Whenever meeting developers, there is one topic which seem to make peoples lives troublesome: estimations. In every company and even als freelancer people are used to provide different kinds of estimations:
- Rough Estimations
- Fine Estimations
In some cases developer invest many hours up to days or weeks in providing estimations; even for rough ones. I noticed this behavior for classical programming languages such as Java or C++ and even IDE based application systems like IBM BPM. During my time as team lead, I noticed that some people are looking for the right way to do such estimations; even though due to deadlines time is not on their best friend.
Next to the mentioned estimations, there are more ways to estimate development activities; and there are supporting tools like Rough Order of Magnitude (ROM) for several programming languages and tools. They are basically sheets, which organize tasks into categories; by summing up the results it’s easy to get a rough estimation with about 40% of certainty. Based on this estimation and by adding some experience-flavor it is easy to create roguh estimations.
Example
For IBM Business Process Manager there are several IBM RedBooks, such as Scaling BPM Adoption: From Project to Program with Business Process Manager. As most IBM RedBooks, this one is also used as basis for most of the available IBM BPM trainings; and one of my favorite RedBooks. Page 137 contains one of those Rough Order of Magnitudes, which is kind of self explaining and therefore easy to use:
| Implementation complexity | Low | Medium | High |
|---|---|---|---|
| Process Analysis | Yes | Yes | Yes |
| Top Level Business Processes | 1 | 1 | 2 |
| Lower Level Business Processes | 5 | 7 | 10 |
| Process Steps/Activities | 15 | 30 | 60 |
| Participant Groups | 3 | 5 | 10 |
| Coaches (Low Complexity) | 10 | 15 | 20 |
| Coaches (Medium Complexity) | 5 | 7 | 10 |
| Business Entities | 5 | 15 | 30 |
| Inputs/Outputs | 80 | 150 | 250 |
| Rules/Policies (Low Complexity) | 5 | 7 | 10 |
| Rules/Policies (Medium Complexity) | 0 | 2 | 5 |
| Basic Reports & Scoreboards | 4 | 6 | 8 |
| System Integrations | 2 | 3 | 4 |
| Implementation Duration | 10 weeks | 14 weeks | 20 weeks |
| Developer Hours | 900 – 1’500 | 1’500 – 2’500 | 2’500 – 5’000 |
| Number of Developers | 2 – 3 | 3 – 4 | 4 – 5 |
The values are based on gained experiences on several projects and also match with my experience for IBM BPM projects. Based on the values and your understanding of the teams flavor, an estimations is quickly done. As BPM projects should be realized in an interative agile approach, the rough estimation fits in for the general purpose. Deviations will be considered during the playbacks/interations like any other risk is considered in projects.
