OpenSourcery

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.