One of the most important aspects of project management is estimation. All projects require a budget and stakeholders want to what it is before the project is started. So, project estimation must be done prior to the project launching. This brings us to a type of preliminary estimate called Rough Order of Magnitude (ROM), which is presented to the stakeholders, who then decide whether they will continue with the project or not.
In this article, we are going to talk about the Rough Order of Magnitude, how to calculate it, some pitfalls to be aware of when calculating it, and some practical examples.
What is Rough Order of Magnitude (ROM)?
A Rough Order of Magnitude is the initial estimate that is often done before a project is started. The Project Management Body of Knowledge (PMBOK) suggests that the ROM estimate should have an accuracy of - 25 percent to + 75 percent. So, if the estimate is $100,000 then the acceptable outcome should be within the $75,000 – $175,000 range. The main goal of this estimate is to give decision-makers the necessary information on whether or not the project is within their means. Therefore they will know the ballpark level of effort in terms of cost, duration, and resources.
Throughout the lifecycle of a project, there are other estimates that need to be done besides ROM. So, what is the difference between these estimates?
Difference between ROM, Budget Estimate, and Definitive Estimate
Aside from the Rough Order of Magnitude, the Budget and Definitive estimates are the two other types that are required as the project goes through its lifecycle. Let us take a closer look at the difference between these three.
ROM estimate is done at the initial phase of a project and usually has a variance of - 25 to +75 percent. It provides a rough estimate of the total expenses that the owners may incur until the project is completed. An estimation approach known as “top-down” is mostly applied here, whereby the overall project is either estimated first, then individual tasks are allotted from it, or the project is broken down into larger tasks that are estimated separately.
This estimation approach is used especially when much information on the project is not yet known and there is a strict budget expectation. Another approach known as “bottom-up” can also be used. Here, the individual tasks are specified and estimated first, then combined into an overall project estimate. This approach is mostly used when detailed information about the project is readily available. The ROM estimate is not fixed and can constantly change with time.
The budget estimate also uses the “top-down” approach and more specifically the analogous estimating technique. When compared to the ROM, it has a more accurate variance of - 10 to + 25 percent. It is done at the conceptual phase of the project, especially when final project specifications are still unknown, but the team already has the main set of features and technical requirements. It helps the client and stakeholders to make an initial cost and budget control plan.
The definitive estimate is the most accurate of the three. It has a variance of accuracy as little as - 5 to + 10 percent. This means that this estimate is the closest and should reflect the final cost of the project. Unlike the other two estimates, the “bottom-up” approach must be used. The definitive method of estimation is usually done in the planning phase and should be kept until the project is completed. Due to its detailed structure, it takes a long time to create this type of estimate.
Difference between ROM, Budget, and Definitive estimates
Techniques used to determine the Rough Order of Magnitude
When trying to determine the ROM, there are many different techniques your team can choose. These techniques can be used individually or in combination with each other to arrive at a more accurate estimate. In most cases, a project manager will need expert judgment and engage technical leads and architects.
Analogous estimation
This method uses data and knowledge of previous or similar projects as the basis for estimating the new one. There will be instances where the project manager is asked to give duration and cost forecasts for a new project as the owners need some data to decide whether the project is worth doing. In such cases, an analogous technique is the best solution. It’s often used when much information about the project is not yet known. For example, the previous time-tracking app cost $15,000 and three months to complete. Therefore, the new app the team wants to build should cost about $20,000 given the new features.
When comparing the two projects, many different variables are taken into account such as scope, costs, duration, etc. However, the analogous estimating approach mostly makes use of cost and duration variables.
The accuracy of this approach is the lowest amongst the three methods. However, it is the fastest and cheapest estimate to make. Getting data on previous projects is usually a few clicks away, especially if the project was done by your team. This estimation technique can be applied to the project as a whole and to the individual phases of the project.
The pitfall of the analogous technique. When using this method, the project manager assumes that all the variables in the past project remain roughly the same for the new one. However, the variables such as cost are constantly changing, which may lead to a significant deviation from the actual cost or duration of the project.
Parametric estimation
The parametric technique makes use of a unit rate taken from previous projects to determine the estimate of the new project.
For example, your team wants to make an app design and the UX specialist requires $150 per day (unit rate). Based on previous project data, it takes about 10 days to design the app. Therefore, the estimated cost of designing the app will be $1,500. You may use other types of units such as story points.
This estimation technique is best used when you have detailed information on the project and when the business provides similar services such as landing page development or customizing eCommerce engines. This is because once you have created the formula for the first project, it can be repeatedly used for the upcoming ones.
The accuracy of the parametric approach is quite high because the parametric values are taken from industry publications or similar projects (both internal and external).
The pitfall of the parametric technique. The overall estimate is only as reliable as the parametric value. So, the accuracy of the project estimate may be greatly skewed if the parametric value is very small and the number of units is very large, or vice versa. For example, check following estimates:
Estimate A: $1 per unit x 1,000,000 units
Estimate B: $1,000 per unit x 1,000 units
We see that even though the estimates are the same, a small mistake in the parametric value of Estimate A will cause a significant increase in the value of the final estimate. However, that is not the case for Estimate B. Another obvious drawback is that parametric estimation requires a lot of historic data, which may not be available. Finally, the unit measure may deviate from project to project because of external factors, e.g. employee experience.
Three-point estimation
The three-point method uses optimistic, realistic, and pessimistic estimates to get the most accurate value for a project. The best thing about the three-point technique is its ability to accommodate for the uncertainty in project times.
It also makes use of many factors that can delay or accelerate the project’s progress. Using the three-point technique, project managers can have an idea of the possible cost and time variation for the deliveries and offer delivery dates to the stakeholder in a safer manner.
Optimistic (O). Assuming that no risk occurs
Pessimistic (P). Assuming that the risk certainly occurs
Most likely (M). Assuming the most realistic risk occurrence level
To calculate the three-point estimate value, there are two accepted formulas:
Triangular distribution. It is simply the average of the three values. Commonly used in small repetitive projects.
E = (O + M + P) / 3
Beta distribution. This formula is also known as the Program Evaluation and Review Technique (PERT), which takes the weighted average of the three values. It is known as the “weighted average” because the most likely value has 4 times more weight than the other two values. This technique is mostly used for large non-repetitive projects.
E = (O + 4M + P) / 6
For example, based on previous projects, we understand that the time it takes to design an app main screen under the best conditions is 5 days. We then estimate the time it will take if the worst-case scenario occurs, such as the designer gets sick. Let us say it is 15 days. Then we assume that the realistic time it will take to complete the task is 10 days if some favorable and unfavorable scenarios occur. So, the estimated time to design the app according to the three-point estimating technique will be:
E = (5 + 4 x 10 + 15) / 6 = 10 days
The pitfall of the three-point technique. This method will provide inaccurate estimates if there are inaccurate or incorrect assumption scenarios. Also, it will be confusing and time-consuming if the optimistic, most likely, and pessimistic values are defined by different people.
T-shirt size estimation
The T-shirt size technique provides the estimates in relative terms rather than numbers. Normally, just like with T-shirt sizes, smaller tasks are labeled with S, medium with M, large with L and XL, etc. Those estimates can then be scaled and converted to a number. The T-shirt estimation technique is typically used at the initial stages of the project when there is little information, but the project manager is required to provide an estimate. The definitions of the sizes are often based on past internal projects or historical data.
So, for every t-shirt size, there is an associated range of durations or costs. Note they will vary from organization to organization. For example, for one company, small size may be associated with $10,000 - $20,000, while in another company the same small size may be $1,000 - $2,000.
So, to get the duration required to develop an app, the process is divided into chunks and each specialist provides a size relative to the time it could take to complete. For example, the app development process is broken down into features such as design, coding, third-party integrations, documentation, communication, and hosting.
Design = S
Coding = XL
Third-party app integration= L
Communication = L
Documentation = S
Hosting = S
The pitfalls of the T-shirt size technique. It is not useful if the relative sizes are not consistent. The new members of the team will find it difficult to adapt to this technique. Also, if the project cannot be broken down into tasks of different sizes, then the technique will not work, as different sizes help put the task complexities into perspective.
Example of ROM estimation
In this example, we are going to calculate the ROM estimate of building a time-tracking app, taking into consideration that our team has worked on that kind of project before.
First, the stakeholders and project manager will evaluate the project’s scope by comparing the duration and cost of similar projects that the team has done using the analogous technique. Let us assume that the previous project data in our case shows that it took approximately $15,000 and 50 days to complete the app. This information is used as a reference point when creating other estimates.
Next, a project manager defines the specialists needed to work on the project. Once that is done, the project is broken down into phases, where each specialist involved in the development process uses the T-shirt size method to estimate the level of effort it will take to complete their part. With this information, the project manager can use the three-point technique, to calculate the estimated number of days for each phase. For example, the UX experts assign a t-shirt size of S to their part. The project manager then converts the size to 5 days as the optimistic time, 10 days as the most likely time, and 15 days as the pessimistic time. Using the formula we can calculate the estimated time:
E = (5 + 4 x 10 + 15) / 6 = 10 days
This is how ROM estimate that combines several techniques may look like.
Now, the manager uses this information to calculate the estimate of the total duration and cost of labor based on the rates of the individual specialists. Given that designers are paid $150 per day and programmers $200 per day, we can use the parametric estimating technique to determine the estimated cost of the individual phases or whole project which will be $11,500.
Things to consider when doing ROM estimates
To conclude, we’d like to mention a couple of things to consider when doing ROM estimates.
Engage multiple experts in estimate discussion. There are many methods to do estimates in a group. One of the most popular ones is planning poker, commonly used as one of the Scrum best practices. With ROM estimates, it may be enough to engage a couple of senior engineers or a team lead and a solution architect and let them discuss the tasks to arrive at a mutual understanding of their scope.
Factor smaller activities in. When determining project estimates, remember to make room for minor tasks that may add up to increase costs and duration. These would be communication, project management itself, onboarding of new team members, etc.
Include contingencies. Make sure that your project estimates include contingencies. One of the best ways to do this is by using the three-point technique that takes into account unforeseen events and risks. Some project managers deliberately exclude contingencies from their estimates to make a successful pitch. But keep in mind that the stakeholders will not be pleased when you go over the budget due to contingencies that were not included.
Always try to be honest with the estimates and do not use only optimistic values just to stay within the stakeholders' budget. Doing that may result in specialists chasing deadlines and working with limited resources.
While the project is initiated with a Rough Order of Magnitude, it should not end there. There are other types of estimates such as the Budget and Definitive estimates that should be used during the project’s lifecycle to provide more accurate and reliable values.
