How to Perform a Project Estimation?

Time to Read 8 min

"Divide et impera - divide and rule" Gaius Julius Caesar

This isr the simpler and more popular case: a detailed specification (a requirements specification) and a rough technical solution (a system architecture) already exist for a project.

More than 100 Pages of Specification and still No Coffee?

An example of this was the development of a control system for a professional coffee machine. In order to easily operate the coffee machine with its variety of products and with the numerous configuration options, product and cleaning processes, languages and maintenance options, a fully graphical touch screen was specified. This resulted in software that was further complicated by the many dependencies on the hardware and especially the mechanics of the machine.

The finalized specification contained more than a hundred pages, plus the same amount of description of the mechanical processes. With this information, a more accurate project estimate for a fixed price project was possible. In the end, the entire project to the finished control system involved several person-years of work. This entire project was estimated by our engineers at the beginning to be more accurate than a 10% variance. And all this without even having smelled the first espresso from the machine ...

What Can You Expect?

Work Breakdown Structure: What it looks like and why it requires a system design
Project Structure and Project Life Cycle: Reuse helps save time!
Effort Estimation as a Team: How the estimates come together... and the risks
Two-Point Estiamtion: How the worst case gets into the estimation
Parameter Estimation: Where you can keep your work easy

And on separate pages:

We have been working with this estimation method for many years and have developed a spreadsheet template for it. In addition, a software tool exists for this project estimation, which we offer as freeware if there is enough interest, please comment below if you are interested.

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.

Phase	Component	Work Package	Result/ Deliverable	Description	Assumptions	Remaining Risks
Software Design	Module 1	specify module	Module Specification	create "black box"-specification
		define components, package-diagrams, interfaces	Module Architecture	create "white box"-architecture	communication stacks might be taken over by chip manufacturer
		define tests	Test Specification	generate first test plan for tester		test framework customer unclear

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.

Screenshot of a work breakdown structure

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:

Work Package	Result	Effort Normal Case/ Ph	Effort Worst Case/ Ph	Estimation /Ph
specify module	Module Specification	20	40	27
define components, package diagrams, interfaces	Modular Architecture	40	40	42
define tests	Test Specification	8	28	15
Total Effort				84

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:

Work Package	Result	Parameter
Estimation of the parameters for an "average feature"
specify feature	section in Specification	0.1
design feature	section in Design Document	0.2
implement feature	Source Code (compiles without errors)	1.0
generate and implement tests	Test Code	0.3
test and debug feature	Source Code (works without errors)	0.4
Total effort/ Implementation effort		2.0

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:

Work Package	Implementation Normal Case/ Ph	Implementation Worst Case/ Ph	Total Effort Normal Case/ Ph	Total Effort Worst Case/ Ph	Estimation/ Ph
Feature 1	8	16	16	32	21
Feature 2	20	40	40	80	53
Feature 3	40	48	80	96	85
Overall Effort					159

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!

Author