It's not uncommon for seemingly open RFPs to be issued in cases where the winning bidder has been preselected.

Why are “done deal” RFPs created in the first place ?

People at a company have a project that needs doing. The People decide to work with trusted contractors they know or have worked with in the past. They might even get as far as brokering a verbal agreement, when someone at the company realizes they have to follow the procurement policy. The policy usually says that contracts with budgets over a certain size must be put out to bid. Sometimes review of a minimum number of competitive bids is also stipulated. A very thorough & official-looking RFP is issued, as a formality, and the end result is people work with the folks they know.

Of course you aren't planning to do this, so why does this matter to you ?

If you don't have a lot of experience writing RFPs it's not uncommon to use example RFPs as a guide.Organizations which have a policy which requires RFPs often have a very refined template for generating RFPs. This means there are lots of easy to find examples of very good looking “done deal” RFPs. If you don't know how to spot a “done deal” RFP you might unintentionally use one as the model for writing an honest and open RFP.

Experienced web developers are pretty good at spotting a “done deal” RFP and won't waste time preparing a response. If you base your RFP on a “done deal” RFP you risk driving away the most experienced potential bidders.

Is this a done deal ?

RFPs which use vendor-specific buzz words or non-standard industry terms in the requirements suggest that a specific vendor was involved in drafting those requirements.

A very short response deadline is a dead giveaway that the person writing the RFP doesn't want additional proposals to review. Less than 3 weeks is questionable, a week or less is a red flag.

Unreasonable or strangely specific experience requirements might indicate that the RFP writer already has a proposal in hand from a preselected developer who meets these requirements. For example: Please provide 5 or more examples of websites you've built for other State Universities, At least 5 years experience integrating websites with our internal EsOhTerriK ™ database, etc.

A very detailed implementation timeline can indicate the RFP is a done deal. It's ok to specify when the proposal is due and when the job needs to be done, but it's usually left up to developers to determine the implementation schedule and milestones for the project build. Including dates for minor development milestones in your RFP is a signal that you've already got a proposed timeline from a developer.

In an effort to minimize web development project risk, RFP writers sometimes place strict requirements on the geographic location of responding firms. For example, a nonprofit agency in a small town might state in an RFP for their new website that the web developer needs to be able to meet in person at their office throughout the project.

This has the effect of reducing the number of well qualified responses to the RFP. The best web developers can't afford to move to your town for a 3 – 6 month contract. Well established firms are used to collaborating with clients via web and video conferences.

Proximity doesn't ensure accountability, though it does increase the chances that you'll bump into your web developer at the supermarket.

In terms of collaboration, time zones mean more than geographic co-location. If two groups are in the same time zone then they are next-door Internet neighbors. If you're within 4 hours of each other, you can work together comfortably with no problems, you're Internet neighbors.

Feel free to work the geographic flexibility of the Internet to your advantage. Spend that Manhattan money in Portland, Oregon where the overhead is lower.

When writing a RFP for web development services, focus on making it easy for folks to initially respond with a proposal. Remember most review processes take place in two stages; a “first cut” review and a follow-up interview process with two or three selected bidders.

Scrutiny happens in the second phase, not the first. So keep it simple in the beginning. Don't ask too many questions. You might consider holding off on requesting client references until after you have identified your top three candidates. You should be able to get the background you need in about 10 – 15 basic questions. One of them can be “tell us about your background and experience”. Don't ask questions which aren't related to the business of web development. Developers don't want to discuss their favorite T.V. shows (or your favorite T.V. show), for example.

Developers who know they are on the short list for your project will be much more willing to answer questions, provide client references, etc.

Include a ballpark budget range in your web development RFP. Leave out this critical piece and the most reliable developers won't respond to your request. Keep in mind the budget you tell contractors needs to reflect what you can actually afford to spend on your website.

Having a budget discussion early in the process helps to ensure that both the client and the contractor are in the same league and playing in the same ballpark. It's only worthwhile to toss the ball back if the developers have some assurance the potential client will be able to catch it.

There are a number of reasons folk might be hesitant to include a target budget when requesting a price quote. They might be unsure about what a reasonable project budget range is, or concerned about the impact a stated budget will have on the price quote. If you're nervous about this too, let's take a moment to look at what actually happens in some different situations.

These examples all assume that you're dealing with a reputable contractor, whom you can trust; As a general rule, we advise against hiring contractors you don't trust.

Situation #1
A potential client asks for lots of bells and whistles and provides a target budget that is substantial, but far too little for the scope of work requested.

Detailed estimations doesn't move forward until the scope is reduced or the budget is increased. The goal is to figure out some way to deliver what client #1 actually needs given the resources at hand, if that's at all possible. A phased approach to development might be suggested.

Situation #2
A potential client asks for some very fancy features and the stated budget turns out to be substantially greater than it needs to be.

The estimations and proposal process moves forward smoothly. Engineering findings and costs are provided in a transparent format so that potential client #2 can see the basis of the quote. From the contractors perspective we're excited to deliver the news that the project will cost less than expected, since this means our bid will be competitive. Assuming client #2 accepts the bid they don't end up spending more for having provided a greater budget.

Situation #3
A potential client asks for very simple features and the stated budget is also very small.

Some projects are too small, or too simple for our firm to do. Letting us know the target budget in this case would result in getting a referral to reliable freelancers who specialize in smaller projects.

Situation #4
A potential client requests a quote and provides us with a firm budget limit just a wee bit lower than seems feasible.

If an estimation is expected to come out over a firm limit, we might reach out to the potential client to determine if there is some wiggle room in the budget or to suggest some strategic adjustments to the scope of work.

Situation #5
A potential client needs advice about what a reasonable budget range is for a scope of work.

It's perfectly ok to ask a reputable development firm for advice about an appropriate ballpark budget for a web development project. Do this before you solicit proposals to make sure your organization has the resources needed for the project.

In the previous article I covered the problem of risk in web development projects. There is a mix of experienced and inexperienced developers, and sometimes it's hard to tell them apart when reviewing RFP responses.

Of course you'll never be able to tell them apart if you only receive responses from inexperienced developers. Before we tackle telling the alfalfa sprouts from the redwoods let's look at a simple step you can take to help ensure that experienced developers respond to your RFP.

The very first thing I look at when evaluating an RFP is the deadline for the proposal. Have the people issuing this request provided enough time for a qualified firm to respond ?

Keep in mind responding to an RFP means the developers clarify the technical requirements, create an implementation plan and estimate the time required to do what needs doing. If the request for proposal doesn't provide a few weeks (minimum 2-3 weeks from when potential bidders first see the RFP) to respond, then you'll only get proposals from inexperienced developers.

This is how the element of risk first enters the picture. When too little time is alloted to provide an estimate based on engineering findings there are some natural consequences. Inexperienced developers will try to make a quick guess at the cost for building your project and experienced developers won't respond at all.

Web development projects that start off this way frequently spiral out of control in the final weeks or months of the project. In the worst cases an inexperienced developer will start to feel saddled by the project as the number of hours spent on the project exceed the guesstimated project budget. “We've been having trouble getting our developer on the phone” is a common symptom with cases like this.

A little planning time in the proposal stage really goes a long way toward bringing your project in on time and on target.

OpenSourcery's Nonprofit Ambassador shares the story behind how experienced web developers review a request for proposals.

Part 1: The Problem of Risk

Web application development is a totally unregulated industry; It's like the old west, there are lots of cowboys, and just a few seasoned ranchers. Some of the freelance cowboys are experienced and know what they are doing. Many inexperienced freelance cowboys are eager to gain experience by working on your web development project. Inexperienced developers tend to be less successful than their more experienced counterparts, introducing a level of risk that would be unacceptable in other contracting industries.

Your Request For Proposal (RFP) document will determine who responds to your request with a proposal. Write it well and you'll hear from the dependable ranchers, seasoned cowboys, and the very risky inexperienced cowboys. Write the RFP poorly and you'll only hear back from the least dependable folks.

This blog series will explore the elements of a good RFP, what experienced developers respond to and what they don't respond to. Follow these guidelines and you'll be in good shape.

Is Fixed-Price Software Development Unethical?

This is the question posed by Scott Ambler in his article on software development.

Here's the problem.  Everybody knows:

• Cost estimates are frequently wrong
• Client requirements usually change during development

...and as a result fixed-price projects are often late, over budget and/or don't really do what the clients want when the product is delivered.  How does this happen, Scott lays it down here.

Here at OpenSourcery we strive to use the Agile software development methodology to deliver better service to our clients at less risk of the project going horribly, horribly wrong.  

Watch this space for more information on Agile software development, why we use it and why it makes so many of our customers happy.

- Steve Peters