For each of my freelance projects, I note down all the hours worked (on paper). This includes, phone calls, emails, minor changes, CSS debugging etc.
At the end of a project I look back and work out how long the project ‘actually’ took – as opposed to how long I thought it took. Here’s an example from a recent project.
This project was a freelance project for a well established brand, it involved a simple design and a static HTML/CSS build.
Where the time went
- Submitting/Proposal/Getting the job: 1 hour
- Communication/Project management: 1 hours 20 minutes
- Design work: 2 hours 25 minutes
- HTML/CSS templates: 1 hour 35 minutes
- Setting up test server: 20 minutes
- FTP: 15 minutes
- CSS Testing: 2 hours 25 minutes
- Invoicing: 15 minutes
Total time: 9 hours 35 minutes
Why was so much time used up?
After the design was first submitted, some minor changes were required – this is standard practice, but every single client change requires vigorous checking in Internet Explorer 6 and 7. This is because a minor edit can cause a major upset. Changes also need to be uploaded via FTP – now you can do other work (or walk away) whilst FTPing files, but it is still work that has to be monitored in case of problems.
My CSS testing also factors in the time taken to boot-up Parallels – and how slow my Mac performs when running Windows on Parallels.
Summary
When I worked out the total time I’d spent on this project, it shocked me a bit. This project seemed quite small and seemed to get finished very quickly, but looking back, it took a long time when all the work was factored in.
I don’t (explicitly) bill by the hour, instead I bill for the value of the project scope – this means I can get bitten if a project takes longer than I anticipated. If I’m sat debugging CSS for an extra 2 hours than I had planned for it can be very frustrating.
My advice (for myself), always over-estimate how long everything will take.