Estimating Time For Digital Projects More Accurately: Part 2

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, 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.


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.