Time to Read 6 min
This is the more challenging case than the project estimation. How to make an estimate when the requirements and even the architecture of a product are not yet clear? How to make an effort estimate when only a first idea is sketched on an A4 sheet?
How can you get the maximum out of the available information? The maximum here means: In what range is the expected effort?
Tea Leaves Reading for a Coffee Machine Controller
Such an example was the development of a control system for a coffee machine in the initial phase. The project ended up covering several person-years of work. The initial estimate was based on the information available at the time: a specification of twelve pages including cover page and table of contents, and a rough menu tree for operation...
How can an estimate be generated for a project at this early stage that is not just pure tea leaves reading?
What can You Expect?
- System Design: Should you really do it already with the data available?
- Functional Breakdown Structure: How to avoid the system design effort
- Estimation of the Effort as a Team: These are the few estimation steps
- A Little Probability Calculation is Required: The confidence interval
And on separate pages:
- Estimation: What Should be Considered in Practice?
- Models: How to Deal with Fuzziness? Distributions!
We have been working with this estimation method for many years and have created a software tool for it, which we offer as freeware if there is enough interest, please comment below if you are interested.
System Design: Really?
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.
Functional Breakdown Structure
Instead of structuring the estimate by work packages, for the Functional Breakdown Structure (FBS), it is structured by functions and function groups.
Breakdown into Functions by the Project Manager
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.
Gathering Information with All Stakeholders
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.
Categorization of Complexity by the Project Manager
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.
Estimation of the Effort as a Team
Estimation of the Implementation Effort
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
Estimation of the Remaining Work Steps
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.
A Little Probability Calculation is Required
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!
No Comments