A software project ROM estimate starts with recognizable work: product epics, integrations, nonfunctional requirements and delivery support. Size low and high effort scenarios using relevant history, then convert hours into cost or fee. Include testing, release and coordination explicitly instead of treating feature development as the whole project.
Terms used in this guide. fee: the amount charged to the client; cost: the expense included in the stated project model; margin: revenue left after the included costs; margin percentage = that amount / revenue × 100; baseline: the approved original plan kept for comparison.
In plain words
A software ROM estimate is a rough range for building something before the requirements are final. You list the big pieces (called epics), give each a low and a high effort, add the work that is easy to forget, such as testing and release, then turn hours into cost. It tells you the order of size of the project, not the delivery date.
Who this helps: Presales consultants, product owners, engineering managers and project managers who are asked for a software budget early.
Questions this guide answers:
- How do you estimate a software project early?
- What is a ROM estimate for software development?
- How accurate is an early software estimate?
Read first: What is a ROM estimate? explains the basics and the lifecycle this guide builds on.
How do you calculate a ROM estimate for a software project?
Total effort = feature hours + QA + coordination + deployment
Labor cost = sum of each role’s hours × its planning rate
The role totals, not the number of screens or epics, determine modeled labor cost. Add other project costs separately and use the same coverage at both endpoints.
What do you do when the client brief is only a few sentences?
Many software ROMs start from a single sentence: “We need a customer portal connected to Salesforce so customers can see orders and upload documents.” It names a user group, two capabilities and an integration. It does not say how users sign in, who owns the records, how long documents are kept or how clean the data is. Counting screens would ignore most of the delivery risk.
A presales consultant first rewrites the brief as a scope hypothesis: a browser portal, one customer organization per account, read-only orders, document upload and one existing API. Each item is marked as stated (“customers see orders”) or inferred (“orders are read-only”), because inferred items carry the uncertainty. Then the five questions that move effort the most go to the client, each with an owner:
- Who signs in, and is there an existing identity provider?
- Is the Salesforce API available and documented for these records?
- Must users edit orders or only view them?
- Do uploads need malware scanning, retention or approval rules?
- Who supplies sample data and accepts the finished workflow?
Do not promise that a quick look at a vague brief resolves it. Its useful output is the next decision: reject an implausible budget, investigate a dependency (for example, test API access with sample records) or develop a scoped first phase. If the client cannot answer a high-impact question, keep both scenarios visible rather than quietly choosing the cheaper one.
What makes an early software estimate usable?
“Build a portal” does not say how users sign in, which roles exist, who owns the data or what service level applies. Before choosing a number, do three things.
- Describe the user journeys and the system boundaries.
- Write one line of acceptance for each journey, so “done” is not a matter of opinion.
- Keep two kinds of uncertainty apart and give each its own owner (below).
| Kind | Example | Owner | Next action |
|---|---|---|---|
| Delivery uncertainty | The API is undocumented | Engineering manager | A short API test with sample data |
| Scope decision | Notifications by email, SMS or both? | Client sponsor | A decision in the discovery readout |
The example below assumes a B2B portal with existing brand assets, a documented API, two customer roles and one live plus one test environment. It excludes mobile apps, payment processing and bulk historical migration. Two epics with the same name can hide very different work, and the five questions above show the kind of detail that separates them. Keeping the two uncertainty types apart stops the high case from quietly combining every optional feature with every technical difficulty.
How do you use a similar past project without copying it?
If you have no comparable project, sketch work packages, ask an experienced engineer to review the most uncertain ones, separate research from build and widen the range. If you do, treat it as a package inventory, not an answer.
Suppose a similar portal took 320 development hours at USD 60 and 120 testing and coordination hours at USD 50: 19,200 + 6,000 = USD 25,200 of labor cost. It used an existing identity provider and clean sample data, and had no document upload. Those differences set the two cases:
| Case | Change from the reference | Labor cost |
|---|---|---|
| Low | Add 80 h of uploads at USD 60; keep the existing identity provider | 25,200 + 4,800 = 30,000 |
| High | Add 120 h of uploads and 100 h of identity and data work at USD 60 | 25,200 + 7,200 + 6,000 = 38,400 |
Re-price the hours at today’s rates, never a past discounted fee, add non-labor cost, and then divide by (1 − target margin) to get the price range. Send the range with the scope hypothesis and what would invalidate it, such as write-back to orders or a new identity platform.
How do six epics become an effort range?
Each epic gets a low and a high effort, and the supporting work is added as its own lines.
| Work package | Low hours | High hours |
|---|---|---|
| Sign-in and role access | 40 | 80 |
| Customer profile | 32 | 56 |
| Order view | 48 | 88 |
| Document upload | 40 | 72 |
| Notifications | 24 | 48 |
| External-system integration | 56 | 112 |
| Feature development subtotal | 240 | 456 |
| QA and acceptance support | 80 | 152 |
| Project coordination | 48 | 80 |
| Deployment and handover | 32 | 48 |
| Total | 400 | 736 |
- QA, coordination and deployment are planning allowances for this example, not industry ratios.
- If an epic already includes its own tests, remove the overlap before adding a QA line.
- Estimate separately anything the client requires on top, such as penetration testing.
- Each task sits under one category and one owner.
Where the range comes from
The feature subtotal grows by 216 hours between the cases. The integration accounts for 56 of them and the other features for 160. So a short API test is valuable but does not settle upload handling or acceptance.
Scenario: the walk-through that finds the missing work
- Before the estimate goes out, a developer and a tester walk through one full transaction, including a failed upload.
- They ask: can a customer sign in, see an order, upload a document and recover from an error?
- They find that the low case (40 hours) has no time for the failed-upload path, so the upload package is set closer to the high end of its 40–72 range.
- The tables below show the first-draft figures from before this walk-through. After it, the upload package moves toward 72 hours, so the low-case hours, cost and fee must be recalculated before the range is sent.
That walk-through finds the work a screen list misses.
How do role hours become a software cost estimate?
Price each role’s hours at its internal cost rate. Keep the role lines visible: one blended rate hides the effect of a different mix, for instance when a security specialist replaces part of the development effort.
| Role | Rate | Low hours | Low cost | High hours | High cost |
|---|---|---|---|---|---|
| Development | USD 60 | 240 | USD 14,400 | 456 | USD 27,360 |
| QA | USD 45 | 80 | USD 3,600 | 152 | USD 6,840 |
| Coordination | USD 70 | 48 | USD 3,360 | 80 | USD 5,600 |
| Deployment | USD 65 | 32 | USD 2,080 | 48 | USD 3,120 |
| Labor cost | 400 | USD 23,440 | 736 | USD 42,920 |
From cost to price
- At a 30% target margin and no revenue-based charges: 23,440 ÷ 0.70 = USD 33,485.71 and 42,920 ÷ 0.70 = USD 61,314.29.
- These are costs and prices, not the same thing; the client sees only the price range.
Scenario: a mandatory external assessment
The client requires an independent security assessment costing USD 4,000, outside the role effort. The low-case cost becomes 27,440 and the price 27,440 ÷ 0.70 = USD 39,200. If the assessment is added to the scope without changing the price, the margin drops. Before sending, check what the client actually receives at each end of the range.
Does an hours estimate tell you the delivery date?
No. Four hundred hours cannot simply be divided by a team’s capacity. Three things stand in the way:
- Dependencies. Integration access may arrive after the first sprint, and a client approval can block a release.
- Sequence. QA follows testable increments.
- Availability. A specialist needed for 32 hours across four weeks is different from one free for a single week.
Convert effort to a tentative sequence
- Begin with access and architecture checks.
- Place development in testable increments.
- Reserve time for client review before release.
- Record waiting time: it adds no supplier hours but still moves the date.
A shorter schedule can raise cost if it needs parallel staffing or premium specialists, and stretching the same work over more weeks does not by itself lower labor cost. Review the most sensitive epic first: here the integration doubles between cases, so a short API spike may narrow the range more than polishing every screen estimate.
How accurate is an early software ROM estimate?
Accuracy depends on scope maturity, comparable history and unresolved dependencies. There is no universal percentage appropriate to every software project. Track the version, compare the same scope with later actuals and learn which components routinely expand. A well-explained range can be useful even before it is narrow.
Real example: an engineering manager sizes a customer portal
An illustrative story with invented figures, to show how the idea works in a real office.
Arjun, an engineering manager, is asked by a presales lead how big a customer portal is. Marketing has sent a six-epic list. Arjun gives each epic a low and a high effort, then adds testing, coordination and release from his own team’s past projects. His totals are 400 to 736 hours and USD 23,440 to USD 42,920 of cost.
The presales lead divides by 0.70 for the 30% target margin and sends the sponsor a planning price of about USD 33,500 to USD 61,300. Arjun adds the sentence that matters: the integration is the most uncertain feature, and a three-day API test with sample data will narrow the range. The sponsor sends the API documentation the same week.
When do you give a software ROM, and who needs it?
Software work gets a ROM at the same moments as any other project, but the reviewers differ: the engineering manager checks that the epics are real, and the presales lead checks that the range is priced. Both sign before it goes out.
| Stage | Who produces it | Checkpoint |
|---|---|---|
| Qualification | Presales consultant with an engineering manager | Epics listed from the brief; unknowns (integrations, data, security) named |
| Sizing | Engineering manager | Each epic has a low and high effort; testing, release and project management are included |
| Pricing | Presales lead | Role hours × cost rates, then price at the target margin |
| Planning | Project manager | Hours converted to calendar time using the real team size and availability, not hours ÷ 8 |
The same range feeds two decisions: whether the client can afford the project, and whether the firm should bid at all.
Software project ROM estimates: frequently asked questions
Can story points become a client fee?
A team needs a supported conversion to effort and role cost before using relative sizes in a commercial model. Story points from different teams are not interchangeable. Preserve the calibrated scope family, observed delivery history and uncertainty instead of multiplying an arbitrary point count by a universal hourly price.
What should be investigated first?
Choose the unresolved question with a material effect on feasibility, cost or timing. In this example, test integration access and representative transactions, then validate role permissions and document handling. Investigation should produce evidence that changes the relevant package estimate.
Should a software ROM include a contingency?
Show uncertainty through the low-to-high range and a named risk, rather than hiding a percentage in the total. If you add contingency, state it separately so the client and your delivery team can see it.
How do I estimate an epic I have never built?
Ask the team for a low and a high case, write down what would make it high, and record the question discovery should answer. A wide range on a genuinely new epic is honest.
Can I turn the effort range into a fixed fee?
Not directly. A fixed fee needs agreed scope and acceptance criteria; the ROM does not have either. Use it to decide whether to pursue, then estimate the defined scope.
How do you work the portal example in Managed Margin?
Reproduce the portal's low case in an estimation strategy: development 240 hours at USD 60, QA 80 at USD 45, coordination 48 at USD 70 and deployment 32 at USD 65. In the stage or weekly resource grid, choose loading that reconciles to those totals under the selected working-hour basis. For example, one developer at 100% for six 40-hour weeks produces 240 hours. Review the support-role totals separately rather than assuming a developer headcount covers them.
With no additional costs, labor is USD 23,440. Select Target Margin at 30% to derive the fixed fee; select Quoted Price instead to assess a buyer's existing budget. Create another strategy with the high-case role effort and compare it with the first. The optional ROM range changes price while retaining each strategy's effort. Finalize the accepted scenario and carry its roles, stages and costs into delivery.
Explore the pricing and estimation workflow or review the delivery margin workflow.
Background reading: what is a ROM estimate? and 5 Project Estimation Methods for Services.
Continue the sequence: guides to read next
- What Is a ROM Estimate? Meaning, Cost and Example: the definition behind the six-epic example
- Parametric Estimating in Project Management, With an Example: sizing from a driver when epics are too coarse
- Three-Point Estimating and the PERT Formula, With an Example: handling uncertainty on a single epic
- ROM Cost Estimate Examples for IT Projects: four more worked ROMs from other kinds of services work
Sources and methodology
The worked figures are original educational illustrations. The linked references provide background for the estimating and management concepts; they do not establish the example rates or guarantee the outcomes. Product instructions describe the current implementation and are separate from methods the reader performs outside the application.
The examples, templates and calculations are original editorial illustrations, not market benchmarks or customer results. Monetary amounts are in USD, exclude tax unless stated, and use the cost boundaries defined in the article. Validate assumptions against your own delivery history before quoting.
Further background: QSM early software sizing. The worked arithmetic and scenarios above are original; this reference provides context and is not a source for market rates or the stated example amounts.
The application walkthrough was checked against the current stage, pricing, cost-rule and delivery calculation code on 13 October 2026. Forecasts describe recorded actuals plus the remaining plan, not predicted customer outcomes.