Rough Order of Magnitude (ROM)

Share this post on:

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
LowMediumHigh
Process AnalysisYesYesYes
Top Level Business Processes112
Lower Level Business Processes5710
Process Steps/Activities153060
Participant Groups3510
Coaches (Low Complexity)101520
Coaches (Medium Complexity)5710
Business Entities51530
Inputs/Outputs80150250
Rules/Policies (Low Complexity)5710
Rules/Policies (Medium Complexity)025
Basic Reports & Scoreboards468
System Integrations234
Implementation Duration10 weeks14 weeks20 weeks
Developer Hours900 – 1’5001’500 – 2’5002’500 – 5’000
Number of Developers2 – 33 – 44 – 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.

Leave a Reply