If you want to create a Work Breakdown Structure (WBS) with this level of data, you are implicitly already doing a system design phase with a lot of assumptions. This leads to a large effort, which is not justified in this early phase and above all is not worthwhile, since the specification will most likely change again and the WBS will become worthless.

What now? The solution is to use the existing information, which mainly concerns the function of the product to be developed.

Instead of structuring the estimate by work packages, for the Functional Breakdown Structure (FBS), it is structured by functions and function groups.

At the top level, it is best to divide the project by subject, for example, software, hardware, mechanics. This results in each subject being able to estimate its effort independently. If necessary, the functions are grouped together within the specialist areas, and the individual functions are then found inside the groups. This work can be done very well by the project manager or the corresponding specialist alone.

If functions concern more than one subject, they occur several times, for example a USB interface in software (USB stack) and hardware (USB electronics).

An additional simplification results from the fact that one indicates the number of similar functions, i.e. not the product menu, the cleaning menu ... but that one indicates how many menus of the same complexity occur, for example "6 operating menus".

Since the FBS does not depend on the project life cycle, it is more difficult to create a generic template than in the case of the WBS, which follows a project life cycle.

Function Group | Function Sub Group | Function | Number | Complexity | Description | Assumptions | Remaining Risks |
---|---|---|---|---|---|---|---|

Interfaces | Host | LAN | 1 | L | to SCADA | LAN driver must be ported by us | |

serial | 2 | S | for legacy systems | ||||

User | LCD graphic display | 1 | XL | dot-matrix | max. VGA-resolution | ||

numerical keyboARD | 1 | S | |||||

Protocols | MODBUS | 1 | M | ||||

Proprietary host protocol | 1 | XL |

Excerpt from a larger FBS

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

When you have created the FBS so far, it makes sense to look at the structure again with all stakeholders. Often, new information is gained through changes or additional functions that were forgotten in the initial documentation.

In order to simplify the estimation, the functions are not estimated individually, but divided by the project manager or technical specialist into, for example, four complexity categories (S, M, L and XL). On the one hand, this rough classification reduces the estimation effort, and on the other hand, it leads to no unnecessary discussions about subtle differences that are lost in the rough final result anyway.

Now the effort for the implementation of the single categories can be estimated in hours. This estimation is done per subjectz (i.e. with the software team, the hardware team, etc.).

For this purpose, three functions are selected from each category (S, M, L, XL) that represent the greatest possible diversity (e.g. menu / driver / controller). For these, one estimates the implementation effort for the normal case (i.e. the most common case) and the worst case as a kind of average of the three selected functions.

This estimation is also done with Planning Poker.

Category | Implementation Normal Case/ Ph | Implementation Worst Case/ Ph |
---|---|---|

S | 2 | 20 |

M | 8 | 40 |

L | 20 | 80 |

XL | 40 | 200 |

Example of estimating the implementation effort for the four categories

Now the project life cycle comes into play after all. After estimating the implementation above, important things like integration, testing and debugging, but also project management are still missing. These are given as a percentage in relation to the implementation.

Module | Project Life Ccycle Phase | Description | Number of Iterations | Effort Relative to Implementation Normal Case | Effort Relative to Implementation Worst Case |
---|---|---|---|---|---|

Software | Implementation | Design, development & test at unit level | 1 | 1.0 | 1.0 |

Module Integration & Test | First integration und tests, incl. debugging | 1 | 0.4 | 1.0 | |

Module Regression Test | Regression tests & debugging for iterative releases | 3 | 0.2 | 0.3 | |

Module Design | Architecture & design of the module | 1 | 0.2 | 0.4 |

Parameters to be estimated (in *italics*) for a typical software project cycle

And also these percentages have a normal value (the most common case) and a worst case. This estimation is best done with Planning Poker. Historical values can be used as a reference.

Now that the individual estimates have been created, they need to be summed up. This does not work without some probability calculation. For the probability distribution of the individual estimates a log-normal distribution is used.

As a result, we would like to be able to give not only the expected value, that is, the value that the effort takes on average, but also the range in which the estimate moves. This is interesting because it contains information about the certainty of the estimate and the risk of the project.

We use the confidence interval 90% , that is, the range in which 90% of the estimated values lie. Or, in other words, the project was estimated to have a probability of 5% below the lower value of the confidence interval or the same probability of 5% above the upper value of the confidence interval.

All these calculations are based on probability distributions.

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!

Projects? Ideas? Questions? Let's do a free initial workshop!

No Comments