Saturday, May 28, 2011

The ROM Curse: When Guesses Replace Estimates

A ROM refers to a rough estimate of cost and time for a software project or software feature.  It usually stands for Rough Order of Magnitude, although I've heard people mistakenly but perhaps prophetically translate ROM as Random Order of Magnitude.  In an IT setting, customers and bean counters can legitimately ask for ROMs to assist in budgeting, planning, or prioritization.  However, many organizations are too immature to handle this practice and the consequences are often painful for the delivery organization.

As a planning number a ROM should never represent a commitment as it rarely has analysis to support it, however this fact is often lost once the numbers are delivered.  For reasons malevolent, ignorant or practical, too many senior managers and customers later use the ROM as a negotiating cudgel to drive down the real cost of the project, or to change the scope of the solution, leaving the weak project lead holding the bag on a project destined to miss on cost, quality or expectations.

Even more insidious, ROMs become the check written by one party to be cashed against another party's bank account.  For expediency, people who aren't going to be on the hook for delivery create the estimates, but then accountability for delivery is weakened.  As if this isn't bad enough, a more serious dysfunction is created, too.  The implicit manipulation of those who must deliver by those who do the estimate creates a culture of disdain for the delivery personnel.  Over time, only delivery staff with lower skill or lower self-esteem will work in such an environment.

Finally, because ROMs are attractive to the customer - they are created quickly and no customer accountability is at stake - the desire to use ROMs as a surrogate for real planning elbows out any discipline and skill for real planning.  Having lost its planning ability, the organization will consequently lose its ability to do anything novel or complicated. This fact alone may be responsible for many IT failures. 

Like any drug, ROMs feel good in the short term, but the long term consequences are unpleasant for those who deliver.  Your mandate is to fight off the ROM and instead ask those who will deliver to produce analysis-based estimates that you are willing to commit to, at least, until your organization is mature enough to handle ROMs.