This is the eighth post in a series called Y U No Tell me; Lessons learned from building a WordPress development business. For a list of all posts in the series, please start here. We're just over half way through the series. To make sure you catch 'em all, be sure to sign up to receive my posts directly to your inbox.
I'm going to let you in on a secret, everybody everywhere is terrible at estimating how long something is going to take. Call it blind optimism, but we all believe we can get things done quicker than we actually can.
Guess what. You can't.
When we're getting ready to go out to dinner, if I ask my wife how long it's going to be before she's ready and she tells me 15 minutes, I know I've still got time to binge watch another episode of Game of Thrones. Conversely, if she asks me how long it'll be before I'm done working for the day and I tell her “about an hour”, she knows she probably has time to paint the house. But I digress.
Assuming you charge by the hour, this can be a serious issue when you're trying to figure out how much to tell the client a project is going to cost. The problem gets compounded when you aren't the one doing the work. You estimate that it'll take YOU X amount of hours to do something, but how about if you're estimating the project and somebody else is going to be the one actually completing the work. Will it take them twice as long as you estimated? Will the project still be profitable?
You might even try bringing in the developer and ask them how long it's going to take to build. But now you need to be careful because they're going to be wrong, too. If you're lucky, over time you will see patterns in your staff's estimating. One guy is consistently 20% under, one guy is always 30% over, and yet another is all over the map. If you're able to figure out a pattern you can adjust accordingly. Until then, it will remain a painful process.
Just so we're clear, this isn't just a problem when it comes to billing. It's just as big of an issue when it comes to scheduling. If you expect a project to take roughly a week to finish, you might line up the next project to start a day or two after. If the first project takes an extra week or two to finish, you're that far behind on the next project before you've even started.
Easing the pain
One solution to the craziness of hourly estimates would be to do as my friend Chris Lema suggests and switch to value-based pricing. I would write more about it, but it's not something we do much of and Chris writes about it so much better than I ever could.
At 9seeds, what we have done to get better at estimating projects large and small is to break them down to the smallest parts possible. And it all starts with a spreadsheet.
On the spreadsheet we start by creating sections for each group of tasks that needs to be done. Typically that will look like: Site Design, Theme Development, Site Development, Testing & Project Management.
Instead of having a single line-item that reads “Theme Development: 24 hours”, we might break it down like this:
Home page template
Single page template
Post archive template
Single post template
Header
Footer
etc…
Next to each line item we have a number of extra columns: Low estimate, High estimate and Notes being the most important. The first few lines might look something like:
| Item | Low | High | Notes |
| Home Page Template | 6 | 8 | 2 custom widget areas, 4 meta values for entry by client |
| Single page template | 2 | 4 | Sidebar with 2 widget areas |
This method has several benefits. For starters, it's much easier to have somebody else come in after you and double-check your estimate. They can look at a single line item and have a good understanding of what needs to be done based on the scope document making it easier to tell if your estimate needs adjusting. Then, once you've landed the project, the line items in the estimate doc can easily be converted in to a list of tasks for your team to complete.
Does this mean we get it right every time? Of course not. At the end of the day, creating estimates is still one of my least favorite parts of the job. But all I can do is try to make the next one I do better than the previous one.
Do you have a method of estimating projects that works well for you? Share it in the comments below.
Don't forget to sign up for to receive these posts directly to your inbox. In tomorrow's post we'll talk about distractions.
I want your spreadsheet! Or an example. JB told me to kick rocks when I asked. =)
I’m loving these posts, btw. An ebook. You know. That would be rad.
haha, that JB is a bit of a jerk, isn’t he?
Glad you’re liking the series. I’m enjoying the process. And an ebook has crossed my mind as well. Thanks!
Nice. This is exactly what I do! But don’t forget to add in the time to talk to the client, coordinate staff, and any onsite meetings (plus travel time and expenses). The project cost is not just the dev/design time. Then add 10-15% for whatever random holdup/crisis/revision that WILL occur!
Both in hours for billing and in when to start the next project. Keeps the sanity.
Amen!
That’s a fantastic point, Heather. There’s always going to be revisions and bumps in the road. You can either add some padding to handle them, or set the expectation with your client that revisions need to come in as a separate work order and will be billed outside the original estimate.
Estimating is a very specialized craft. Thanks for writing about this John. If people are looking to spend their time learning something, this should be a priority.
Absolutely, Wes. Somebody should do classes just on the art of creating estimates.
Yes. SOMEONE should. 🙂
Very interesting post and estimates are a challenge. The main challenge is estimating how much it will cost you to create something and in turn how much value the person is going to get out of the work you do.
I usually do something similar to what you describe on my estimates (ie. how much will this cost me?). Then, I make sure to look at it and think if that matches the value that the customer is going to receive. Related to this is how much the customer’s budget is for the project. The best projects are the ones where the value created is really high and your costs are much lower. Evaluating which projects reach this goal is valuable.
The value-based pricing approach is something that my friend Chris Lema talks about a lot. It’s just another level of pricing/estimating. Much of the estimating process is about getting to know the client and the project inside and out before you ever get to the estimating phase. That’s something than can be done when the overall project size warrants it. But for many projects that we work on, it simply isn’t.
There is definitely not a single right/wrong way to do it. But it’s definitely something we all should be working on getting better at. I know we’re trying.