In Part 1 of this article, I discussed the common reasons why underestimating times for digital projects is such a common occurrence. In this part, I describe how I personally go about compiling estimates in ways that reduce risk to the project, and your business, and increase the accuracy of the estimate, and thus overall profit.
Estimating projects and the occult
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.
The Devil is in the detail: When people say that the devil is in the detail, they mean that small things in plans and schemes that are often overlooked can cause serious problems later on.
Using English.com
I may not believe in the Devil, but I do believe this statement to be as true as it gets when it comes to estimating time for digital projects.
Estimating digital projects accurately
Some would say this is an oxymoron, and to some extent I would agree, but I do believe by applying a few techniques it’s possible to drastically increase the accuracy of most digital project estimates and avoid the feeling of wanting to curl up in the foetal position and whimper helplessly under your duvet.
Confirm a ball park figure
Before you embark on any detailed estimate exercise it’s crucial to immediately confirm with the client a rough budget, or budget range, they feel would be acceptable for an estimate. After all, if you get a new business lead, spend three days estimating and deliver a proposal worth £30,000 only to hear that the client ‘appreciates your response’ but only has £3000 to spend, you probably deserve to be struck with reasonable force in the baby-making department.
When you receive a project brief, throw some figures out there for the client to comment on, only one of a possible few things will happen:
- They will laugh and hang up when they hear your daily rate
- You will laugh and hang up when you hear they want Facebook for £4000
- They will say you’re in the right area but probably need to come down or go up a little bit
- They will refuse to feedback and say “We are open to suggestions”
For these possibilities what the next steps are need little explanation, but the “we are open to suggestions” answer is always the trickiest. In these cases it really is down to you to make a decision if the project is worth the risk of spending time writing a proposal and estimating for. It could be that the potential for new work is huge, or the client is extremely high profile and thus often it’s worth it, however, if you feel none of these are true, you should probably ask yourself what this statement says about the client and if you want to work with them.
It’s understandable a client wants to get their website or web application at the lowest cost, but the best clients are the most professional, experienced and ethical ones and simply know that not providing a rough budget range could waste theirs and your time.
Assuming you have made the decision to pursue the lead, you can now begin the detailed estimating exercise.
Consistent project phase breakdowns
Most digital projects can be broken down into the following high-level categories:
- Research and planning
- Solution design
- Functional specification
- Web design
- Front-end development
- Back-end development
- Content entry
Each individual project will contain unique tasks, but most can be encapsulated in the above phases.
The first step to increasing accuracy of digital project estimates is to make sure you always begin with a consistent set of categories and then add as many sub-categories and tasks as you like.
Get granular, then get more granular
Now your consistent high-level project phases are defined, it’s time to get granular and add sub-phases and tasks e.g.:
- Research and planning
- Requirements gathering
- Project planning
- Solution design
- Sitemap
- Wireframes
- User workflows
- Functional specification
- Design
- The initial homepage look and feel
- Content page
- Master content page template
- News main page
- News item
- Front-end development
- Template x5 XHTML/CSS
- Cross-browser fixes
- Back-end development
- CMS Setup and configuration
- News feature
- Contact us form
- Content entry
This full list of required project tasks can be created based on the pre-sales research you have conducted with the client. It is imperative to nail down, in as much detail as possible, what exactly the client wants before you submit an estimate or begin work.
The more granular you can get, the more you are forced at this early stage to think through each part of the project, literally designing and building the website or application from beginning to end in your head.
By going through the project step-by-step, putting yourself in the shoes of the information architect, the designer and all developers, will often immediately result in many issues rearing their head that you need to clarify before putting in an estimate, take the News feature for example. Ideally you could break each feature down as much as you can, so the News feature may actually end up looking like the following:
- News feature
- Add/edit/delete new item
- Upload image
- Attach PDF
- Auto-archiving
- RSS
By resisting the temptation to just think “News… ummm… 5 hours” and breaking it down to this level means you’re mentally building the feature step-by-step and raising questions as you go.
So the client needs to be able to upload images to their news items, ok, but do they need:
- Auto-resize capability?
- Auto-thumbnail generation?
- Full-screen viewing?
- Caption addition facility?
I’m sure you can think of many more questions that could be associated with a simple upload image for a news item requirement. This demonstrates the possible scope variations that are contained within even the smallest of features and that could impact your estimates / risk of underestimating.
By getting granular and mentally trying to build the solution you are able to identify and address these issues early on, making sure to cater for them in your final estimate.
A Digital Project Manager knows how to design and develop most of the project on his own, even if with poorer results compared to his team. This allows him to estimate projects with good approximation and to understand his team’s problems and difficulties
Introduction to Digital Project Management: Fucina Web
Granularity: Good for the client and good for you
Don’t forget, by getting this granular not only increases your estimations accuracy, but it also gives you the instant ability to remove proposed features quickly if your estimate exceeds the client’s maximum budget! Need to shave 10 hours off the budget? Well, rather than removing the News feature entirely, how about remove the thumbnail and caption adding functionality from News, and a few other small niceties from other features and still allow the client to have the basic versions of all the features they need? Simply remove the lines and hey presto, a new estimate at warp speed and with full visibility to the client of what functionality they’re sacrificing for budget.
Roughly guessing the News feature will take 5 hours is one thing, but what about when the client comes to you after seeing the initial functional specification and asks where the archive section is or how they attach PDFs simply because they assumed the News section they would be getting is like the News section on another website they’d seen?
Getting granular will not always allow you to breakout a required feature in full because it is client industry specific. If you are ever in any doubts about what the client needs, ASK THEM! Take the time to understand their business so that you can fully understand why they want the feature and how it needs to work.
Few clients mind you asking questions, if anything it tends to give them more confidence that you will continue to be as diligent and thorough if they hire you.
Best of all, if you win the work, by getting granular you have:
- An instant statement of work
- A defined project scope
- The timings you need to put together an accurate project schedule with milestones
- Set your client’s expectations very early
- Demonstrated your thoroughness and understanding of their business to the client
By being methodical, transparent and getting granular from the very start means your client is well informed and you’re seriously reducing the chances of friction later down the line.
You won the work w00t! Time to start tracking time
The more projects you complete that are categorised with a consistent set of phases and tasks, the more useful data you can collect on how long you estimated versus how long each phase or task actually took.
Consistency here is the key again. By this stage you should have the final project estimate that was approved by the client, and this estimate should be broken down first into the same high-level phases as your previous projects, and then at a granular level by task and sub-task.
Simply replicate this structure and the time estimates for each in your time tracking tool of choice so that you can:
- See how long you have to complete each phase
- View how long you have for each task and sub-task
- At the end, report on how long everything took
Not only is this a perfect way to track the progress of the project you are working on, but the data you collect over multiple projects, using a consistent pattern, will become more and more valuable when it comes to estimating future projects and also allow you to identify bottlenecks in your project processes.
Analyse project estimates vs. actual time spent
Once you have defined a consistent set of high-level project phases to use when estimating all digital projects, and committed to setting up your time tracking tool each time to match, you are ready to reap the rewards.
By tracking all the estimated and actual times of all past projects, using a consistent framework, will give you an average percentage that each phase and task took, and you can use these averages as a good guide for starting a new estimate.
For example, by collecting data for your past five projects you are able to identify trends like:
- Solution design took around 10% of the total project time to complete and get approved
- Web design 30%
- Front-end development 15%
- Back-end development 30%
And so on…
Using these averages, and with a client’s preferred budget, you can begin to immediately allocate a rough amount of time to each phase and then break out each in more detail, but with the roughly allowed hours available known beforehand.
With this initial capped time limit in place, you can estimate not only your times but also the most cost-efficient solution you can deliver based on the budget rather than going in with a blind quote that may be way to small or too high.
Of course, this is dependent on knowing the client’s budget beforehand, not always possible, but more possible than most seem to think if you just explain you want to deliver the best solution for the budget given that you could potentially offer a News feature that costs £750 or £7,500.
Get granular with features, again!
Aside from being able to determine the average percentage of time each high-level phase usually takes of each project, you can take this tracking and analysis one step further.
How many websites or web applications tend to need a feature you’ve implemented before? Small to medium business websites invariably demand the following functionalities:
- News
- Press Releases
- Case Studies
- Events
- FAQ
- Contact us form
At the estimating stage you will have identified these requirements and broken them down as much as you can. Not only can you re-use these common breakdowns in multiple quotes, if you track the time for each one over multiple projects you will also begin to have average times it takes to implement or migrate each feature – now that’s useful.
In summary
The approach for estimating time for digital projects I have described to you in this article works for me. It’s something I’ve developed over several years through trial and error by having to estimate digital projects of all shapes and sizes in a small web agency environment, combined with a lot of good old fashioned hours of research.
Its methodical, it’s laborious, isn’t a guarantee that a project will not go over budget and I’ve no doubt is something I will continue to develop and evolve as time goes by. But as any digital project manager will tell you, the more you plan, the more chance there is your project will be successful and the same goes for estimating times.
When possible, resisting the temptation to throw some figures onto a proposal and send it off and instead splitting the project requirements into as granular detail as possible can really be a life saver. It not only identifies possible grey areas early on but forces you to think through everything you’re planning on offering the client and to what extent/scope.
It also presents you to the client as someone, or as an agency, who are very meticulous, diligent and thorough in how they approach things and this is often taken as a signifier of how you will approach the rest of the project and this always gives the client confidence.
Finally, by creating and maintaining a consistent pattern of high-level phases and tasks between your digital project time estimates and time tracking means you can collect and analyse reliable data from multiple projects that can help you further increase the accuracy of, and cut the time needed to create, estimates for digital projects.
If you want to read why underestimating digital projects is such a common occurrence, please check out Part 1 of this article.
Sam,
Phenomenally cool article with the perfect amount of depth. The situation of estimation is a tough cookie to crack and I think you’ve done a good job of balancing the hours it takes to estimates vs. the hours you have to estimate.
One friend-company of ours actually has a scoping phase, where the client pays for 1-2 weeks of scoping before an estimate of building is given. What say you about this?
Cheers!
Kenny
Really enjoyed this article (and part one), these are the issues we face every day!
Hi Sam,
This article and part 1 have been really informative! Project estimating I admit is still something I’m working on as a young graphic and web designer myself, so to read about your suggestions after years of practice and trial and error has been a saving grace for me. Thank you for sharing this valuable information!
My only concern with ‘fleshing’ out the project details is how the client may react to it, upon receiving the estimate. Certain terminology for instance, processes, or technologies that they themselves aren’t familiar with opens up what I think would be pandoras box where you then may be bombarded with more questions.
Is this something you have experienced in fleshing out you projects at all? If so how have you managed to inform your clients without having to spend too much time explaining things?
Thank you for your time!
Really interesting article, especially the part about the need for a rough budget. And thanks for the mention too.
Hey all, thanks for the comments, I’m glad the two articles have been so well received :)
@Kenny, I think if in early meetings you have identified that the project is extremely complex, requires very bespoke development or technologies not used before, often making the client realise this for the first time too, it’s a great idea to try and get the client to sign up to an initial paid spec stage. It protects you as an agency, but also is great for the client as it resets their funding and delivery date expectations nice and early.
As a bonus it also allows you to work with the client for a smaller fee/lower risk and determine what type of client they are. If they’re a nightmare through this spec stage it could be an early red flag that means you run away, save yourself a complete headache in the long-run and go win work off some good clients. Either way the client ends up with a spec and you end up better off – everyone is a winner.
@Eleonor, a really good point and something I have encountered before. It should be said, the mega granular breakdown you create is primarily for internal use and perhaps only needs a public viewing if you have to explain to the client why a certain feature is certain price. How you present your estimates to the client is also up to you. As long as you have all the phases, tasks and estimates you can always word it so it uses non-uber technical terminology in your proposal e.g. Solution Design could become Planning and Back-end Development could be called Technical Build etc.
Super article and one I’ll have to read again. It’s all too easy to allow internal and external stakeholders to push you into providing estimates quickly, but as I’ve learned many times over, it pays to keep them at bay.
Granular – that’s going to be my new word!
I can admit to no rights over the word Cola, feel free to use it whenever you want – a backlink each time would be appreciated each time however ;-)
Ah – a great article, thank you. Highest good advice:words ratio I’ve seen in a long time!
Hi Sam – great post which has circulated our entire agency. I only had a chance to read it quickly but one thing I would possibly add to the project breakdown is “Testing”. It’s something we have been guilty of under-estimating in the past but it is so crucial that you provision time for this.
Some clients will question why they have to pay for you to fix your own mistakes but they would probably also question why they need a project manager etc. The good clients accept methodical testing as vital and want to pay for it so it’s done thoroughly.
@David, thanks, I hope it helps!
@mr_mcd, I’ve always found the row “Testing” is rarely completed as a single project task because so much of it happens as you go.
I will generally add browser testing as a separate row, but often include functionality testing time as part of the total estimate for each feature. This way the budget for that feature caters for going from nothing to it being 100% complete and tested.
However, the amount of times a feature is complete and tested, but a subsequent feature breaks it… really hurts my head.
Nice article.
I’ve toying around with the granular thing, but the suggestion of using a consistent set of top-level items which makes it easy to track among different projects is really good.
Thanks for this article – it’s the best I’ve read on this process. I’m off to tweak my project estimation and time-tracking categories now!
Hey Bright and Sijmen, really glad you liked this post and even happier you’re off to tweak your estimating processes Bright :) It takes a few projects to really gather some useful data but it usually reveals some pretty surprising results!
Damn you Mr. Thesambarnes.com!! I could have done with this article about a month (or 12) ago! ;)
Having run my own freelance *thing* I know how hard it is to estimate for a new client… You’ve done a fantastic job with this and I have found myself nodding with a resounding “yes” to all the points you brought up in Part 1.
Thanks for your granular tips, I’ll be sure to double check this list for the next project! (as i am a designer adapting to development).
And I’ll also take note of @mr_mcd’s point on testing, which I think takes up a lot of time when learning/using new technologies.
Great stuff! Thanks again.
Bren
@Brenski, pleased you liked the article. I wanted to write it 12 months ago too :)
Testing is defintely one that’s often overlooked yet takes up time… I’m now trying to incorporate this into my estimates and schedules as separate line items. Will see how it goes and maybe write an article about it in 12 months ;)
Does anyone else find it hard to get a client to pay for testing I wonder?
Hi,
Thanks for some very interesting and useful articles.
I am webdeveloper at heart but working in small teams and sometimes freelance I am often faced with doing the estimates myself.
I am rarely sure how much text to write for each feature and how technical I should get.
Therefore I am curious if you perhaps could show how you layout your estimates. Perhaps you have a template document you use or just some basic ideas?
@sam
Luckily I’ve subscribed to your 12 month RSS plan… what a bargain! ;)
On a heavier banknote… I believe clients would generally think you know your stuff and *therefore* spend minimum time on the testing front (caveat: unless you’re doing something outstanding and awesomely new!).
From my past experience ‘learning on the job’ has always added too many hours to justify the price. I’ll let you know when I’ve conquered this catch 22…
@bjawnie, I tend to find that the most economic way to define functionality when working in a small business is to try and write it so:
* The client gets a good idea of each feature will do (and what it wont do in order to define some kind of boundary that can be cited in the case of scope creep)
* A developer can understand that aim of the feature and see any detail they need to in order to build it
* Allow a designer to understand what elements need to be included in that feature
It’s not ideal as it tends to lack a little detail for each party, but when time is precious and you have a load of work on, it serves as a good platform for the client to sign-off and for your team to get started on production…
As for templates, I’m afraid I’d be slapped on the behind by Rawnet.com if I started making mine available to the world ;-)
@Brenski, if a new technology needs to be learnt, the ideal strategy is too learn it and don’t charge for it the first time, as long as you make it a mission to resell it and recoup the time/money over time…
It does seem web project management is full of catch 22 situations though doesnt it!
Thanks for the pointers.
Great article, as a freelancer I’m on that way too.
What I feel really hard to do is not that estimation, as it’s necessary to get the client, no, what is hard for me is to count time spent on the project as it starts : what time is it ? Okay, i start the print style sheet at 11h05. And at 6pm, as I’ve finished the news feature of another client i’m wondering at what time a finished that printing stylesheet this morning…
But it shouldn’t be a problem.
A progress I’ve made in my estimations is including a lot of actions that we allways forget :
– time to do the estimation,
– time to write all those e-mails you’ll send to the client to inform him on the running project,
– time spent to produce the bill, to the check the payments,
– time to do the archive of the project, with a nice illustrated CDbox…
– money spent in printing the specifications provided by the client…
The master key is really granularity, as you explain it, and stick to the estimation to immediatly see that you’re going off what’s planned ands try to correct it asap.
@McBenny, it sounds like most of us you’ve learnt the hard way how to get those estimations and actual times more aligned. I guess the granularity doesn’t stop at estimating, but it should continue into your time tracking too.
So when start your time when you start that print stylesheet, and stop it when you switch… it’s a tough thing to stay disciplined at, but if you can manage it until it becomes second nature then you have an excellent additional set of business data to further increase your accuracy!
Sam, I love this article, but am leaving a little confused. According to your “What makes a great account manager” posts, I thought that writing proposals was the job of the Account Manager. Are you wearing two hats when you estimate jobs or is the time estimation left to the Project Manager and then inserted into the Proposal written by the Account Manager? (Can you tell we are a small company working on our processes in order to become a bigger one? ;))
@Jesse, it really depends on the company you work at. At larger digital companies you’ll often find an account manager writing proposals and seeking your guidance on technical details and estimations, but at smaller agencies a Web Project Manager has to wear about 15 hats and they include all pre-sales activities like proposal writing, estimating and running the project itself!!
This is a great article and I’ll definitely be incorporating some of the advice into my own processes, but the question I’m struggling with right now, which is how I found this article, is you’ve been given a budget for a potential project and you think it might be possible to achieve it within budget but you’re not sure.
To know for certain, you’d need to spend more time getting the granularity of information you’re talking about, but that process could end up requiring a significant amount of time, and at the end of the process you might find that the total budget doesn’t cover it, or that the client opts to go with someone else anyway.
So I’m wondering if there is a way of covering yourself for that initial discovery phase if the result isn’t in your favour, or is that just a cost of business you have to accept?
@John, this is a situation I’ve faced a few times in the past. The approach I took depended on the client and project in question…
If the client was massive the long-term benefits of winning this project were significant, I’d possibly do the requirements work for no charge – but of course it depends on how your business is doing right now, just how much time you think you’d need and how valuable the client could be.
Alternatively I’ve been very honest about this fact with the client and proposed an alternative approach – to be paid to do the requirements gathering and sitemaps, functional specification etc. as a piece of work.
The idea being that this work will need to be done regardless of who the client awards the web project too, and it will also allow the client to ensure they’ll be getting the solution they want and for the best cost possible (given any agency quoting would unusally have a full specification to refer to when estimating)
This not only works for the client but also can work for you. During this phase you can assess if you actually want to work for this client on the web project or not… if they’re difficult during the spec phase, once paid up you can walk away if you want.
But on the flipside so can the client from you, but if you’re smart you’ll use the spec phase to build a rapport with the client so that they hire you for the full job, or at least hire to consult on the hire of a new agency.
As far as factoring in the discovery phase into a web project quote, all you can really do is use instinct and put a number against the phase – if you win the work, the Web Project Manager should then immediately begin to set expectations of the sold hours – if it’s looking like a lot more time will be needed, they should tell the client and try to negotiate more budget – easier said than done but if the client is handled correctly from day one, it’s not as difficult as most think!
Thanks Sam. I was thinking about the possibility of asking to be paid for the discovery phase but I don’t have a lot of experience in this area (I’m a freelancer that mainly subcontracts for other agencies) and I didn’t think the client was likely to go for it given the budget he’d mentioned.
@John, ahhh being a freelancer does bring with it a whole new problem in this situation – a paid spec phase is easier to sell when a company will being doing it rather than one or two people…
And yeah, low budgets often indicate they won’t go for it, but if the budget is low and you feel after sounding out the project it will require a big ole spec phase, it could possibly be a a case of unrealistic expectations from the client.
If possible work with them a little longer to try and propose more cost effective solutions, or maybe walk away?
Yeah I went for the second option in this case. It’s a bit of a vicious circle when it comes to doing paid spec work as a freelancer: because you don’t often get the chance to put that forward as a proposal, it’s harder to get experience in that area, which makes it harder to win those sort of proposals due to that lack of experience.