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.

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.

I'm writing this series of blog posts to help improve the response rate on your Requests for Proposals (RFPs) as well as increasing the chance that the right firms will respond. We receive a number of invitations to respond to RFPs every week, and a surprising number do not contain enough information for us to respond.

Rule number one, always include a budget in your RFP. You may be thinking that disclosing your budget is a mistake, that it leaves you open to predatory firms, or price-gouging. I disagree, and I'll tell you why.

RFPs without a budget are perceived as risky to developers. We wonder -- does the requestor have money set aside for the project? Is the project even approved? Is it in too early a stage for the developer to get involved? Does the requestor understand the complexity required?

Perhaps more importantly, a developer needs to know that they're the right fit. Because of our size, it doesn't make sense for OpenSourcery to respond to an RFP if the requestor has a budget of $2,500, and it also doesn't make sense for us to respond to a budget of $5,000,000. It could be argued that as developers we should know how much a given project will cost. That may be so, but finding the answer is time consuming and therefore expensive. Providing that answer is valuable; it requires expertise. Don't expect that to be provided for free -- at least, not by people capable of giving an accurate answer.

Responding to an RFP has real costs. A developer must dedicate expensive resources; for example it costs my company at least five hundred dollars to respond to an RFP, both in hard and opportunity costs. It can cost us many thousands. I need to be convinced that there's enough profit potential in an RFP to justify the investment, and without a concrete budget I'm forced to guess. And my guess will always be "not enough."

Adding a budget is the most important component to an RFP. Don't leave it out.

If you don't know how much your project might cost, you need to find that out before you put your RFP out to developers. I'll cover techniques for doing that in my next post.

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