Brian Jamison's blog

  • How to write an RFP, part two: How much will it cost?

    Feb 03, 2010

    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.

  • How to write an RFP, part one: Always include a budget

    Sep 21, 2009

    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 use 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.

  • Achieving success, part three: Stop re-inventing the wheel

    Sep 10, 2009

    One of the major reasons I believe in open source is efficiency. Leveraging open source software should allow you to spend your time and money on customization or innovative new features.

    For example, it doesn't make sense to build a content management system from scratch when you can leverage the efforts of hundreds of thousands of programmer hours for free. And yet, developers do this all the time.

    Open source developers aren't exempt. And simply using open source tools doesn't automatically guarantee the wheel isn't wastefully being re-invented. You have to leverage an open source project to do that.

    What's the difference between tools and projects?

    Tools are just what they sound like; they allow you to build, but they're not the end product. PHP and Ruby on Rails are tools. Projects are finished work and in many cases need nothing more than installation to be useful. Drupal and Wordpress are examples of open source projects.

    Developers often say, "Don't worry, I'm using open source tools on this project!" and happily waste hundreds of hours duplicating work that is freely available.

    Why would a developer re-invent the wheel? I don't have a good answer for that, but I can speculate. They're probably not trying to make a project cost more. They may underestimate the difficulty, or the complexity involved. They might not be looking out for your best interests; who will manage the site after they move on, or how will you be able to inexpensively add new features down the road. They may be unwilling to invest the the hundreds of hours mastering an open source project. Or they may believe they can do it better; they have a grand vision for turning your contract work into a new open source project. No problem -- unless you, the client, have to pay for it.

    I have three recent examples. The names have been changed to protect the re-inventors, but I've encountered each within the last two months.

    Case #1
    We were recently asked to evaluate a content management system written from scratch using the open source Ruby on Rails tools. And while the site looks beautiful, they wasted time and money re-inventing the wheel. Instead of spending months building the site from scratch, they could have installed Drupal in minutes and invested in useful new features, even better design, or just saved the money.

    Case #2
    A company spent tens of thousands of dollars customizing Drupal to great benefit. They attributed much of the success of their product to the marketing and social functions their site gave them -- features other competitors lack. Unfortunately they recently hired a junior programmer. The junior programmer threw the old site away and spent months building a new website from scratch using open source tools, but not re-using any of the prior work. And while the new site looks great, the old site could have been themed to look exactly the same as the new site in about two days, retaining the sophistication already developed. As it stands, who will maintain this site once the junior programmer moves on? Are there unknown but serious security holes in the new system?

    Case #3
    This week I met a web developer who built a new content management system for a client from scratch using PHP. He wondered whether or not it would be a good business opportunity to sell it to other companies. I had to tell him that there is simply no way that a new content management system written by two guys will be able to compete in the overcrowded content management space. Their fresh new system lacks the thousands of free enhancements available, the sophisticated permissions, workflows, solid security and design flexibility that Drupal offers. And it will never be able to catch up, because hundreds of people are working every day to make Drupal better.

    In each of these cases, tens of thousands of dollars could have been saved or put to better use. Please don't re-invent the wheel. Hold your developers accountable to their design decisions. Ask them how they intend to leverage existing open source projects to save you money.

    In future blog posts I'll talk about productizing applications in a niche market, but beware the developer that talks about turning your consulting job into a mainstream product like a content management system.