Everyone Wants a Number

Proposals are hard. Second only to networking, they’re the biggest part of my job, and also the worst. I get acute stress about dialing down an entire project to a single number. It’s stressful. It is not something I want to screw up.

Earlier this week, I was done with a proposal…except for the number. As I sat there, staring at the blank space in the Word document, I tweeted this.

It’s all fun and games until I have to put a number to the right of the dollar sign in your proposal.

And there I sat. For about an hour.

The numbers we put in a proposal can be of two flavors.

1. Fixed: we will do X for $Y, period.

2. Hourly: we estimate that X will take Y hours at $Z per hour; this is an estimate and might change depending on what happens mid-project

I personally prefer hourly, but everyone wants fixed because, at the end of the day, everyone wants a number. They want a number they can grab hold of and say, without question, this is the number with which we can build this project.

Remember the Marine Corps Rifleman’s Creed from Full Metal Jacket? Let’s modify it a bit.

This is my number. There are many like it, but this one is mine. My number is my best friend. It is my life. I must master it as I must master my life. Without my number, I am useless. Before God, I swear this creed.

Everyone wants a number.

I can sympathize, because everyone has to budget, and for everyone who wants a number, there are people above them who also want a number. The incessant drumbeat for a number trickles down from above. The inability to produce a number is never met with understanding.

Numbers provide certainty. The number is a constant you can cling to. It is security – you may not know much about your project, but you have this number, so you cling to that.

Sadly, there’s another side to this – the integrator. The guy who is bidding the work. The guy who has to get you a number.

I’m that guy.

My struggle is that I want to give you a number that is honest and accurate, while at the same time protecting my company from unforeseen cost overruns. I obviously want to make a profit, but – contrary to what some believe – I don’t want to rip you off, and I do very much care that you feel like you got a good value for your money at the end of the project.

Consequently, I sweat the number I give you. I don’t take it lightly.

If only coming up with this number were easy, it would make my job a lot better. But web projects are complicated, and they never have enough information. Sometimes, the work required to get to a number can be a significant chunk of the project itself.

I talked about this six years ago in The Quandary of the Web Development Sales Process:

There’s so many variables involved with building a Web site, and so much of it is buried in the creative process, that it’s hard to really paint a picture in a prospect’s mind as to what you plan to do.

Consequently, you often get clients who want more and more information and more and more planning before they sign a sales agreement, until you find yourself putting far too much work into a sale which you haven’t gotten yet and might not end up getting.

This hasn’t changed one bit. If anything, it’s gotten worse as web technologies have become more complicated and customer expectations have grown.

Fixed bids cause web development companies stress for the simple fact that we’re binding ourselves to a number that we have to respect. If we get into a project and it explodes with unforeseen difficulties, that number is still there, and Blend takes it seriously. We do not relish going back to a client and saying, “There’s a problem and your number is no longer valid.” In the rare cases we’ve done this, we’ve had a very clear reason why this was not our fault and due to extraneous circumstances beyond our control (or clearly the client’s fault) caused this situation.

(Honestly, in more situations than we should have, we’ve just swallowed the overage in an effort to provide the client with a good experience. We do this more than I like, frankly.)

So, to provide a fixed number that doesn’t cause us to lose sleep at night, we need to do one of two things:

1. Have requirements specified to such an absurd degree that the entirety of the project is understood, and there is no chance for a misunderstanding.

2. Pad the hell out of the number.

I do not like padding. It feels dishonest, but when lacking sufficient requirements, and facing someone who is adamant that they get a fixed number, that’s our only option.

I’ve had people call me on it.

Come on, is it really going to take that much money to do it?

My response is always the same.

Probably not, but your requirements are so vague that the chances for a misunderstanding are huge. Therefore, to protect myself, I’m bidding for the worst case. If you don’t like this number, then let’s develop your requirements so that the worst case is less likely to happen.

This answer underscores a key point: your number is only going to be as accurate as your requirements. Good requirements = accurate number.

Too often, we get “requirements” that are so vague as to be meaningless. Just today, I had a bulleted list of things like “event calendar” and “banner ads.” And this person wanted a fixed fee.

I refused to do it. I explained that with a fixed fee, someone has to interpret what “event calendar” means in relation to the fee – does it get recurrence, start times and end times, categorization, iCal import, permissions, etc? What they think is reasonable for $X, I may vastly disagree with, and who arbitrates?

This conversation has actually happened:

Well, obviously we should have gotten Feature Y for $X. Google Calendar has Feature Y. When you bid this, you should have known that Feature Y was a reasonable expectation for this project. I mean, seriously – what calendar doesn’t have Feature Y?!?

I resisted the urge to respond:

Every calendar that only cost $X!

To counter this, we’ve begun to do what we call “Phase 1” projects. These are projects where we unleash Corey, our content strategy guy, and he works with the client to plan the entire thing out and deliver all sorts of documents – including detailed, annotated wireframes – that flesh the entire project out. We get paid a flat fee for this work.

This is work product, and we tell the client to put it out for bid. We bid on it obviously, but we understand that other firms will be using our plans to bid on the work as well. To date, we have never lost a bid for the implementation work (in most cases, honestly, their experience with Blend throughout this process is so good that they never actually put it out for competitive bid).

I like this process, because it feels honest to me. The client is getting a better experience because they’re being forced to explicitly plan out their web presence in advance. This part of the project is the most important thing any organization can do.

As I bonus, I’m getting a solid plan I can bid. I can put a number on it – without padding – and be comfortable in that number. We work up a formal WBS and put hours on every task, including line items for “soft” items like “project coordination” and “environment set-up.”

We usually provide this spreadsheet to the customer, so they can see exactly where we’ve put hours. Then we usually offer it to the client two ways, which should look familiar:

1. Fixed. We will do it for this number.

2. Hourly. We think it will take his number of hours at this rate, but we’ll bill you what it actually takes.

I tell the clients that if they think our estimate is low, then take the fixed fee – if we’re indeed low and go over, then it’s our problem. But if the client thinks we bid high, then take the hourly – if we’re indeed high, then the actual cost will be lower, and they’ll pay less.

This too feels honest to me. It’s the equivalent of the apocryphal tail of the mother with two sons who needed to share a single cookie – one of them got to cut it, and the other one got to pick which half he wanted. With this check in place, it was in the cutter’s best interest to make the cut as equitable as possible.

In effect, it becomes harder for a client to complain about a bid. If they don’t like it, then they have the option of a course of action (hourly) that will give them a better deal.

Sadly, this doesn’t stop people who still want a very low fixed bid with extremely vague requirements. In these cases, we have to trust our gut and just walk away.

Here is my advice to those of you evaluating proposals or putting together an RFP:

• Be realistic about the finality of the number you want compared to the finality of your requirements. They are directly linked – the more final your requirements, the more final my number. Do not expect a firm number on soft requirements.

• Be wary of getting a fixed number on vague requirements, because then the requirement is up for debate, and the integrator will evaluate it in relation to the number. A “Event Calendar” for $X is going to look a lot different than an “Event Calendar” for $10X. If you didn’t specify what you wanted, and the number is set in stone, then the integrator will specify it for you and what recourse do you have?

• Be open to the idea of paying for a specification before you actually start building something. You really need a plan anyway, so you’re just breaking off part of the project and paying for it sooner than the rest. To do otherwise is to tell a contractor, “Build me a house,” then walk out of the room. Architects exist for a reason, folks.

• Hourly projects are not necessarily a bad thing. Yes, they introduce uncertainty, but if you have a good relationship and good communication with your integrator, then it can work. You should get a more slimmed down project because the integrator doesn’t have to pad a fixed number. Just make sure in advance that the integrator knows your final budget and what you expect for that, and make sure you’re updated on expenditures often, so if something is running long, you can adjust.

• Consider just telling your integrator how much money you have to spend, and asking them what you can get for this. Make money the fixed constant, and debate functionality instead. That can make the situation a lot more clear, and it lets an integrator bow out early if the budget isn’t even close to what they want to charge you. This benefits you in the end. For more on this, see: Just Give Us a Budget Target.