A good foundation
After reading Alyssa Gregory’s recent article on Sitepoint.com, How to Estimate Time for a Project, I couldn’t help but feel that it was a good introduction but lacked a little when compared with the realities and complexities of estimating/quoting for a website or web application.
But before we look at how to create more accurate estimates for digital projects, it’s important to look at the reasons why this area is such a difficult one and why digital project management forums aren’t exactly littered with posts entitled “How can I stop completing digital projects on budget?”
Why underestimating is so common
There are many common reasons why digital projects are often underestimated by freelancers and web agencies alike, they include the following:
- The technologies required have never been used before
- Large parts of the project are grey areas at the time of estimating
- The features needed are very specific to the client’s industry and thus bespoke
- To break the project down into the detail it would require almost as much as work as the paid for requirements gathering phase
While almost all digital folk will admit to these points being common reasons why it’s difficult to estimate time for digital projects, there are a few that will admit to the following that are just as true:
- No previous project ‘estimated vs. actual’ analysis has been conducted to draw on
- The client needs an estimate for their large project tomorrow
- The revenue needs for immediate cash flow now outweigh the effects of no new business now
- Estimating time for a project is not fun
I am no different. At one point or the other I have cited the valid public reasons but also fallen foul of the not so public ones; this is the reality of working as an insanely busy freelancer, or in an equally busy web agency, just trying to keep your head above the water financially.
However, there are few worse feelings in this industry than getting to any point in a project and realising you’ve grossly underestimated the time, it’s a bitter taste you don’t forget in a hurry and should strive to avoid again.
So why does it happen time and time again?
The day-to-day reality
The approaches to creating more accurate estimates for digital projects that I will describe in Part 2 of this article explain how to combat several of the common reasons for underestimating. I personally use them to track time on all projects and use the data gathered when estimating new ones – the results are very positive indeed.
However, as you can see below, it doesn’t resolve them all:
- The technologies required have never been used before
- Large parts of the project are grey areas at the time of estimating
- The features needed are very specific to the client’s industry and thus bespoke
- To break the project down into the detail it would require almost as much as work as the paid for requirements gathering phase
- No previous project ‘estimated vs. actual’ analysis has been conducted to draw on
- The client needs an estimate for their large project tomorrow
- The revenue needs for immediate cash flow now outweigh the effects of no new business now
- Estimating time for a project is not fun
So what can you do to combat each of these realities?
Technologies have never been used before
If you are estimating time needed to implement a solution using a technology you have little or no experience of, you will have to conduct some basic research and then just guess! Alternatively, try to negotiate a smaller fee with which you can conduct the first stages of the project in terms of research and putting together some kind of high-level specification for the project.
At best, you learn a new technology, build a rapport with the client and win the remaining work. At worst, you’ve learnt a new technology, you’ve generated revenue and the client has a good specification to update its project tender with.
Detailed estimation exercises take too long
My personal approach takes time, much more than the traditional method of providing an estimate purely based on both experience and instinct. What if you spend hours or days putting together this detailed quote, breaking the project down perfectly, and then don’t win the work. Is that a loss of opportunity on another potential sale? Does the client now have a free detailed breakdown for free?
Well yes, but this is just how it goes in any sales situation. Is it wasted work? Possibly, but it’s also possible you have researched a new technology or broken down a feature you haven’t used before. What’s to stop you trying to sell this to existing or new clients if it aligns with their long-term business aims?
Client needs estimate for large project tomorrow
If a client needs an estimate for a large project tomorrow, please refer to the ball park figure section in Part 2 of this article. Try to confirm a ball park figure and then assess the potential gains to your business versus the possibility of underestimating this one project. Always bear in mind, the larger the project, the greater the likelihood you will underestimate and the potential loss you could incur by submitting a low estimate.
Business revenue needs
Revenue needs of a freelancer or small businesses for cash flow is an ever present issue. A typical dilemma faced is:
- We need £20k in revenue this month to sustain the business
- Client is offering us a maximum of £10k now and we don’t have many other leads
- We feel their project will cost a minimum of £15k
- We can walk away now and not lose £7k, but also not make £10k
- We can take the project on and try and do it for £10k
- We can take the project on; accept the £5k loss, break even and live to fight another day
This quandary is the reality of running a business and just one of the daily tough decisions a freelancer or Managing Director has to make, I don’t envy them. What to do in this situation is entirely the business owners decision, all you can do is get accurate information to them so that they can make as informed a decision as possible.
Estimating time for a project is not fun
Well never has a truer word been spoken. Despite taking so much pride in it, and also testing new ways to improve accuracy, it’s not often a person will love the process of compiling and delivering a project estimate (if you find one, grab hold of them and lock them in your office!).
Let us speak plainly my friends; the following facts are true when it comes to estimating digital projects:
- It’s hard work and takes you outside your comfort zone
- Forces you to predict the future
- Usually has to be completed alongside your plans for your already fully booked week
- Makes you largely responsible for the:
- Sales success
- Solution offered
- Eventual profitability of the project
- Growth/survival of your business
With all of the above being truisms that I believe most people who have to estimate digital project feel, the scary truth of the matter is getting it wrong just a few times can leave a freelancer or small web agency in real turmoil.
Identify then fix
For all of the reasons stated above, getting people who are primarily from a creative or technical background and more passionate in actually creating something, to really spend time on developing a solid and reliable digital project time estimating process is quite difficult and understandably so, it’s just not sexy work.
But, especially in these turbulent times, being able to identify any gaps in your entire digital project management workflow that (incoming buzzword bingo phrases) minimise project risk and maximise project profit should take a front seat, and the digital project estimation phase is the most crucial in achieving these aims.
In Part 2 of this article I will go into detail about how I personally go about estimating time for digital projects, both on an individual project and long-term multiple project basis, that combats the remaining common reasons for underestimating.
Nice post! I’m a big fan of making project estimates… actually, I just find the topic really interestingand am always amazed at how quickly and carelessly people rush through this critical phase of a project. Probably the best book I’ve read on the topic is Steve McConnel’s “Software Estimation: Demystifying the Black Art”. I look forward to reading part II!
-dina
Interesting post, Sam. I’m spending the next few days planning/estimating a project and as its the first large internal office one I’ve work on (as opposed to client-based) the time estimate is really, really important. I’m not familar with the book Dina recomends, but I do delve in and out of Catherine A. Tomczyk’s “Project manager’s spotlight on planning”. I’ll be watching for Part II!
Why do I feel this is solely aimed at me? Roll on Part II.
Nice post! I like your theme!
I take some comfort in seeing that it isn’t just me! This is spot on so far.
Great Article. For me, estimating is the most hated part…JESUS. I realy hate it…
Thanks, looking forward to the follow-up!
Thanks for the comments guys! @Dina & Cola, I may have to check out them books, a black art it sure is!
@Danny, this post will probably make many feel it’s aimed at them because they know, like me, they’re guilty of taking the short route to compiling a quote from time to time ;-)
@Mike & Kathi, believe me, it’s as comforting to know I’m not alone too!
Great post padawan! Estimation is such a dark art and so rarely are the benefits and pitfalls illustrated so lucidly.
One of the things that makes estimation so difficult, and one of the ways that Agile methods excel, is that the person doing the estimation frequently has scant understanding of the rate of their team’s productivity. Agile cracks this by doing all estimation internally using a points based system and then measuring the team’s productivity, or ‘velocity’, over time. This gives a project leader an empirical measure of what can actually be achieved within budget.
The real benefit of having your team estimate using a system of sizing points vs hours/days, is that it removes the emotional dimension from estimation. Workers can get a gut feel for the ‘quantity of effort’ without having to acomodate unknowns like interruption, etc. We all know how inaccurate a proud developer’s estimate can be, and how charmed our boards/clients are when those estimates turn out to be works of fiction.
Great work. Can’t wait to read more.
I would echo the part about using a ball park figure if estimates are needed very quickly. However, I was taught that giving a range is better than giving a figure. In other words if I say the ballpark is approx £15K that is fine but the figure 15 tends to get lodged in the subconcious. It is better to say the range is approx £12K-£18K which as well as not fixing a particular figure, also gives an idea of the confidence in your estimate.
@Richard, you’re right about getting a range. Often I’ll start with asking what kind of budget do they have, and if there is even slight hesitation to answer I’ll then ask for a range instead.
Good point, much better than mine in my article :)
First time on your site. Really like what I am reading, moving on to Part II now. You now have another fan!
@Paul, thanks for your comments. Hope I didn’t lose you after Part II :)
No, I managed to keep up! My problem is that I am with an agency that has a strong off line and design pedigree. Getting peeps to think in terms of functionality and content first rather than design first is a real challenge. Most jobs are sold on a few visuals and ball park quote which fits the budget. Not great with you find out when you find out – to use your phrase – they want facebook for £4000!
Great Article Sam! Such an important issue for Freelancers. Looking forward to part II
Glad you like it Andrew :)
For complex projects, many of our clients prefer an hourly quote.
This is better than 98% of all articles out there on project estimating. Thanks for speaking the reality.