At some point in your career as a web developer you will grow tired of being outrageously wrong in your estimates of time required to complete a project. There are two responses to this: (a) fervently adopt a form of Agile development that rejects the entire concept of making a good up-front estimate on an entire project, or (b) establish a method of estimating project completion time that works for you. For my part, I think option (a) is more in the way of a coping mechanism than a viable path forward. It's running away from a challenge, and you'll never get anywhere if that becomes your dominant strategy in life.

When I talk about a method that works for you, I mean "will not cause undue embarrassment" - you won't wind up with a project that turns out to be half or twice as long as the original estimate without advance warning and a clear understanding as to why it happened. You will certainly have projects that drift in time elapsed by 10-20% in either direction without clear reasons, and it's your responsibility to make that potential outcome understood to the client. An estimate is exactly that: an estimate. It can be good, but if it nails the end result exactly on the head ... well, that was pure chance, not skill.

At the end of the day, development estimates are as much about making the client comfortable as they are about enabling everyone involved to better plan time and finances. Thus your estimation methodology has to be transparent and based on simple inputs that can be quickly explained to - and understood by - a non-technical client. Understanding is comfort when it comes to affairs of the checkbook.

The Skeleton of the Method

1. Create a page diagram of the website you will be building.
2. Count the pages. Modifying an existing page counts as half a page.
3. Multiply the page count by a factor of 2, 3, or 4, depending on the technology used and and the quality of the development team.
4. The result is an estimate for the number of developer days the project will require to complete.

1. Create a Page Diagram

I am assuming that you already have a rough outline of the website in hand: it may be a list of features, a vision in your mind, or an actual specification document. Now pull out pen and paper, Visio, PowerPoint, or the GIMP and get started on your page diagram. This is just a set of labeled blocks joined by lines, where each block is a web page. An image is worth a thousand words, so here is a small example:

I find laying out a diagram like the example above - but usually much larger and more annotated - to be a very helpful part of the early development process. This is true whether or not the results are used in estimation of project length. Establishing an initial visual inventory of the web site to be built makes it easier to (a) talk about user experience scenarios, (b) identify features missing from the original development outline, and (c) pick out other potential problems in the design earlier rather than later. People are essential visual thinkers, and few clients are good at walking through design problems without a map of the project - despite the fact that their initial outline was almost invariably nothing more than a simple text list of features.

The point here is that you should be building a page diagram anyway - so using it as a part of your estimation methodology will not be adding any extra work.

2. Count the Pages

This is the easy part. Just add them all up, with modifications to existing pages only counting as a half page each for the purpose of this exercise.

3. Multiply by a Factor

Now multiply your page count by a factor representing the average number of developer days it will take to complete a page. This includes every part of the development process: design, arguments, work, alterations from on high, changed minds, rework, and testing. But what should this number be?

If you have worked with your present team and the technology platform (language, framework, server OS, etc) before, then you can look at previous projects and work backwards from known project length to establish a good average for developer days elapsed per web page completed. But all too often it's a matter of new faces and new technologies for every new development project. Here are my fuzzy guidelines for estimates under these circumstances:

The more that you are hampered by big company processes, interventionist management, a clunky choice of technology, or a poor development team, then the longer a project requires to complete.

4. The End Result: a Count of Developer Days

Page count multiplied by the factor above provides the estimated number of developer days you'll need to bring the project to a close. Obviously if your estimate is 300 man days, you can't just bring on 10 developers and have it done in a month - use common sense in figuring out team size and estimated calendar length of the project. My experience has been that if you're faced with a task or functional component that will take four developers three calendar months to complete, then you are unlikely to gain much benefit from adding more people to that team. The reasons for this are far outside the scope of this post, but you might start with a reading of the Mythical Man-Month.

Caveats Learned From Experience

The method I have described only works well for projects of six developer-months or longer. Estimates that worked out very well for me involved teams of three to five developers working over four months or longer. This is because you need a fair number of discrete functional elements in the project to allow the law of averages to work in your favor: you want to see a bell-curve distribution of time taken to complete a functional element (such as a web page), and ideally the number of unpleasant surprises and unexpected shortcuts should both be small compared to the overall number of functional elements (such as web pages). Looking at it another way, the project must be large enough that it will not be greatly impacted by one of the normal risks of software development cropping up for a couple of tasks - such as suddenly finding that one particular functional component requires ten times as long to complete as expected.

This doesn't mean that you can be complacent when risk and slow completion inevitably emerges. But having many other components of the project to reexamine or rearrange means that it is plausible to make up lost time through good planning, fortuitous shortcuts discovered while coding, and fallback positions such as excluding wish-list features.

You cannot generate a good estimate for a small project by counting the pieces and assigning a multiplier for the time taken. There simply aren't enough functional components to play the averages game with very variable completion costs. The risk to the whole project timeline is much greater when the cost of a single component unexpectedly balloons, and the ability to control this risk through good project management practices is much reduced. There are far fewer project components that can be rearranged to make up time, and the likelihood of uncovering a fortuitous shortcut is far smaller as well.

In Conclusion

This isn't rocket science and nor should it be - it's a fast way of establishing a decent estimate for mid-sized and large web development projects. Simple approximations have their place, even in a complex environment such as the real world of software engineering, and can save you a great deal of time and grief.