The cost evaluation is one of the key initial stages that happen before a project starts. It provides stakeholders with information about the resources required and helps them decide if they have enough supplies for effective project management. How do we know how much a new project will cost?

The truth is that we can’t tell for sure until a project is finished. The future is always unpredictable and uncertain. The best we can do is to make an estimation. There are three methods of project estimating that differ in the precision of the final estimate.

Let’s start with accurate cost estimates.

  • The most accurate, hence the most time-consuming, is the definitive project estimate. A definite estimate requires a Work Breakdown Structure.
  • The next one is a budget estimate that requires less time and has a range of variance from -10% to +25%.
  • The fastest way to provide stakeholders with estimation is to prepare a Rough Order of Magnitude (ROM).

In this blog post, we will discuss how to create ROM estimates in the condition of high uncertainty.

What Is the Rough Order of Magnitude?

Rough Order of Magnitude (ROM) estimate means a quote provided in the early phases of project planning when the scale and requirements are not clearly defined. Rough cost estimates are usually created to supply a client with approximate data about the time scale of a project and requested resources so that they can decide if they have enough. Data-driven decision making for launching a project and clear cost estimates help businesses avoid pitfalls and increase efficiency.

Rough order of magnitude estimation is also a useful document that helps understand if a project will return the investments or not. A rough cost estimate is never precise. The values described in the ROM quote are loose and might change within the project life cycle. The scope of rough magnitude estimates is as high as the general uncertainty of a project.

What Is the Uncertainty?

Uncertainty is inherent to any project. In the broadest sense, it means the state of not knowing. In some cases, the risks are associated with not knowing the future. In others, ambiguity appears because of the lack of knowledge about the current or future conditions. The causes of the events and their potential outcomes may be hidden. Outcomes with negative effects are called threats. Outcomes that bring benefits are called opportunities.

With dynamic systems, forecasts about future outcomes are much harder to make than with static environments. Both human and non-human agents tend to behave unpredictably. Because of those ambiguities, a project manager may lose the understanding of the path to follow or a solution to pursue. This, in turn, may adversely affect the use of the project budget and confuse project executors during the planning phase.

A PMBOK proposes the following options of how to respond to the uncertainty:

  • Conduct research. Gathering business intelligence data, performing a market analysis, and having an IT consultation with experts are good ways to decrease the uncertainty. It is also important to understand when new information stops bringing benefits.
  • Prepare for different outcomes. A plan B is always a good idea. In cases when there are only several possible outcomes, a team can prepare for each of them. An extensive set of possible events requires estimation of the likelihood of occurrence so that a team prepares only for the most probable.
  • Set-base design. Organize a team meeting and discuss the possible trade-offs: time vs. cost, quality vs. cost, risk vs. schedule, or schedule vs. quality. The aim of the project team is to research the possible options to learn from working with different alternatives.
  • Invest in resilience. Be ready to adapt and respond quickly to unexpected changes. Resilience applies both to the team members and the processes inside the project. Effective project management tools may help your team instantly adjust

How to Determine Rough Order of Magnitude with High Uncertainty?

There are several techniques a project management institute can use to prepare a rough estimate under the condition of high uncertainty. They vary in the level of precision and the required time. You may choose one of them or apply several methods to receive a more accurate estimate. Decide wisely so that you provide a realistic order of magnitude estimate without getting stuck with a detailed analysis.

Estimation by the Analogy

The quickest way to get an order of magnitude estimate is to take data about the duration and cost of a similar project. Getting information about project costs is only a few clicks away, especially if your project team has worked on similar requests before.

Estimation by the analogy is often used when there is little evidence about the project, but clients still need an estimation to understand if they possess enough resources. It can be applied either to a project as a whole or to separate phases.

While preparing a price quote based on the data from the past project, it is a good idea to increase the expected cost. For example, if the cost of the previous app was $20,000 and four months, a new app will probably cost $25,000 and five months.

Pitfalls: When using this method, managers pretend that external conditions remain the same. In reality, the situation might have changed dramatically so that the order of magnitude estimate would significantly deviate from the actual cost. The method also appears useless when a client requests new features or characteristics.

rom rough order of magnitude

Parametric Estimation

This technique uses a rate per unit taken from previous projects. You have to do multiple quantities of units by historical data about the cost of a unit. For example, a client requests you to install your software on 85 of their office PCs. You know that a price of a license for a single PC is 40$ and the time of installation is 50 min. The ROM estimate for such a project will be 85*$40=$3400 and 85*50 min=70,8 hours.

The units to consider while preparing parametric order of magnitude estimate are:

  • Resources required (human, expendable materials, equipment).
  • Expected outcomes (web pages of a website, features of an app, duration of media content).

If you have a prepared template, an estimation can be done in a few clicks. Otherwise, you need to prepare a detailed work break structure, which will take time. You can reduce the time spent on parametric estimation with the help of project management software that provides templates and data about a unit’s possible cost.

A great benefit of a parametric estimation is its flexibility. For example, if a client suddenly decides to change the scope of required work, you can easily adjust the ROM by changing several numbers in a formula.

Pitfalls: For some units, you might not have historical data. For instance, it is difficult to estimate a software integration to a system and associated APIs that are new to the software development crew. Since a minor change in numbers strongly affects multiplying, the lack of data can cause a major deviation in the estimated cost. For example, $250*1000 units=$250000 while $270*1000 units=$270000. The difference is 20000, which is significant!

Three-point Estimation

Also known as a probabilistic order of magnitude estimate, the method of evaluation costs provide not a single but several estimates. It is usually represented with a probability density curve. The best thing about the three-point method is that it helps to accommodate for the high level of uncertainty.

rough order of magnitude estimate

To create a probabilistic estimation, you need to mark three points on a curve:

  • Most likely scenario. Assuming that some minor risks happen and a project is delayed or resources are lost.
  • Optimistic scenario. Assuming that everything goes as was planned and no obstacles were met.
  • Pessimistic scenario. Assuming that a major accident happened. It is important to reassure investors that the project can be finished even in the worst scenarios.

Another variant of a three-point estimation predicts different scenarios depending on the amount of effort spent: low, medium, and high. It is especially useful for cases with little data about the project complexity.

Low effort

  • Task: 1 to 3
  • Hours: 20 to 40 to complete
  • Cost: $2000 to $3000
  • People involved: 2 or 3

Medium effort

  • Task: 3 to 5
  • Hours: 40 to 80 to complete
  • Cost: $3000 to $5000
  • People involved: 3 or 4

High effort

  • Task: 5 to 7
  • Hours: 80 to 120 to complete
  • Cost: $5000 to $7000
  • People involved: 5 or 7

You may also want to provide your client with a triangular distribution of possible outcomes. To receive the result, you simply need to calculate the average of all three results.

Pitfall: The optimistic scenario may sometimes confuse a client and give unreasonably high expectations, so it is super important to communicate with a client the probabilities of beneficial outcomes.

Want to learn more about how to administrate projects? Check tips from our Senior Project Managers.

T-shirt Size Estimation

Initially popularized by Agile and SCRUM teams, this technique provides project estimates in relative terms rather than in exact numbers. Just like with T-shirt sizes, smaller tasks are marked with the letter S, medium with M, big with L, and XL. You can also add ES (extra-small) size for the tiny tasks.

Since the variations in the size are approximate time estimations and not the accurate value, the technique rescues us from the trap of providing a client with the wrong number of development days.

Another benefit of a method is that it provides a clear and comprehensible framework for order of magnitude estimate. The results of the estimation can be easily communicated to the audience with different levels of expertise.

agile sprints

Pitfall: The size division of tasks may be subjective, so you have to make sure that your clients and team are on the same page. Also, the difference between sizes may not be so clear. To make the distinction more obvious, reduce the number option. Stick to only S, M, and L, removing the redundant values.

Story Points

Story Points are yet another artifact from the SCRUM methodology. It represents the efforts needed to bring product backlog items to life. Each Story Point expresses a normal distribution of time.

For instance, in reality, 1 Story Point could represent a range of 5-10 hours, 2 Story Points 10-20 hours, and so on. This time is usually unknown during the order of magnitude estimate so the Story Points are just an abstraction. It makes the approach agile and suitable for situations with a high level of uncertainty.

Story Points are assigned according to the complexity of work, amount of work, resources or additional training required, etc. Assigning values helps teams to break the work into smaller pieces, hence responding to uncertainty. Moreover, it motivates team members to focus on delivering value and not spending time on work.

Story Point order of magnitude estimate begins with a broad discussion of tasks with different company divisions. It is made to receive feedback from people who hold a different perspective on project difficulty.

Suppose the product managers plan to do something simple, like the introduction of a single new feature. In that case, they should discuss the idea with the UI designers, development team, and QA. What seems an easy task for the designers may appear a hard task for the developing engineers.

Pitfall: Opinions about the value of different stories might vary inside your team, which can lead to some disagreement.

Final Thoughts

Let us repeat once again which of the following is true of a rough order of magnitude estimate.

Not always, the circumstances allow for an accurate estimate. ROM (Rough Order of Magnitude) is an evaluation instrument with a low accuracy level. The ambiguity of estimation can be evaluated by mixing different methodologies. Nevertheless, while providing an estimation, a balance is needed. You have to be precise but not fall into analysis paralysis. Attempting to plan everything in detail moves you away from agile and makes the business vulnerable to uncertainty and risks.

One of the ways to handle risks is to prepare several estimations with different probabilities. Discuss with the team what are the most pessimistic, most optimistic, and most probable scenarios and provide your client with a proper quote.

The other way to address the uncertainty is to avoid an exact order of magnitude estimate of the number of hours and resources required. The T-shirt approach is a good method of providing estimation without mentioning the accurate values. You may also use Story Points for the cases when you are not sure how much time is needed to complete a task but know what level of difficulty each task has.

Need help from a professional project management team that can handle estimations with high uncertainty? Contact us, and we will gladly assist you with your project.