One question that we (almost) always ask organizations that are considering our services is: Has money been budgeted for this project?  If so, how much has been budgeted?  As you can imagine, there are a number of different responses to the question; however, essentially there are two responses.  The more popular response goes something like this, “Well, um, yes, we have money in the budget for project XYZ.  No, I can’t reveal that amount to you.”  The less popular response sounds like this, “Yes, we have set aside money for the project in the budget.  While I can’t tell you how much has been set aside, our expectation is for proposals between $X and $Y.”

Why don’t organizations reveal how much they’ve budgeted for their project, or, at a minimum, what their expectation of how much the project will cost?  I can think of a couple of reasons.  They include:

• If we reveal our budget — let’s call it $X — to vendors, every last one of them will bid $X or $X - 1.
• It’s none of your business.
• We really don’t know what the project will cost and we’re using this RFP process to help us figure out how much to budget.

Let me address each of these reasons.

If we reveal our budget, every vendor will bid that amount (or close to it)

OK, I understand why someone would think this way; however, in today’s IT consulting marketplace, there is enough competition between far too many vendors chasing a limited number of clients and projects that I just don’t think it happens that often.  In an ideal world, we, as a IT consulting firm, would be able to convince you, the possible client, of the value of our services and justify the cost of our bid as a sound business decision.  The reality is that price does matter.  Organizations, especially those in our target markets — associations, non-profits, professional service firms, financial institutions — have a limited amount of money to deal with growing IT issues.

It’s none of your business

While I’ve never heard a possible client use these exact words, I’m sure there were more than a handful that were thinking it after hearing our request :-)  Yes, you do have a right to reveal or not reveal information about your organization, your staff and your requirements.  However, the more transparent and open the process is, the more likely that (a) you are going to find a vendor that fits and (b) the project will be successful.  Yes, we are in the business of making money; however, the best way for us to make money and to succeed as a service organization is to develop solid, long-term relationships with our clients and work hard to deliver quality service at a fair price.

We don’t know how much the project should (or will cost)

As a vendor, I think this reason is the most frustrating one to deal with.  If you’re not willing to invest the time and energy to figure out how much you think the project will cost, why should I, as a vendor, spend time and resources to develop a good response to your RFP?  Instead of issuing an RFP, perhaps the better approach would be to issue a Request for Information (RFI) instead.

I’m sure there are many other reasons.  Send me your feedback via the comment feature and I’ll post them.

Please see Five Things Every RFP Should Contain for other comments, as well as my disclaimer.

As an IT consulting firm providing network integration, web design and software development services to small to medium sized clients in the D.C. area, we receive lots of RFPs (both solicited and unsolicited).  Please note that most of the RFPs I deal with are in the area of web design and development, so some of my comments may not apply to RFPs for different services or products; however, in general, I think my comments apply across many kinds of RFPs and other formal (or informal) solicitations for products and/or services.

The RFPs I review vary greatly in terms of quality and quantity.  I’ve seen good proposals that are no more than a couple of pages.  I’ve seen not-so-good proposals that go on for 20 to 30 pages.  Quantity (or the thud factor) does not necessarily correspond to quality.  Since most of the proposals I read are related to web development, the discussion points and examples below will be geared towards that particular kind of RFP.  Here’s what I think all good proposals should include:

• What are the critical success factors and key requirements for the project?
• Who’s involved in the decision-making process?
• What criteria is being used to select a vendor?
• What internal (or external) constraints affect the project?
• How much has been budgeted for the project?

As a general rule, the more time and energy that the proposer invests in the RFP, the more likely we can either (a) propose a solution that we believe meets their requirements or (b) help them find a vendor that is better suited for their project or (c) decline to bid, which saves everyone time.

I’ll deal with these five discussion points in future blog entries.  If you have others you’d like to see added, please let me know.  The true power of a blog is not in the initial posts, but in the subsequent discussion that it provokes.

As always, I welcome your comments about this blog.  Post them online for everyone to view or e-mail them to me at james99 (at) networkats (dot) com.