How to Perform a Project Estimation?

Work Breakdown Structure

Why a System Design?

Although it is not part of the estimation in the strict sense, it makes sense to look at the system design. The result of the system design consists of a "black box" specification of the product and a "white box" description of the solution. These two documents do not need to be finished to the last detail for an estimation.

The criterion for determining whether the system design phase is sufficiently advanced for project estimation is that the open items no longer involve risks to the effort. Conversely, this means that in the system design phase, all specifications involving an effort risk must be clarified (e.g., whether the user interface has a touch screen or only a seven-segment display). The same applies to the key components and technologies that must be selected (e.g. operating system, main processor). Often this means creating small prototypes or pilots that verify these key elements.

So, on the one hand, the system design phase serves to document the exact scope of the project and to roughly outline the solution. On the other hand, it serves to mitigate risk, not only technical risk, but also communication risk, because it makes the desired outcome of the project explicitly clear to all stakeholders.

Breakdown into Work Packages by the Project Manager

For the Work Breakdown Structure (WBS), the project is divided into work packages over several levels. How many levels (e.g. subproject, project phase, work package) depends strongly on the size, i.e. the complexity of the project. For the maximum size of work packages at the lowest level, a maximum of forty person-hours should be aimed for.

This division into work packages is carried out most efficiently by the project manager alone. Sometimes it makes sense for individual sub-projects (e.g., hardware development, mechanics) to be created by the appropriate subject specialists.

Extract from a larger WBS

Of course, the WBS must include all tasks of the project, including project management. In addition, it makes sense to define the packages not as pure action packages, but primarily by their results or deliverables. This way there is no overlap between packages and the criterion for the completion of the package is clearer.

A brief description of the work packages is always helpful, and initial assumptions and risks remaining beyond the estimation can already be documented.

WBS is actually old hat, the method was codified in the 1950s and has the advantage that the structure can be used not only for estimating but also for project tracking.

Project Structure and Project Life Cycle

So now all the tasks of the project should be captured. What is the easiest way to ensure this? This is where the project life cycle comes into play. Once you write down "how we do such projects here", you have already created one.

There are also standard cycles as a template, such as, for example, the V-model, RUP (Rational Unified Process) or Scrum. Such a project lifecycle can be used to provide the superordinate structure for the WBS. This then only needs to be filled in with the project-specific work.

A Template for the Project Structure

Now, when all subtasks and work packages of a project are recorded along this structure for the first time, one has just a template for further projects. You can delete the work that the project does not need and add new ones.

If you add them also to the template and in addition track work forgotten in the course of the project, over time you get a WBS template with which you actually cannnot forget anything. This eliminates an important source of error that leads to under-estimation.

Estimating the Effort of the Packages in the Team

How do we estimate realistic effort for the individual work packages? Here we use Planning Poker. Planning Poker allows to collect expert knowledge efficiently and without bias from the whole team. This is also the reason why the whole team should be involved in this phase. Diversity leads to better estimates: Sometimes the newcomer's objection is justified and, thanks to Planning Poker, she also gets to have her say.

An important task of the Planning Poker facilitator is to document the assumptions and remaining risks for each package that come up in the discussion directly in the WBS. They are then used for risk estimation. Most of the time, the team will also find tasks that were forgotten when the WBS was created; these are added as well, of course.

Two-Point Effort Estimation

For most people, it is relatively easy to tell how much time it takes them to complete a task in the normal case, that is, the most common case. It is also not that hard to tell how long it takes them in the worst case. Comparing the two values shows how much risk is attached to the task.

One can exploit this by taking a weighted average that gives double weight to the normal case versus the worst case. In other words, one uses for planning the value that lies one-third of the way between normal and longest effort.

For example, one has estimated two days, or 16 hours, for the normal case, and five days, or 40 hours, for the worst case. You take one third of the differences (1/3 of 24 hours, gives 8 hours) and add them to the normal case, so the estimate would be 24 hours. The background of this method can be found in the technical part.

This then looks like:

Excerpt from a WBS with estimates ("Effort Normal Case", "Effort Worst Case") and result of the two-point effort estimation ("Estimation"), calculated values in italics. Ph: person hours

Parameter Estimation

How to Estimate Tasks that are «Impossible» to Estimate?

For some tasks, estimation is difficult because they are hidden efforts: for example, design, testing, or debugging. How should I know how many bugs the prototype will have?

Here, one can estimate using parameters, based on figures from projects already completed or by also estimating these factors with Planning Poker. These parameters then result in the percentage of effort that must be spent on testing and debugging in relation to the actual implementation.

Such a parameter estimation might look like this:

Parameter estimate for complete development versus pure implementation only, effort estimated relative to implementation, calculated values in italics

This factor is then used in the estimation:

Excerpt from a parameter-based estimate, pure implementation effort for each feature as a two-point estimate, from this by multiplying by the parameter sum (2.0) calculations of the values for estimating the total effort per feature, calculated values in italics, Ph: person-hours

Where it is Even Easier

For certain work packages, you can avoid estimating with Planning Poker altogether: for example for the weekly project meeting. This usually has a fairly well-defined duration – so multiply the meeting duration by the number of weeks the project is expected to take times the number of people involved – and you have an accurate estimation for that task.

Since we also want to get better, please enter your comments below, ideas, suggestions and questions. I will then incorporate them into a next version.

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!