Discover what a ROM is in project management and how to create one

When taking on a new initiative, the first step is securing buy-in. Executive leaders and external stakeholders must know whether the project is feasible with the resources, budgeting, and timeline available.

But accurately estimating project scope is challenging work that involves factoring in various elements, such as market fluctuations, team dynamics, and unforeseen risks. Instead of relying on fallible estimates, a ROM is what many leaders use to streamline this process and improve accuracy. This tactic — often employed by agile teams — gives a ballpark figure you can use to make more informed decisions about resource allocation and set realistic stakeholder expectations.

What’s a ROM?

In project management, a ROM — or rough order of magnitude — estimates a project’s scope. Project managers conduct this analysis when pitching an initiative so approvers can decide whether the team has the resources (time, budget, personnel) to complete the project — and whether it’s worthwhile regarding return on investment (ROI).

Managers might also conduct a ROM to quickly review various initiative scopes to determine which one they think is most worthwhile. They can then choose the most feasible ones and run these by upper management before initiating project work.

A ROM estimate versus a definitive estimate

While a ROM proposal provides a broad overview with less precision, a definitive estimate goes into detail, offering increased accuracy. Managers often use the former when choosing between initiatives to quickly gain a scope overview and the latter when asking for project approval. But you might stick with a ROM in both cases, since definitive estimates take more time and effort.

How to make a ROM in 6 steps

More than just numbers, a ROM estimate is about interpreting data and imagining likely scenarios. With that in mind, follow this six-step guide to craft a functional ROM.

1. Choose a template

Programs like Google Sheets and Excel often have templates available, or you can replicate one you find online, creating it yourself in your preferred spreadsheet platform. And your preferred project management software might also have a template you can use to keep everything central.

2. Assess high-level resource requirements

Now, fill in your template, considering every resource you need to complete deliverables. This typically includes:

• Time

• Software

• Physical equipment

• People

• Miscellaneous materials

• Financial needs

Don’t worry about being too meticulous in your estimates — this is just a high-level assessment. But do prioritize authenticity, not inflating or deflating numbers to please key stakeholders or fit a particular narrative. An authentic assessment — even a ballpark figure — is more valuable when based on accurate data, insights, and judgments.

3. Seek stakeholder and expert input

Take your broad estimates to teammates who might have an even better understanding of how project work will go down. You might even chat with a business process reengineering professional to determine how you can streamline project processes to lower resource use.

4. Build in flexibility

By nature, ROM estimates have a degree of uncertainty. These estimates often vary from actual outcomes, so a ROM budget likely won’t reflect project closure costs, for instance. But if you build in flexibility, you can set more accurate expectations with approvers so they’re not shocked if you use up more resources than planned.

5. Share this document

If you’ve already decided to run this initiative, share the document with all relevant approvers, providing a timeline for approval. Or, you can use this data to choose between projects before going to key stakeholders.

Some stakeholders won’t need to view all the data this document includes. For folks who want a quick-glance overview, consider creating a more audience-friendly roadmap that visually showcases the project’s scope.

Source: Project Roadmap Template

6. Use this information to guide future planning

This high-level estimate is a foundational guide for project execution, providing an initial framework that shapes how you implement your project strategy. Use this data to create more robust planning documents, like a roadmap and comprehensive resource allocation plan.

Common ROM techniques

To estimate resources and create a more accurate ROM, consider using any of the following techniques.

Program evaluation review technique (PERT)

A PERT chart is a statistical tool that helps identify the probable outcomes based on three estimates: optimistic, most likely, and pessimistic. These estimates account for uncertainty and risk and provide a range of possible durations or costs.

PERT relies on these formulas:

Expected Value (EV) = (Optimistic + 4 x Most Likely + Pessimistic) / 6

Standard Deviation (SD): = (Pessimistic – Optimistic) / 6

In these formulas, the EV provides the best estimate for a task’s completion time or cost, and the SD gives an idea of the variability or uncertainty around the EV.

Constructive cost model (COCOMO)

COCOMO is an empirical model used for software cost estimation. It uses a mathematical formula to estimate the effort and duration required based on lines of code or function points. The model consists of several formulas depending on the version (basic, intermediate, or detailed).

Here’s a simplified representation of the basic COCOMO:

Effort = a_b × (KLOC)b_b

Time = c_b × (Effort)d_b

Where:

• KLOC is the estimated size of the software product in thousands of lines of code

• a_b​, b_b​, c_b​, and d_b​ are constants that vary depending on the software project type (organic, semi-detached, or embedded)

  • a_b = effort multiplier for the project based on its size

  • b_b​ = an exponent that accounts for diseconomies of scale

  • c_b = a time conversion constant that translates the effort into a time frame

  • d_b = an exponent accounting for the nonlinear relationship between effort and duration

The final numbers represent the effort (typically in person-months) and time (usually in months) to complete a software project. You can estimate effort, cost, and duration using the total function points. Then, use this information to create a more accurate product roadmap that aligns all stakeholders on development’s scope.

Source: Product Roadmap Template

Function point analysis (FPA)

FPA is a technique for measuring a software application’s functionality from the user’s perspective. Function points are calculated based on the number and complexity of user inputs, user outputs, user inquiries, external interfaces, and internal logical files. The total function points can then be used to estimate effort, cost, and duration.

The calculation involves classifying and weighing different functionalities. Once you have the total unadjusted function points (UFP), you can convert these into effort or cost using historical data or productivity factors. The formula itself depends on the specific values and weightings used.

Three-point estimating

Three-point estimating is analogous in principle to PERT but used in more straightforward contexts. It involves making optimistic, most likely, and pessimistic estimates. You can then use these three data points to determine an expected value, often focusing on calculating the range of uncertainty around the most likely estimate.

To calculate a three-point estimate, use the following formula:

Expected Value (EV) = (Optimistic + Most Likely + Pessimistic) / 3

The numbers derived from this technique can be any metric (like cost, time, or effort) based on the relationship between the parameters used in the statistical model.

3 ROM examples

To further clarify the concept, here are three examples of how you might apply a ROM analysis.

1. Leveraging past project data

Historical data involves using information and metrics from completed projects to inform estimates for new projects. If a team has undertaken similar initiatives (which is likely), they can use the actual cost, time, and effort data from those projects to provide a ROM estimate for a new project.

Example: A software company knows a previous mobile app development project of similar scope and features took five months and cost $50,000. They use these figures as a starting point for a new mobile app project estimate, adjusting for any known differences between past projects and this one and accounting for external changes, like market and user behavior fluctuations and technological advancements.

2. Drawing from personal experience

First-hand experience refers to the personal knowledge and insights of individuals directly involved in similar projects or tasks. Someone who has repeatedly worked on similar jobs will have an innate sense of the challenges, timelines, and resources required.

Example: An experienced construction supervisor estimates the time required to lay the foundation of a building based on his experiences with similar projects. He builds flexibility into his estimate, as he knows he’s relying heavily on individual — and potentially biased — data.

3. Tapping into expert knowledge

This approach is related to first-hand experience but extends to seeking the opinions of experts who might not have direct experience with the specific project at hand. Companies might consult industry experts, senior professionals, or specialists for their opinion on the estimated resources and process improvement methodologies.

Example: A renewable energy expert offers a more accurate ROM estimate for a new solar panel installation, even though they’ve never worked with this specific panel type.

Make better estimates with Tempo’s tools

One of the best ways to estimate a project’s ROM is by looking at previous documentation, and Tempo has all the tools necessary to make effective documents you can refer to. Try Strategic Roadmaps to create thorough and customizable roadmaps and Timesheets to glean better time-tracking estimates. Sign up today.