What is a Rough Order of Magnitude (ROM) in project and business management?

Every project manager knows the drill. At a meeting, a stakeholder asks for a cost estimate when the project only exists as a concept. Detailed plans and breakdowns are months away, but a decision is required now on whether to proceed, allocate budget, or move on to other projects.

This is a question you can’t dodge, and providing a “definitive” figure that came out of thin air isn’t an option either. This is where you need the Rough Order of Magnitude — a structured, defensible ballpark figure made with minimal project details. Let’s see how ROM is different from budget and project plan, how to develop it, and why even bother.

TL;DR

• A ROM in project management is a quick estimate made before detailed information is available.It is used to judge feasibility and make a final decision on whether to proceed with the project.
• You can build a ROM using estimation techniques like analogous, parametric, expert judgement, three-point, bottom-up, or T-shirt sizing.
• Once project scope is 15-25% defined, project management professionals typically move on from a ROM to forming a definitive estimate.

What is a ROM?

A ROM (Rough Order of Magnitude) in project management is an informal estimate of the project’s costs and required effort. Basically, it’s a buffer zone between a quick math session in your head a second after you get the idea and a definitive project budget.

The ROM is a useful step in the validation of your idea: it can help determine whether the project is feasible for the business, whether there are necessary resources, and if the actual outcomes are worth the investment. For stakeholders, it’s a helpful way to compare the costs to the benefits and make the final decision.

ROM vs. Definitive estimates

It is essential to distinguish a ROM from more precise estimates that appear later in the project life cycle after scope, requirements, and work breakdown structure (WBS) are locked down.  

Aspect	ROM Estimate	Definitive Estimate
Timing	Initiation / concept phase	Planning / execution phase
Project Definition	0–5%	80–100%
Typical Accuracy	-25% to +75% (or wider)	±5% to ±10%
Purpose	Feasibility, prioritization	Budgeting, contracting, execution
Effort to Prepare	Hours to a few days	Weeks to months

The accuracy ranges measure how much we still don’t know. The less data we have going in, the more risk and guesswork sits behind the number. Vice versa, the better we understand what we are doing, the more precisely we can estimate the costs.

As a project gets better defined, the estimate gets tighter, because we’re calculating instead of guessing. But for a quick idea scribbled on a napkin, a wide, uncertain range is an accurate reflection of where the project stands.

You probably also spotted a critical pattern. All estimate types have a larger upward range than downward. For a ROM, the minimum is -25% and the maximum is +75% — this asymmetry reflects an essential reality that there are more possible options above the nominal value than below.

So, when you’re presenting a ROM, try to focus the conversation on the upper bound, not the lower. Stakeholders tend to gravitate towards the smallest number, but you’ll need to direct their attention to the full range.

Different authoritative sources define slightly different ranges:

• Rough Order of Magnitude (ROM): -25% to +75% (lowest detail required)
• Preliminary Estimate: -15% to +50%
• Budget Estimate: -10% to +25%
• Definitive Estimate: -5% to +10% (highest detail and accurate costs required)

What this means in dollar terms:

ROM Estimate	ROM Range (-25%/+75%)	Preliminary (-15%/+50%)	Budget (-10%/+25%)	Definitive (±10%)
$100,000	$75k – $175k	$85k – $150k	$90k – $125k	$90k – $110k
$500,000	$375k – $875k	$425k – $750k	$450k – $625k	$450k – $550k
$1,000,000	$750k – $1,750k	$850k – $1,500k	$900k – $1,250k	$900k – $1,100k
$10,000,000	$7.5M – $17.5M	$8.5M – $15.0M	$9.0M – $12.5M	$9.0M – $11.0M

Why provide a ROM — or the cost of not doing it

• PMI's Pulse of the Profession study found that ~⅓ of complex projects fail, nearly twice the 13% rate of failure for projects overall.
• An earlier PMI report says that 28% of project failures trace to inaccurate cost estimates.
• According to BCG, the cost of failure for a typical large company can exceed €20 million a year for a single program.
• And in another 2024 BCG study, nearly half of C-suite respondents said more than 30% of their organization's technology-development projects were both late and over budget.

These dooming statistics are self-explanatory when it comes to the benefits of having a ROM, but let’s hammer this point home. Here’s how a ROM can help you:

• Decide whether a project is worth pursuing. Compare its likely cost with the expected business value before committing significant resources.
• Set realistic funding expectations. Give sponsors and finance teams an early indication of how much budget the project may require.
• Compare competing initiatives. Put rough estimates against different projects to help prioritize where limited resources should go.
• Identify cost and scope risks early. A wide estimate range can signal that more discovery or planning is needed before making a firm commitment.
• Avoid false confidence. A range acknowledges that early estimates are uncertain instead of presenting an early guess as a precise project budget.

In other words, a ROM is a good step 1 towards building your project plan. Your eventual scope and budget will naturally differ, but when a ROM is there for a reality check, it’s easier and safer to make final decisions.

How to develop a ROM with limited data

With minimal detailed information on your hands, you won’t be able to build a definitive estimate. Instead, you must rely on estimation techniques and even do some guesswork at some point. As for the execution tool, you can choose whatever works best for you and your company.

Step 1: Define the scope

Before estimating your project, you need to clarify what it includes and what is explicitly excluded. For building a ROM, you don’t need detailed requirements — just come up with a short scope statement covering the main objective, the important exclusions, and the deliverables/end result you aim for.

Example:

This ROM covers the migration of our North American sales team to a cloud-based CRM, including authentication, a customer dashboard, standard reporting, and data migration. It excludes ERP integration and custom mobile development.

If there are any known constraints (in budget or team resources, for example), dependencies, target dates, or tech stack requirements, make sure to include those as well.

For a software project, the variables that may affect cost and effort might include:

• Number of features or modules
• Users or data volume
• Integrations
• Development and testing effort
• Infrastructure
• External vendors or licenses
• Compliance requirements

Step 2: Choose an estimation technique

There are multiple project estimating techniques that can help you build a ROM. These can be used together or separately depending on your goals — or to cross-check the result.

Analogous estimating

What to do	When it works best
Use a similar completed project and base your estimations on the past data	When you don’t have much information on specifics When you have a good historical comparison When the project needs to stick to a certain company standard

Analogous estimating uses data from previous projects as a starting point with adjustments for differences in size and complexity if necessary.

Example: 

A CRM implementation for 500 users cost $200,000. A similar project for 750 users starts at roughly: $200,000 × 750 / 500 = $300,000

If your project team works in Jira, your historical Jira data can give you a much stronger starting point. You can use past projects, Epics, tracked effort, and planned-vs-actual data to ground your assumptions instead of estimating entirely from scratch. 

For example, with Planyway for Jira, you can use historical planned and tracked time across Jira work to see how similar work actually performed and use those patterns to inform your new estimate.

Parametric estimating

What to do	When it works best
Use a similar completed project, but focus on specific unit rates, not the entire cost	When you have a project with reliable unit-cost data When the scope of the new project is similar to older ones When you have a lot of measurable variables or deliverables When you assume there will be a lot of repeatable tasks

This technique is also useful when you already have a solid database from your past projects. Use historical data to derive Cost Estimating Relationships (CERs) and provide a more accurate estimate. Apply a known cost or effort per unit using this formula: 

Quantity × cost per unit = estimate

Example:

• $15,000 × 4 modules = $60,000
• $2,500 × 50 workstations = $125,000
• $12,000 x 30 KLOC* = $360,000

*thousands of lines of code

Expert judgment

What to do	When it works best
Ask several experienced specialists to estimate independently and compare their assumptions	When you have a completely new project or concept When historical data is limited or absent When you have your own expert pool

This technique is particularly good for idea validation when combined with another estimation method. Several points of view can shed light on new perspectives, valuable insights, or even threats you may have missed.

However, it’s dangerous to just average the numbers if one expert estimates 800 hours and another 1,500. Instead, investigate what’s driving the difference and run another round of expert interviews if necessary.

Three-point estimating

What to do	When it works best
Explore three different scenarios: Optimistic (O) Most likely (M) Pessimistic (P)	When you have a project with significant uncertainty When you need to give decision makers a better understanding of the risks

This technique is useful to give you a better understanding of different courses of actions you may take in various scenarios.

A common PERT (Program Evaluation Review Technique) formula is the following: (O + 4M + P) / 6

Example: 

You're estimating how long it'll take to build a new landing page for a client.

• Optimistic (O): 3 days — if everything goes smoothly with no revisions
• Most likely (M): 5 days — your realistic gut-check based on past projects
• Pessimistic (P): 10 days — if the client keeps changing their mind or dev runs into bugs

Estimate with the formula: (3 + 4×5 + 10) / 6 = 33 / 6 ≈ 5.5 days

Bottom-up estimating

What to do	When it works best
Break the project into several major stages, estimate each of them, and then do a grand total	When the major components of a project are already understood When a work breakdown structure (WBS) has already been approved or remains relatively the same for all projects in the company

This technique generally consumes more time, but it may be one of the most accurate ones. With bottom-up estimating, you’re unlikely to miss any costs or overlook an important constraint. To use this technique, you don’t need an actual, detailed, up-to-date WBS for this specific project, but you do need to understand all the major workstreams that will be involved.

Example:

You’re building a new digital SaaS product that requires developing an app and coming up with a brand identity.

Here’s how you can estimate the project using the bottom-up technique:

	Time	Money
Discovery	100 hours	$5,000
Brand identity (logo, naming, style guide)	200 hours	$8,000
UX/UI design	400 hours	$15,000
App development	900 hours	$60,000
QA and testing	300 hours	$10,000
Deployment	100 hours	$3,000
Total cost	2000 hours	$101,000

Still, keep the breakdown high-level. A ROM isn't a detailed work breakdown structure. 

T-shirt sizing

What to do	When it works best
Estimate the project’s scope using the sizes of a T-shirt: XS (Extra Small): very quick task (under 1 day) S (Small): Simple feature or minor fix (1 to 3 days) M (Medium): Moderate complexity (1 week) L (Large): Complex scope (2 to 3 weeks) XL (Extra Large): Massive scope or high uncertainty (1 month or more)	When you need a quick high-level estimation When you can’t estimate timelines, money or hours When you already have a solid project portfolio to compare against

Consider this technique an add-on for analogous estimation. This one is perfect for agile projects and teams that need to handle uncertainty quickly, but it may not be the best choice if you don’t have a lot of specific projects to compare against.

Example:

You have plenty of different projects in your team’s backlog. One client wants a "Forgot Password" email button, another wants a whole new reporting dashboard, and your finance department is asking for AI-powered predictive analytics.

Here’s how you can size the projects in T-shirt terms:

• The “Forgot Password” email button is an XS as it’s a one-line copy change that can be done by lunch;
• New reporting dashboard is an L because it touches multiple screens, needs design and backend cross-team work;
• AI-powered predictive analysis is an XL since it’s new territory with lots of unknowns and likely a multi-sprint effort

Step 4: Triangulate the estimates and establish a range

If you combined multiple techniques to estimate your project (which is highly recommended), compare the results you received.

For example:

Estimation technique	Estimated cost
Analogous	$80,000
Parametric	$75,000
Expert judgment	$90,000
Bottom-up	$85,000

Now, instead of a single estimate, you have a cluster around $75K–$90K, which gives you more confidence.

But if your numbers diverge significantly, investigate why and use more estimation techniques if necessary. The explanation can be in different assumptions, scope gaps, or missing cost drivers.

Step 5: Do a reality check of the ROM

When building a ROM, document things such as team size and skill level, tech stack, vendor and licensing costs, productivity factors, stakeholder availability, dependencies, compliance requirements, etc. Don’t forget to explicitly state what’s excluded.

Example:

This ROM assumes three developers, existing authentication infrastructure, standard CRM functionality, and no additional third-party licensing. It excludes custom mobile development and ERP integration.

Before presenting your final estimate, ask:

• Does it align with similar projects?
• Does it reflect the project’s size and complexity?
• Are the major costs accounted for?
• Does the timeline make sense?
• Does the estimated effort fit the team’s capacity?

At this stage, Jira teams should also check historical data and current team capacity. 

Planyway for Jira can help you compare planned work with actual tracked time and see current workload across projects. This gives you another reality check: can the team realistically take on the estimated effort without overloading the work already in progress?

Step 7: Turn the ROM into a high-level roadmap

If and when the project gets the green light, turn your estimate into an early delivery plan.

For Jira teams, Planyway for Jira can help visualize that high-level roadmap, connect work across projects, map dependencies, and see how planned work fits into available capacity. You can create custom views for each stakeholder, too.

Also, Planyway allows you to build the roadmap in draft mode first, experimenting with timelines and dependencies without immediately changing the underlying Jira data. Once the plan is agreed on, you can commit the relevant dates and planning decisions to Jira and move from a rough roadmap to execution, tracking the project progress.

How to create a ROM: example and an Excel template

Let’s try and brainstorm on a ROM with an example of a daily PM routine.

Say, a software development firm has been asked to build a web app for around 500 internal users. The application would require user authentication, a dashboard, and reporting functionality. There are no additional project details.

Here is how this specific project can be estimated and then turned into a ROM.xlsx.

1. Scope statement

This ROM covers:

A standard web-based application for internal users, with authentication, dashboard views, and report generation.

This ROM excludes:

Custom integrations, mobile development, and data warehouse construction.

2. Estimate development

Technique	Calculation/Comparison	Result
Analogous estimation	Similar project last year cost $80,000 and took 4 months; New project is slightly larger	$85,000
Parametric estimation	4 modules x $15,000 per module	$60,000
Expert judgement	Senior dev #1: $85,000 Senior dev #2: $95,000	$90,000
Three-point estimation	O = $60,000 M = $80,000 P = $130,000 (60+320+130)/6	$85,000

3. Triangulation

Estimates cluster around $80,000–$90,000. Single-point estimate: $82,000.

4. Range Application

Boundary	Calculation	Result
Lower (-25%)	$82,000 x 0.75	$61,500
Upper (+75%)	$82.000 x 1.75	$143,500

ROM proposal: $82,000 (range: $61,500–$143,500)

5. Assumptions

• Standard technology stack; no new tooling is required
• Three developers available for the duration of the project
• No data migration from legacy systems
• No third-party licensing costs beyond the base platform

Example of how the final presentation may look:

“Based on the current project scope, the ROM estimate is approximately $82,000, with a range of $61,500 to $143,500. Since the project is still at an early stage of definition, the estimate reflects the PMBOK ROM accuracy range of -25% to +75%. This estimate assumes a stable technology stack and no integration work. As the requirements become more defined, we will be able to narrow the estimate range.”

In practice, you'll want a reusable format you can use for any project. Here is an Excel template that mirrors the structure above: scope statement, estimate development (with all four techniques side by side), triangulation, range application, and assumptions.

When to move beyond the ROM

No matter how good, a ROM is a temporary artifact that does not replace a project plan or a budget. Its purpose is to guide the idea through the initiation phase and give way to more advanced analysis and documents when the project moves forward.

You can move to a more detailed estimate when:

• Project definition exceeds 15–25%
• Vendor quotes or subcontractor bids become available
• Architectural or technical designs are drafted
• A list of specific deliverables and features is finalized

Transition to a budgetary estimate (accuracy -10% to +25%), and then to a definitive estimate (+5–10%).

A good ROM is only the beginning

It’s essential not to treat your rough order of magnitude as a final perfect number. Instead, ROM is meant to be rough, fast, and uncertain as long as it answers one question: if the project is worth pursuing. Combining different estimation techniques brings several lenses to the same problem, ideally giving you that defensible range instead of a random number off the top of your head.

Without building your ROM for you, software solutions like Planyway can help it “talk” to your team’s Jira artifacts and evolve into a definitive estimate.