Just Give Us a Budget Target
I’m going to propose a radical thing to anyone shopping for Web development services: just tell us how much money you have to spend. Gosh, that sounds crass, doesn’t it? I don’t mean it to, but I’m serious – things will be so much easier for both your side and mine if you’re just upfront about how much you want to spend on the project.
The thing is, Web development is not a black-or-white thing. Too many people writing RFPs think that the project is either done or not. What they don’t take into consideration is that there are usually a dozen different ways to do anything. There’s the Kia option, the Ferrari option, and about a dozen options in between.
What you might not understand is that we can alter our plans based on your budget. If you tell us “I have $X to spend on this” we can either:
Come up with a plan that accomplishes it for $X
Be honest with you that it can’t be done for that price.
It usually ends up being the former, because we’re awfully inventive around here.
A couple of months ago, we got a set of requirements from a someone we’ve worked with in the past. He wanted a bid, so I worked up a Statement of Work, put an appropriate price on it, and sent it off. His response: “Seems high.” Now, I knew it wasn’t “high” in the sense that it wasn’t even remotely padded. It was an honest bid for the work he wanted done. But it was obvious that he had a number he wanted to hit.
Now, I had the option here of playing darts with him – essentially throwing darts against a wall until I hit the magic number. Rather than that, I did the unthinkable, and I just asked him: “Tom, how much to you want to spend on this?” To my surprise, he didn’t hesitate to give me a number. It wasn’t a bad number – just about 20% less than the number I had given him. But now we had a target. With a target, it was pretty easy to see where we had to get.
In this case, we cut a little here and there:
We had them write a certain piece of code (which, in turned out, they were expecting to write anyway)
We removed some unit testing of the interface
We had them do all user acceptance testing.
We cut down on the project coordination budget and explained to them that this meant they needed to be deliberate and focused about meetings.
In the end, we hit their number and we both had a much better understanding of how the project was going to work. They were thrilled, and the project is about two-thirds done as I write this.
But no matter how much it eases the process of coming to an agreement, too many people will never release their budget. Sometimes they just don’t know how much the can get, or they have no idea what the project will cost. However, more often than not, there’s another reason – they think the bid will come in much lower than their budget, and, if they reveal their budget, all the evil vendors will pad their bids to match it.
In practice, this rarely happens. As any Web developer can tell you, it’s not often that somebody comes in the door with far more money than they need. They usually have plans coming out their ears, and not nearly enough money to accomplish them all. Rather than scaling up bids to use all their massive wads of cash, what we’re usually doing is helping them refine their plans and determine what goes in for the initial outlay.
(I guess, in the end, this strategy depends on the honesty of the firm you’re dealing with. I don’t doubt that there are some firms that will pad bids in an attempt to soak a client. Thankfully, I don’t work for one of them. At Blend, we love what we do, and if we can sneak one more feature into your project for the money you have, we’re likely to do it.)
Understand that being open about your budget also benefits you in the end, and you’re likely to get a much more honest response if you put your budget in the RFP. Many firms will look at your number and simply say it can’t be done for that. This is a good thing. You don’t want an RFP from a company that won’t even be an option for you. Of the RFPs you do get, they’ll be much, much more realistic in terms of what can be done.