For the Right Price
I was having lunch the other day with an old friend discussing the consulting that I do. He asked me how I come up with prices to quote potential clients, specifically when the work is being done on a project basis, not hourly. After explaining my system to him, I realized that other people likely have the same question, so here’s the basics of what I do.
First, I’m in the IT consulting business, so some of the sections here won’t apply to you if you’re in a different field. However, the method itself is extensible to other fields with the details of each segment being modified to suit the project.
Second, the method was inspired by a comment from Joel Spolsky regarding evidence-based scheduling:
You have to break your schedule into very small tasks that can be measured in hours.
Third, despite knowing the method, it is still easy to make mistakes, and experience alone can reduce the cost of those errors. As an example, there was one project where my quote was off by so much, I ended up earning less than $10 per hour for my work. That project taught me many things, including how to price certain types of projects better. The method can help you develop your intuition, but at the end of the day, if you don’t have any intuition, the method will only get you so far.
I try not to spend too much time coming up with a quote, as I’m not paid to do that. Typically, I can produce a quote for a project within a couple hours for larger projects, and in minutes for small projects.
- Agree on scope: This can take about an hour for a tiny project to weeks for a project with several months of development anticipated.
- Draft requirements and design: Sometimes, this is done as part of the first step, especially for the smaller projects. For larger projects, this could mean as much as 6 months of work (a.k.a. 1000 hours). Experience will help you narrow that range down fairly well.
- Development: For this, I try to break down the tasks I need to do into the smallest pieces possible, each one no longer than a week, and preferably less than 10 hours, although for large projects, getting it down to 50 hour pieces can be difficult enough.
- Testing: Usually 20-30% of the development time will be spent on testing.
- Deployment and Training: This can be anywhere from a few minutes to copy some files and e-mail a document, to a couple days of presentations and creating complex support documentation and procedures.
Now, you add up all the hours you counted in each step. Add 20% to that number. Multiply by the rate you want to get paid for the work. That’s your quote. You can fiddle with the number a bit, but the more you deviate from this, the more risk you take in either quoting too high and losing the project, or quoting too low and not being compensated appropriately.
If you’re worried about the unexpected, realize that you’ve actually already covered it.
The first step will prevent scope creep to some extent, and the better you are at drafting a Statement of Work, the more control you will have over what’s included in each project.
The extra 20% you added at the end is in case something unexpected, but covered by the Statement of Work, comes up during the project. In most projects, this happens, you just don’t know what it will be until it’s too late. If nothing comes up, then your margin on the project is larger.
Last, to determine your hourly rate, I use about two-thirds of my maintenance rate. Since I can dedicate time to the project, and I can schedule it, I don’t mind earning less per hour for that work. In other words, my maintenance rate is 150% of my normal hourly rate because I can’t schedule it and it’s generally for small amounts of work at a time.