How to estimate

Estimates should be determined by creating a Work Breakdown Structure (WBS). This can simply be a list of major tasks, broken down into sub tasks if required, with an estimate next to each item. A spreadsheet is the perfect tool for creating a WBS.

You can only estimate how long a task might take based on your personal historical experiences of completing similar tasks.

If you are ever doing anything completely new, it is impossible to provide an estimate that is not a pure wild guess. This should be communicated in your estimate.

Try to keep a record of how long certain common tasks take on current projects, so that you know for next time.

A common pitfall I used to encounter is forgetting to include things like setting up the development, staging and production environments and deployment tools. It’s a good idea, I find, to have a standard WBS document template that includes tasks common to all projects, and to keep this updated when you encounter new things.

Types of estimates

Estimating for a project should be an iterative process where the estimate is updated whenever more knowledge about a project’s requirements are ascertained and documented. This becomes increasingly important as the number of people working on the different areas of a project increases. For example, say a particular piece of functionality is far more complex than originally anticipated; your estimate is prohibitively large, consequently that functionality is deemed unfeasible for the project. It is imperative that this is discovered as early on in the planning process as possible to save other members of the team time estimating for other tasks associated with that functionality.

An estimate will go through many revisions over the process of project definition, from a ballpark estimate to a final estimate.

Every estimate should be with reference to a particular revision of the documentation detailing the requirements.

A ballpark estimate is one that can be provided on the understanding of the fundamental requirements of a project.

A final estimate is one that can be provided once the functionality of a project has been defined.

Accurately estimating the total cost of a project is a nightmare when you do have all the information, and is absolutely impossible when you don’t.

The accuracy of estimates improve as you learn more about a project.

The reality of ballpark estimates

A ballpark estimate is a very rough approximation coming from the idea that a baseball is rarely hit out of the park but can still land anywhere in quite a large area.

Ballpark estimates only purpose should be to facilitate cost benefit analysis of a project to find out whether it’s worth investigating in greater detail.

Ballpark estimates are the result of a typical catch 22 situation: the time required to identify and analyse a projects’ requirements in order to estimate it with a reasonable amount of accuracy and determine its feasibility, is not available before the project is approved, and the client won’t pay for that time until it has been approved.

The trouble with ballparks is that they get taken as gospel by your bosses and your clients. Projects are frequently deemed failures because ballpark estimates become targets that you are expected to meet.

Ballpark estimates are almost always lower than final estimates, because scope increases as more knowledge about the project is discovered.

Managing how your estimates are used and interpreted

You should always include a tolerance with your estimate, e.g. 100 hours ±50%, or -10% +60%. This tolerance should reduce as more information about the project requirements is learned.

If there are too many unknowns in the requirements and your client (who could be your manager) is demanding a ballpark, you can politely refuse to provide one, explaining that you need time for further analysis and scoping of the requirements. This includes situations where you have no experience in the type of project, or no experience in the technologies required.

Express estimates as a range of hours or days, or on an effort scale that you commonly use, e.g. a small project is 1 day, medium is 2 to 5 days, large is 2 to 4 weeks etc.

If a final estimate is wildly different to the ballpark, this should be due to significant differences in awareness of requirements by the estimator, which is perfectly acceptable. If the client can’t accept it, and wants to negotiate on the price, do not panic, this shows they are interested and want to drive a bargain. However, since your final estimate is accurate for the known requirements, it should be acceptable to them that in order to reduce the cost, they are going to have to reduce the scope. In this case, they should prioritise the features and omit the ones that are beyond their budget, or get more budget.