A Rough Order of Magnitude Estimate (ROM estimate) is an estimation of a project’s level of effort and cost to complete. A ROM estimate takes place very early in a project’s life cycle — during the project selection and approval period and prior to project initiation in most cases. The main purpose of the ROM estimate is to provide decision-makers with the information necessary to make a decision on whether it makes sense to move forward with the project based on the estimated level of effort, in terms of completion time and cost.
Developing a ROM estimate is as much a skill as it is an art. First and foremost, subject matter experts should be involved in level of effort estimations. Second, when developing a ROM, it is important to understand that the estimate is a “Rough Order of Magnitude” estimate that will have an accuracy of about plus or minus 50%. Depending on the source, the variance can be as much as 100%. A variance of -25% to +75% is also common for ROM estimates. The point is to provide a “ballpark” estimate using the information available at the time.
A ROM estimate’s variance is rather large, but it should not dissuade you from making an attempt. Remember that some information is better than no information. Also remember that the estimate is based on the information available at the time of developing the ROM estimate. As the project moves forward, expect to further improve the estimate, when more information is obtained and requirements are further refined during the initiation and planning phases of the project (PMBOK students, do you recall the term progressive elaboration?)
The following information provides a comparison of the three general kinds of estimates as the project makes its way through the life cycle.
When developing a ROM estimate, it is best to try estimating in buckets of time and cost. Providing categories may help estimators who otherwise would not be able to provide one number due to the limited amount of information available at the onset of a project. The example below provides categories of “Low”, “Medium”, and “High” levels of effort. Using such a scale may be easier than trying to pull a number out of a hat. It also sets the expectation on both sides — project team and client — that the ROM estimate has a large variance and should be recognized as just an initial ROM.
Using buckets, or categories like the ones listed above, decompose the work from top down to a level of detail that makes sense given the amount of information available. Assuming that the project is in the very early stages, and stakeholder needs and requirements are at a high level, it is safe to assume that the breakdown of work will not be significantly detailed. The point is not to develop a full-blown WBS here. The point is simply to compartmentalize the work into a set of activities that make sense and that can be measured. For example, developing a web application, the work list might only be a few items like so:
Apply a category of effort to each piece of work to come to a ROM estimate. That’s it in a nutshell!
There is a great deal more to know about cost estimating and cost estimating techniques (e.g., Applying learning curves, complexity factors and risk factors; PERT time estimation; Software estimation techniques such as function point analysis technique and COCOMO — http://cost.jsc.nasa.gov/COCOMO.html). But this is a good primer, at least, on ROM estimation. The related links, below, offer additional tips on cost estimating. Also, refer to the Society of Cost Estimating and Analysis (http://www.sceaonline.org/), which is a thought leader in this arena. Expect lots more to come on cost estimation!
Would you like to share additional thoughts or information on ROM cost estimation? Add them to the Comments section below.