on developer

How I Estimate Web Development Projects

Do you know how to tell a web developer that comes straight from university from someone who has years of experience in the business? The new ones can not estimate time on tasks at all. The experienced ones sucks a little bit less, and gives you an estimate that can be multiplied by 2 or π to get a somewhat correct guesstimate of what the real effort might be.

I checked my estimates for the last three years, and they are pretty much spot on. How come I and other seasoned developers can correctly estimate the time required to build a web app when most new developers can not?

Here are my short rules that I use to estimate most software projects. Note that most of our projects are between 25 and 500 hours, so nothing really huge - it is small to medium size projects in our market.

Don’t experiment on client projects

This is a big mistake that most new developers do. When you hire a carpenter or a car repair guy, do you want them to try out their newest experimental tools that they have never used before? If things take twice the time just because they are experimenting, do you as a customer want to pay double the price of a regular exam?

Side projects are for trying stuff out. Not client work when someone (client or employer) pays you by the hour.

There are of course some exceptions to this. Some clients are willing to pay you to experiment, but that is a whole different thing.

Start by estimating what you have already done

The longer you have worked in the business the more things you have done in the past. Take advantage of that knowledge, and start your estimates by writing down your estimated times for the tasks that you already have done before.

Estimate what YOU will do, not what others will do

Estimating for other people without their written consent is generally a bad idea. Will you do all the coding yourself? If not, get an estimate from the other people involved.

If someone struggles late in the project, they always blame the estimator first, then the client. Make sure everyone estimates their own part.

Look at the history

Your first estimate will probably not be perfect, but every failed estimation should be an opportunity to learn. Compare with your past estimates, or ask your colleagues if they have done it before.

Was it successful? Did it feel rushed? Did we learn something that we could re-use in this project?

Estimate in hours, days and week

My estimations normally are grouped in to the following time groups:

  • 1 hour
  • 2 hours
  • 4 hours
  • 8 hours (one day)
  • 2 days
  • 3 days
  • 1 week (40 hours)

For tasks that take less than one hour I group several small tasks together. I never estimate tasks longer than 1 week, because it adds too much uncertainty, just divide it into several smaller tasks.

Don’t forget communication and meetings

Generally about 10-15% of your time will be spent communicating with the client. Sometimes I have a specific bullet point on my estimates for this, sometimes I just round up all estimations a little bit to make room for communication time.

Plan for bugs

Customers don’t like to pay for bug fixes. You can make your customers feel much more content with your time spent on bug fixes by planning ahead and make room for them in your estimate. I never write out ‘Bug fixes’ in my estimates, but instead make a little room for this in each task, just like I do with communication.

Plan for deployment

Coding your web app and putting into production are two completely different things. Make sure you allow time for setting up the server, backup and other deployment related tasks.

Sketch it out

Describe the user interface with pictures and words so that both you and your client are happy with the result on paper before you begin coding. Most of the time I do this before even estimating. For larger apps I charge for this as ‘software architecture’ but for simpler projects like websites I normally see it as a part of the sales process and do it for free.

Sometimes I ask the customer to do this for me, and make revisions to their work instead.

Describing the end result in this way with pictures and words both make the estimation part easier and also eliminates lots of the ‘This is a Bug!’-discussions that can arise if you don’t share a common view of the end result.

I’ve had some projects that ended directly after the sketch phase because the client realized that they had not thought the whole app through. Good for both of us. I always want to exceed people’s expectations, and I can not do that if I don’t know what their expectations are.

Keep the estimates close when you are working

Print out a copy of the estimated times and keep it on your desk, or write them on Post It-notes à la Kanban/Scrum if that is your thing. I always try to be conscious about the estimated times on my projects, and aim to do it in about 75% of the alotted time.

I’ve seen colleagues just work through the whole project and then compare their estimate with the final result and go ‘Oh, shit - this took a lot longer than I expected’. Of course it did. You did not work through your promises, you only tried to solve the problem.

The proposal is your promise to the customer. I know it is only ‘an estimate’, but if you keep estimating wrong all the time your clients will be angry with you.

Follow up

After the project, always write down how your estimate compares with the real time spent. If you don’t do this you will never learn to become better at estimating software projects.