Fixed Quotes: The Consultant's White Whale

(A Prequel-ish post to Specs: The Consultant's MacGuffin )

One of the largest challenges you'll face as a consultant is in generating quotes for potential projects. Prospective clients will come to you and ask - How much will it cost to make X? And you will be expected to respond with a hard and fast number that you are willing stick to as the project progresses.

In my experience, coming up with that perfect hard-and-fast number is a impossible proposition for you and a irrational expectation on the part of the client for the majority of projects - pretty much anything without perfect specifications that's not a carbon copy of a previous project that you've done. As most clients don't know exactly what they want until much later in the process, asking for a fixed quote is akin to asking a car dealer to commit to a price before you've decided on a sedan vs. a SUV.

As Venkat and Andy write about their book Practices of an Agile Developer in the section "Fixed Prices Are Broken Promises":

A software project is subject to all the simple mistakes [as building construction] plus fundamental changes to the requirements (no, not a shed, I want a skyscraper!), huge variability in individual and team performance (20X or more, depending on which studies you believe), and of course, the constant inrush of new technology (from now on, the nails are circular) (Practices of an Agile Developer, p.75) .

They suggest an alternative - Ask the client to pay for one iteration of an agile development cycle. start with a small set of features and a shorter development cycle to create a deliverable with most of those features that is useful in some way to the client. The client can then choose to go forward or not with the project but at most they are only out the cost of an initial iteration.

This is a great idea and probably a win for everyone involved - but in my experience it's a tough sell to a client unfamiliar to agile processes. If you need the project, sometimes your are going to have to come in at a fixed cost or the client will go with someone who does.

Your (potential) client is not a software developer. They don't understand the intricacies of what's involved nor do they understand that there are vastly varying levels of project quality depending on the developer (See: Software is a Craft ). I'm not saying that they should understand those things - it's not their business - but the bottom line is that your client will need to make a decision on who to use and will generally use some very simple metrics to choose who to go with. I've found they generally go by:

1. Were you recommended by someone they trust
2. What does your existing body of work look like
3. What is your price.

There's also a 4:

4. What are the details of your proposal

But that, I've found, is less important than they other three. This is why - when your company is just starting out and #1 and #2 are not working in your favor you need to compete on price. You will probably need to save the creative proposal Venkat and Andy describe for a little while down the road when you have a little more clout behind your endeavor.

So - back to that impossible quote. Before we get into the details, I think it's important to keep a definition of what a quote is in mind and here's mine:

Quote (n) - the amount of money you are willing to do a project for.

That's all it is. It's not a perfect calculation of the number of man-hours involved with precisely added-in expenses for overhead and coffee. You can pretend it is - but in reality, it's just the baseline number for which you are willing and able to complete the project - obviously including any fixed hardware, software, contractor costs added in.

Now, you do probably have an hourly rate that you've set either explicitly or implicitly - and you should work off of that rate when generating your quote because that's the only way to get a number that's in the correct ballpark. Going back to that definition above, however, you need to acknowledge to yourself that some projects are going to be more essential to your business than others and you need to have a little bit of flexibility in your numbers to give yourself a better chance at projects that you actually need and want. If you need the project to make ends meet and put food on the table, than it's perfectly reasonable to push your final number down a little bit to get a better shot at landing the project. Alternatively, if a project is only tangentially interesting and you're already booked pretty solid with work, put a bigger multiplier on your final number.

You are not beholden to your self-set hourly rate and the RFP process is a pure a form of the free market so there's no need to feel guilty adjusting your number up or down to whatever works for you. That being said, I do feel that once you are working with an existing client or on extending existing projects, there is a level of trust built up so that your client can count on some consistency in their costs.

Now however you do it, you will most likely fail miserably the first few times at connecting your estimated hours to reality, at least that's been my experience, and there's only 1 important thing to remember: once you get a project, track your time versus the numbers you came up with. If you do that consistently over a few projects you'll be able to develop some insight and start to converge your quotes with reality.

Now for how to come up with that imaginary number that is supposed to represent the Total Hours X Hourly rate. One solution is to scan over the request quickly, think about it for a couple of seconds, and then just pull a number out of thin air based on your gut feeling. I'd recommend against that, but it'll probably take a couple of times making that mistake as a new consultant before you are willing to commit yourself to some sort of process.

Here's what we do (and I'm sure the MBA-types will shake their head's disapprovingly at the lack of ISO-9000 certification on our processes ):

Write the quote out in a bullet point, line item form generating only as much detail as you need to figure out how long a piece will take to complete. (See: Spec's the Consultants MacGuffin for a little more on specs )

Now put a time number (either in hours or days depending on the size of the project) on each of those bullet points and add those up to get a base number . That's your: If I had all the details I needed and could develop in a sense-deprivation-chamber number. It's only bearing on reality is as a starting off point. You now need to take into consideration:

• Time spend talking about the project
• On-site meetings and travel
• Small preference changes (green v. red, radio button vs. select list)
• Features the client will assume are in there even if they didn't make them explicit
• Bug Fixes, both during development and after
• Larger included functionality changes
• Training
• Documentation (outside of the code itself)
• Dealing with corporate hierarchy (waiting for approvals up and down the chain)
• Anything else that will make you spend time working on that project

If you forget to take these into consideration you'll be unable to come up with a realistic quote and will instead just focus on development time - and if you're anything like me you'll view it as a challenge to your prowess (I've unfortunately said: "That's not that complicated - I could bang that code out in a couple hours" more than a couple of times and always regretted it.)

You also need to decide on a couple of important features that your project agreement will need to determine explicitly - will this project be done work for hire? i.e. who own the copyright on the developed code - you or the client - if you own the code it might be worth doing the project for less as you can reuse that code in the future, if not - then make sure you take that into consideration. Also, make clear how long are you responsible for bug fixes. If you don't make this explicit most clients will assume "forever" - and provided your prepared for that, that's OK. Make sure you and the client are clear on both of those issues - don't try to gloss over either ( and please don't take the previous paragraph as any sort of legal advice, talk to a lawyer and get yourself a legit development contract - See: Know your IP Basics for a little more on the above.)

All of these together need to be added into your quote in some way or another - either as explicit line items, or as a multiplier.

If you use a multiplier then the magic number is: 2.65. If you multiply your initial quote by 2.65 you'll come up with the perfect number to represent exactly how much time you will take on the project....that's complete BS of course, the multiplier is highly dependent on the initial estimator, the developers and the client and is by no means a magical, fixed number.

The multiplier will vary project to project depending on how much work the client has done to figure out what they want ahead of time and how involved in every small decision they need to be. It'll vary on how engaged you are in the project; how much the client will be involved in testing and a hundred other things. You'll have to figure out your own multiplier, but don't feel guilty using one (and by no means is "2" high - but, again, your mileage will vary)

I've generating quotes now for around 7 years and I still fail miserably at it from time to time. It's heartening to read something like "Fixed Prices are Broken Promises" to know that I'm not the only one. I try whenever possible to stay away from fixed quotes for larger projects, but fixed quotes are still the norm for the industry and until that changes we will have to keep pulling numbers out of the air to keep the work coming.