Getting a Better Geospatial RFP

The Request for Proposal is a lot like a first date. It becomes the first impression for a relationship we hope will be valuable for both parties. Like any relationship, communication is the key to success. That is probably more evident in the RFP than anywhere else in the project. It is here we are defining exactly what we’re looking for in the potential partnership. The RFP (or RFQ or Request for Quote) can be challenging and it’s even more so with highly specialized industries, such as geospatial information systems – the focus of our discussion today. A good RFP will invite participation and competitive bids, and a poorly written RFP could get bids that completely miss the mark or get no responses at all. Even worse, a poorly written RFP could result in an award that creates an adversarial relationship with both parties contending against each other.

The most important thing before writing an RFP is to know exactly what you need and are looking for. That sounds self-evident, but it’s surprising how many RFPs I run across from organizations who understand they need something but don’t know what it is they need. Then the RFP is just as confused. An organization that is new to a technology or lacks personnel with reasonable knowledge will be much more successful by teaming up with someone who can assess their needs and clearly define their requirements.  In my experience, it’s very difficult to effectively purchase services when you don’t know what you’re looking for. This is often much more of an issue with geospatial projects as there is still a considerable knowledge gap – both in organizations needing the services and some who would provide services. With the knowledge gap, there is a considerable amount of ambiguous language in our industry.

The first step is to do your homework – understand the market and the industry. Find out what’s available in the industry and know what’s possible. If necessary, trim the requirements or plan on breaking a project into segments. It’s much easier to find a horse than a unicorn. Completing an assessment project before embarking on implementing a solution can make the final solution much more effective.

At this point, it’s critical to identify what your needs really are. Distinguish between needs and wants. Often there are nice-to-have elements that can kill a projects budget and schedule, so peel off those unnecessary layers. The nice-to-haves should be included, but in a different section of the RFP and clearly identified as wishes.

Next we’re going to discuss several things that are critical in a well-written RFP. Having these specific headings or sections is not so important as actually having the information there, and of course, it needs to be presented in a logical and easy-to-read fashion.

Background – Providing details about the organization and its needs gives the RFP context. It provides the why and answers many questions the bidder might have. A comprehensive overview of your organization helps potential bidders understand why you want the work and can deliver results that meet your needs. Along with the organizational overview, identifying the problems you are trying to solve is also important and anything you may have already done to mitigate the issue.  Remember, this is where you start to establish the relationship.

Purpose – A clear and concise purpose is the meat of the request. The expectations, requirements, platform and software requirements, and any other specifics that affect the delivery should be clearly spelled out. This is the place to identify that you require a specific version of software.

It’s also important to identify the type of relationship desired. Are you looking for someone to come and do a job once, or is this the beginning of a long series of projects? That can make a significant difference on bidding, particularly if there’s some retooling – through software or personnel.

This portion of the RFP requires the highest technical capability. It’s critical to understand what you want and to clearly define it for the bidders. If the project requires a field crew (or crews) to manually inspect an approximate 400,000 water meters, then it should be clear. If you have a database definition document, you should probably include it or make a copy available online. It’s also important to determine the delivery format and how you plan to incorporate data into your enterprise system.

A schedule is also important to include, even if it’s preliminary. It helps the bidder understand the resources needed. It also helps bidders recognize that maybe they shouldn’t bid. If the project is time dependent with a lot of labor, a small firm without the necessary resources may not bid. That saves them time from putting together a proposal as well as saves your time reviewing a proposal with no possibility of accomplishing the project.

A controversial element to include is the project budget. It helps define the boundaries of the project. Yet, often people believe that sharing the project budget will encourage bidders to raise their rates, but the competitive nature of the bid keeps firms offering their best prices or lose to competitors with lower rates. Not providing this information can keep qualified firms from bidding so as not to spend non-billable time for projects of unknown value. A stated budget let’s bidders know a project is real and can also give them a chance to identify the appropriate solution. A great solution that costs 10 times the budget is of no use to anyone.

Goals – It’s very important to clearly identify why you are doing this project. This provides a finish line for the bidder. It gives the bidder a chance to respond with how he’ll meet those goals. It allows the bidder to determine a pricing structure that makes sense for the project. And the upside is that it gives the bidder a chance to exceed your expectations.

Proposal Format – Include a desired list of information you want to see and the format you want to see it in. That helps the bidder ensure they provide all the information you are looking for, and it makes it much easier for you to evaluate multiple proposals.

Evaluation Criteria – Most organizations who issue RFPs have some criteria they are using to decide the winner of the RFP. This shouldn’t be a secret. It actually encourages a fairer bid as everyone participating has a way to identify what they need. If you’re giving points for a licensed surveyor and a minimum number GISPs, then letting everyone know ahead of time can ensure you get the best proposals to review and select. If you have a score sheet, I would go so far as to include it in the RFP.

Wish List – Identifying the actual requirement is the most critical, but if there are some targets of opportunity available, make sure the bidder knows and give him a chance to exceed the project expectations.

As I mentioned in the beginning, a well written RFP is key to communicating your intent. A poorly written RFP wastes the time of everyone involved. Putting the right effort in up front makes all the difference. The better the request for proposal is written, the better your proposals will be, and the better you are likely to accomplish the project goals.