Cykod

You don't want a quote for that project

by Pascal Rettig posted Jul 06, 2010

Note: this post takes the iterative nature of software development for granted. As a consultant on dozens upon dozens of Web projects, I take it for granted. If you have had great experiences in complicated projects that go from specification to completion without change, I've never met you but I would love to as you sound like a mythically perfect client.

So you've got to get a project done that needs outside help. Whether it's for a corporate site or your next change-the-world idea, the normal sequence of events from this step is probably:

1. Write up a Specification
2. Put out a Request for Proposal
3. Look over the responses
4. Of the responses from reputable looking companies, pick the cheapest

Number four might get more complicated if you are working with companies you already have a relationship with, but the bottom line usually comes down to finding the right balance of price and security. How much are you willing to wager on your project's success to get a cheaper price.

Now let's take a look at this from the perspective of the consultant. I assume most consultants work off a standard hourly rate, estimate the number of hours and other costs (software, hardware, etc) and come up with a quote.

For inexperienced consultants, the number of estimated hours is usually a vast underestimate of the actual time it takes to complete the project. For experienced consultants, it's usually a significant overestimate of the time.

In the former case (and I've been guilty of this) the estimate is based on a best-case-scenario that fails to account for the risks of the project. It's a if-everything-goes-right number. Developers are a cocky bunch and tend to see the world through rose-colored glasses right up until the first bug. In the real world rarely does everything go right, and if the project is done at too low of a number, disaster will ensue.

In the real world rarely does everything go right, and if the project is done at too low of a number, disaster will ensue.

The consultant will be motivated to triage features on the project because once they have gone over the number of hours estimated, they will essentially be losing money for every additional hour of work time. Since all good software development is iterative, it is a given that there will be new requests from the client based on feedback from prototypes that weren't part of the spec, but are ESSENTIAL to the project being useful when it's all said and done. These will be refused or re-quoted and features that are no longer necessary, but are in the Spec, will be added-in.

Barring a mid-project renegotiation, one of two things will happen: first the project might degrade into an acrimonious battle of wills back and forth as both the developer and client becomes less and less flexible, the former trying to do the minimum as outlined exactly in the spec while the latter holding the developer to features that have no reason to exist except for their presence in the original spec. Alternatively and much more seldom, the developer will eat the costs of the additional time to provide a quality product and a happy client. While this looks like a win from the client's perspective, future projects from the client will either be turned down or vastly overestimated to prevent a repeat. Any changes to the system will need to be done by a new party (and remember, software is iterative so there will be changes), bringing a whole new set of risks into the mix.

Experienced consultants, i.e. ones who have gone through this disaster-cycle a couple of times, will see risks and dangers hiding in every crack of the specification and will base their estimate on Murphy's law, making sure their ass is covered for any eventuality. What consultant, after all, wants to lose money on a project? The risks on the consultant's side: finicky client, non-payment, etc, are just as real on the consultant's side as the clients side.

To sum up, as it stands now, someone who needs a project done has two options:

1. Underpay an inexperienced consultant and count on their goodwill professionalism to complete the project.
2. Overpay an experienced consultant

Neither of those two options should sound particularly good, so what's the solution?

Most projects, from a risk/completion versus time standpoint operate something like this:

The risk is enormous at the start of the project. It falls quickly, however, as any developer worth their salt will try to solve the projects unknowns first and foremost. If you are building real-time stock viewer, you don't build a whole website, membership and payment system before you figure out how to get and the real-time data. Thus a couple weeks into a project, a lot of risk as already fallen by the wayside. Things will either be able to work the way anticipated, or they won't. If you pay a developer hourly for the first couple of weeks, you'll be able to remove a tremendous amount of risk from the process and won't force the developer to quote a number that covers that risk. Since you don't win if the developer underquotes the project (see above), why should you lose if they overquote it?

What if, as an alternative to asking for a quote in response to an RFP, you asked potential consultants for their hourly rate and an estimate on the number of man-hours each of the chunks of the project might take along with a confidence measure of each of those chunks?

While these early estimates will be a little all over the board, you should see some convergence on the number of hours from the reputable shops and you should be able to pick out the outliers on both ends to stay away from.

Now pick a firm on the same criteria you would have originally, but make sure to request a number of smaller milestones with working prototypes. Each of these milestones, coming in at a specific date represents a certain amount of developer time. If the developer is ahead of schedule, they can add features to the milestone, if they are behind schedule then features will need to be removed, but the date for a working prototype is the sticking point.

Provided that you have workable milestones, you, as a client, will have a much better idea of how the project is progressing, and, since you are paying hourly, can iterate on changes as necessary to get the best outcome for the project. If the developer can't deliver the first milestone, it's better to know that immediately and get out of the arrangement as early as possible rather than hang onto that sinking ship all the way down to the bottom of the ocean.

At first glance it might appear that you've shifted the risk of the project from yourself to the developer, but the truth is that the risk was always on you. If the project was under-quoted, you're set up for failure (again, see above), while if it was over-quoted, you'll never see that money back (do you think a consultant who was forced to quote a flat-fee will invoice for less?)

While I've plugged it in other posts, the first few chapters of Head First Software Development from Oreilly gives a great overview of why you should do iterative software development and is very readable by anyone interested in software consulting, not just developers. If you are in charge of hiring or managing software consultants I'd very much recommend you spend a couple hours on it.

So, like I said, you don't want a fixed quote for that project. A fixed quote is heartbreak on a stack of paper. You want a great developer with an estimate, an hourly rate and a number of measurable milestones to take you to that happy place in the ether where software is delivered on budget and on time.