How I take the uncertainty out
of fixed-price projects
Daniel Howells
Spend enough time with freelancers and you’re likely to hear warnings against charging one total cost for a job. Fixed-price project proposals can be easier to ‘sell’ and bring less risk to the client, but the freelancer can fear ending up working for free for weeks (or months) because of all sorts of variables and unknowns. Yet despite this, after almost a decade of freelancing, the majority of projects I undertake are still quoted on a fixed- price basis.
Why do I do this? I quote a fixed price because I’ve been obsessively tracking my project time for as long as I can remember, and it’s taught me a lot about how I work, how long things really take, and how to produce a bang-on estimate that ensures I’m being paid fairly for my time.
Seeing the value of time tracking
Early in my career I worked at a variety of client-services companies. Without fail, every Friday at 5pm somebody would appear from nowhere and sheepishly remind us to complete our timesheets. The request was always greeted with protestations, since trying to remember what we’d done that week and wrangling their archaic time-tracking app into submission was never a more exciting prospect than being in the pub for Friday night drinks.
The issue was that these numbers never had any meaning to me. For the most part they were plucked out of thin air, and never taught me anything about how I worked or how I could improve. But the moment I transitioned into my freelance life, there was a difference: the numbers were relevant. The 30 minutes doing one thing for one client and two hours doing something else for a different client suddenly made sense, and revealed that I was either managing one project very well, or another one very poorly.
How I track my time
When I started freelancing, I broke my time down into a detailed list of tasks:
A detailed list, I know, and probably verging on the obsessive. However, this level of detail was enough to give me visibility as to what I was actually doing on a project.
To measure my time, I simply used the stopwatch on my phone and logged it in an invoicing app after I finished each task. When I completed a project, I could see exactly how and where my time was spent, and this showed if I went either under or over my fixed-price proposal.
My working day is typically seven hours, give or take half an hour. On an ideal day, the sum of time I’ve dedicated to project work should land somewhere around that mark. If by the end of the day I’ve logged only a measly three hours, clearly I’ve wasted far too much time on Twitter or Reddit. The next day I’d hope to make up this discrepancy, but thankfully the cold hard numbers encourage me to be disciplined enough to only slip a few times a month. If I went over the hours I’d proposed, well, that meant my next proposal for a similar project needed to be adjusted accordingly.
What I’ve learned
With all this gathered data to hand, what did I learn?
My design time varies much more than development time. Working in both design and development, tracking my time made me realise that there can be huge variances between different types of tasks even though two projects might be similar. Because design is so subjective, I found that I would spend a lot more time to-ing and fro-ing with the client on design changes, whereas development is more objective and usually doesn’t normally overrun.
I could use my historical time information to more accurately build contingency time into my proposals. Fixed-price project work is usually criticised because the only way you can be certain of not losing money is by padding the proposed cost out with extra hours, days, or weeks just to make sure. That is indeed often the case but adding in a contingency of time isn’t deceitful, it’s just good planning; remember that a benefit of the fixed-priced project is that the client only has to deal with one number, and if it works within their budget, its composition is moot.
Having archived project records right there to refer to makes it considerably easier to quote and plan for contingencies. My projects are typically consistent in nature; normally the design and development of a website. There are variables, of course, but for every new project I’m always going to have a past project that’s similar in nature. Using that as a base, I’m able to cost up my proposals far more accurately than pulling figures from thin air.
I’m getting faster over time. My timing data also revealed some interesting trends. I’m neither a formally trained designer or developer, but I have noticed that over the years the time I take to design a site, or develop responsive templates, has decreased, either because our tools are getting better or because (I’d hope) I’m learning and becoming more proficient. That’s perhaps predictable, but seeing the information in front of you is very motivating and rewarding.
Refining the time tracking process
Translating the results of your time tracking into