OpenSourcery

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.

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.

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.

In my last post I talked about how important it is to include a budget in your request for proposal (RFP). People have since asked, “How do I know how much it will cost?”

I think that's the wrong question. There are two better questions. The first is, “how much will we get?” The second is, “how much will we save?”

How much will we get?
If your goal is concrete, say online fundraising or ecommerce, take the net funds currently raised after all costs for a year. Add your current growth rate and estimate that figure for the next year. Use real comparable data from similar efforts if you don't have your own.

Now multiply that by your goal. the amount of increased value you expect the site to deliver. Make your goals realistic and conservative. Perhaps your goal increased subscriptions of 20%. Your maximum budget ought to be less than the amount you expect to gain from the new project.

For example, let's say our site brought in $1,000,000 in 2010 with $250,000 net after all expenses. In 2009 that figure was $800,000, so we have a 25% growth rate. If that trend continues we'd expect $1,250,000 in 2011, or a net of $310,250. If our goal is to increase our subscriptions by an additional 20%, that gives us $370,500 in the first year. The difference, $370,500 - $310,250 gives us a maximum budget of $60,250. If our project costs less than that and delivers on the 20% goal, the project is a success.

Before I address our second question let's talk about budgeting when the goals are less measurable.

How much do we have?
In many cases the goal is less concrete. Awareness campaigns, political movements, and educational organizations fall into this category. In this case you need to know your budget before you go shopping.

Identifying a figure in a simple formula is impossible, but most organizations are putting the bulk of their outreach budget into online campaigns because it tends to be the most efficient use of budget. On top of that, results can be tracked and therefore easily improved, and the time to engage and close your prospect is faster.

No more than 50% of your budget should go into the entire technology deployment. At least 50% needs to be held back for staff to do the work – creating content, putting together online marketing campaigns, tracking the results and improving the campaign for the next run.

How much will we save?
This question is one of the most overlooked, least considered aspect of a technology buying decision. For example, a solid content management system (CMS) like Drupal can save an organization enormous amounts of time and money, particularly when compared to a proprietary closed CMS or a website managed by Dreamweaver.

The areas where savings can be had in a Drupal CMS fall into over a dozen categories, not all of which will apply to every organization. Those categories are software licensing, license management, content management, technical management, hardware, hosting, security/reliability, support contracts, development or customization, training, opportunity cost, hardware upgrades, software upgrades, and eventual migration to another system. Total up actual or projected costs for each of these areas. The difference between your existing costs over the expected lifetime of the CMS is what you stand to save (or lose). I'll cover each of the categories in more detail in future posts.

For example, your costs to manage a proprietary CMS might be $175,000 per year, and you project costs of $125,000 per year to manage Drupal so $50,000 a year stands to be saved. If you expect your new Drupal site to last you three years, that savings is $150,000. Coupled with our prior budget of $60,210 that gives a maximum budget of $210,250.

Answering these questions should help your organization identify a budget for your project.