The cost evaluation is one of the key initial stages that happen before a project has started. It provides stakeholders with information about the resources required and helps them decide if they have enough supplies to finish the project. How do we know how much a 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. Depending on the precision of the final estimate, there are several types of estimating methodologies.
The most accurate, hence the most time-consuming, is the definitive estimate that 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 a ROM in the condition of high uncertainty.
What Is the Rough Order of Magnitude?
Rough Order of Magnitude (ROM) estimate means a quote provided at the early phases of project planning when the scale and requirements are not clearly defined. ROM is usually created to supply a client with approximate data about the time scale of a project and requested resources so that the clients could decide if they have enough.
Rough order of magnitude estimation is also a useful document that helps understand if a project will return the investments or not. ROM is never precise. The values described in the ROM quote are loose values that might change as a project develops. 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, managers may lose the understanding of the path to follow or a solution to pursue.
A PMBOK proposes the following options of how to respond to the uncertainty:
Gathering business intelligence, performing a market analysis, consultation with experts is a good way 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 to the most probable.
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.
How to Determine Rough Order of Magnitude with High Uncertainty?
There are several techniques project managers use to prepare rough order of magnitude in the condition of high uncertainty. They vary on the level of precision and the required time. You may choose one of them or apply several methods to receive a more accurate result. Decide wisely so that you provide a realistic estimation without getting stuck with detailed analysis.
Estimation by the Analogy
The quickest way to get an estimation is to take data about the duration and cost from a similar project. Getting information about future costs is only a few clicks away, especially if your 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 about the past work, 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 estimation would significantly deviate from the actual cost. The method also appears useless when a client requests new features or characteristics.
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 for such a project will be 85*$40=$3400 and 85*50 min=70,8 hours.
The units to consider while preparing parametric estimation 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 of estimated cost. For example, $250*1000 units=$250000 while $270*1000 units=$270000. The difference is 20000, which is significant!
Also known as a probabilistic 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.
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, high. It is especially useful for cases with little data about the project complexity.
- Task: 1 to 3
- Hours: 20 to 40 to complete
- Cost: $2000 to $3000
- People involved: 2 or 3
- Task: 3 to 5
- Hours: 40 to 80 to complete
- Cost: $3000 to $5000
- People involved: 3 or 4
- 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 the 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 of project estimation. The results of the estimation can be easily communicated to the audience with different levels of expertise.
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 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 estimation so that 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 estimation 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.
For example, 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.
Let us repeat once again which of the following is true of a rough order of magnitude estimate.
ROM Rough Order of Magnitude is an evaluation instrument with low accuracy. 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 estimation 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 you know what the level of difficulty for each task is.
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.