Rough order of magnitude

From CEOpedia | Management online

Rough order of magnitude (also called ROM) is top-down estimation of costs used at the beginning of projects, often to estimate first rough budget for the project . It is said if should be accurate within 35 percent (plus or minus)[1]. Is used in risk cost evaluation and conceptual cost evaluation[2]. This method is especially advised when there is[3]:

  • limited data so only a few details are available,
  • short time but there is need to estimate costs quickly,
  • there is no possibility of detailed analysis,
  • possibility to use similar models, systems, expertises are subjects,
  • historical data and ratios that could be used,
  • analysis answering question what if,
  • need to estimate some specific part of the project,
  • need to make decision out of many high-level alternatives to assess which one is the most feasible,
  • there is no need to develop budget-quality cost estimate yet.

Benefits of rough order of magnitude for cost evaluation

There are several reasons why using rough order of magnitude is beneficial[4]:

  • uses fundamental assumptions,
  • meets basic requirements,
  • users may build knowledge of type of (future) costs,
  • users have better awareness of costs in the project,
  • cover costs in total life cycle,
  • enables visibility on suitable material solutions,
  • reduces costs, efforts and time on alternatives that were nonviable from the beginning.

Process of rough order of magnitude for cost evaluation

When company or project manager decides to evaluate costs with use of rough order of magnitude, below five steps should be taken [5]:

  1. Definition of goal and requirements: statutory mission requirements, gap analysis, combining requirements, developing capabilities,
  2. Collection of data and analytical review: researching government and industry standards, data from stakeholders, reviewing Life Cycle Cost Estimates (LCCE), evaluation of techniques and methodologies,
  3. Transferring requirements to capabilities: connecting requirements and costs, define the best cost dimensions, developing rules,
  4. Analyzing and developments of model: deeper cost estimation, identification of cost drivers,
  5. Delivering results and documentation: delivering final cost evaluation, documentation, informing board about results to enable making of decision and gaining feedback

Additionally, to be estimate if there is possibility of improvements, so that at little cost or effort, analysis could be at better quality, below questions might be answered[6]:

  • How quality of rough order of magnitude can be improved?
  • Were any complex assumptions avoided due to capacities?

Examples of Rough order of magnitude

  • Construction Projects: At the beginning of a construction project, a rough order of magnitude can be used to determine the cost of the project. This estimation will factor in things such as labor, materials, and other expenses related to the project.
  • Software Projects: At the beginning of a software project, a rough order of magnitude can be used to determine the cost of the project. This estimation will factor in things such as development time, hardware costs, and other expenses related to the project.
  • Energy Projects: At the beginning of an energy project, a rough order of magnitude can be used to determine the cost of the project. This estimation will factor in things such as initial start-up costs, equipment costs, and other expenses related to the project.
  • Business Projects: At the beginning of a business project, a rough order of magnitude can be used to determine the cost of the project. This estimation will factor in things such as personnel costs, marketing costs, and other expenses related to the project.

Limitations of Rough order of magnitude

Rough order of magnitude is a top-down estimation of cost used at the beginning of projects, often to estimate first rough budget. However, there are certain limitations of this estimation technique. These include:

  • Lack of accuracy: Due to the nature of the estimation method, the accuracy of the ROM is frequently low, with a margin of error of up to 35%.
  • Lack of detail: ROMs are typically high-level estimations and therefore do not take into account the individual costs of the project and its components.
  • Poor time management: ROMs can be difficult to keep up to date and require regular adjustment and maintenance as the project develops.
  • Overly optimistic: ROMs can often be too optimistic in their estimates, leading to budget overruns.
  • Difficult to compare: As ROMs are based on top-down estimations, it can be difficult to compare them to other estimates or to benchmark them.

Other approaches related to Rough order of magnitude

At the beginning of a project, a rough order of magnitude (ROM) estimation is used to quickly estimate a project's budget. There are several other approaches that can be used for estimation:

  • Expert Judgement: This approach utilises the experience and expertise of the project team to make informed predictions about the effort required to complete a project.
  • Parametric Estimation: This approach uses historical data from previous projects to estimate the effort required for the current project.
  • Analogous Estimation: This approach uses existing data from related projects to estimate the effort required to complete the current project.
  • Bottom-up Estimation: This approach involves breaking down the project into smaller parts and estimating the effort required to complete the individual parts.

In summary, a rough order of magnitude estimation is one of the many approaches used to estimate the effort required to complete a project. Other approaches include expert judgement, parametric estimation, analogous estimation, and bottom-up estimation.

Footnotes

  1. Rowe S. R., (2015)
  2. Black J., Lane J., Lane R., (2017)
  3. PWC, (2015)
  4. PWC, (2015)
  5. PWC, (2015)
  6. PWC, (2015)


Rough order of magnituderecommended articles
Concept engineeringDecision pointRating processSoftware cost estimationDetermining the length of the production cycleGo no go decisionCost modelConditions of decision-makingAnalysis of processes

References

Author: Weronika Burzawa