Creating proposals with fixed budgets can be a big challenge when it means estimating how long it’s going to take to create something that’s never been created before. By breaking down the project into smaller chunks and figuring out how long each chunk will take, somehow we arrive at the number of hours needed. But what exactly are we basing these numbers on, other than our gut instincts?
Humans aren’t the best at estimating required time
It’s logical that predicting how long it will take to do something you’ve never done, is actually really hard. Check out this great answer on quora that uses the analogy of a long hike and finding many unexpected obstacles along the way to explain why software development task estimates are usually off by a factor of 2–3.
However, for projects similar to ones you’ve done in the past, you can usually give some reasonable estimates based on your experience of working on those tasks before. But if you don’t track your time carefully when you first do a type of project, it’s still just you pulling a number out of a hat.
You can use a tool like RescueTime which is a great free web service plus Mac utility that logs how long you spend working in different apps or on websites. A pro version adds the ability to track specific document titles. So inserting “MC>” or some other client code into each document file you’re working on would let you easily total up all the time spent working on client documents.
Of course, apps like Billings Pro have widgets to start and stop timers on slips, letting you easily track work for projects too.
Create detailed estimates
Once you’ve done a certain number of similar jobs, it becomes much easier to be aware of everything that goes into it. Going through the entire process of making something or delivering a new service always reveals several details you initially overlooked.
Break down a project into it’s component parts and create estimate slips in Billings Pro for each part, estimating your hours as best you can. This will be totally different for industries, but as an example if you were in the business of creating websites it might look like this:
- content strategy: 24 hrs @ x rate = $CS
- IA / UX design: 32 hrs @ x rate = $IA/UX
- development: 52 hrs @ x rate = $dev
- testing/QA: 16 hrs @ x rate = $QA
- social campaign: 20 hrs @ x rate = $social
So on your proposal you’d include an estimate from Billings Pro that shows just the total price, or grouped into more general categories, or a complete breakdown in a table, depending on your sales strategies.
Estimated vs. Actual Time
Then, after you’ve won the job, take care to create working slips as you progress through different tasks. Again, you can use RescueTime to go back and find any hours spent in an app if you realize you forgot to start the timer.
Then, to see a comparison between your estimated and actual time spent:
- go to the Reports section, found in the Billings Pro sidebar, and select Estimate vs. Actual in the Project folder
- Select the name of the project from the Project: menu
- click on the Run button in the lower right hand corner
note: this report will only calculate the actual total after you’ve invoiced the slips. Create an invoice and re-run the report if you are seeing $0.00 when running it.
If there’s a big discrepancy between these numbers, then you need to look into the hours in more detail to see what accounts for the differential. The reasons will either be on your end or due to client requests.
If you defined the scope of your project clearly from the outset, this should be pretty easy to figure out. If there were additional requests from the client that caused extra hours needed, or if they were due to way too many feedback cycles for stuff that was in scope, well then you need to decide if it’s enough money to add those charges on to your original estimate, or at least have a discussion with your client about the additional time spent.
Some of the difference in time will no doubt be due to your own mis-estimating about how long certain tasks will take. Debrief with your team and see what exactly went into those extra hours. It could be unforeseen problems with the tools you depend on were the cause. Or during the process you found a much better method and it made sense to adjust and re-factor you approach. Or perhaps simply because the road was longer than you thought. Again, sometimes you can’t really have a full appreciation for what goes into making something until you’ve made it.
In that case, take note of the difference in hours estimated and calculate the difference as a ratio (i.e.: if estimated is 10 hrs & actual is 13 hrs than ratio = 1.3). If you have a template for creating budgets, adjust it now with that ratio to account for that “unknown” factor for that line item. Do this for any other tasks that have a variation between estimated and actual hours, also for any outside suppliers you rely on. That extra bit of headroom next time around should help keep your profit margins on target. Doing this for each project will only make your adjustment factor more and more accurate as you get better at estimating and the sample size increases.
Use data plus your gut to get better at estimating
Humans are generally bad at estimating. Track your time carefully and compare the actual numbers to your estimates to see how you need to adjust your proposals for future projects.
