Rough order of magnitude definition

Estimations Are Hard

For software developers, creating a meaningful technical estimate is one of the most difficult things you will ever do on a regular basis. A good estimate must take into account so many (often vague) variables like the technologies being used, the scope of work and even the client themselves. On top of that, any attempt to propose a solution based on a development-level understanding of a client’s needs often differs from what the client actually thinks they want (or need) in the first place, especially when they don’t have a technical background.
How developers create and present technical estimations also has consequences, both good and bad. Overestimation can scare a client and lead them to place a project on hold, or even find another firm to do the same job. Underestimation may initially cause the client to accept your proposal, but will put the integrity of your team and business in jeopardy. Unfortunately, even the smallest miscalculation can lead to confusion and with so much at stake, no wonder developers cringe at the thought of putting together a technical estimate. Now while an estimate is rarely perfect, there are still a number of ways to make estimates as accurate as possible.

Reaching A Common Understanding:

Without exception, when your dev team begins the estimation process, they’re naturally hesitant to put together a proposal broken down by days and hours on a piece of paper. Turning a request for proposal (RFP) into a meaningful estimate takes time, research and analysis; questions are also always bound to arise ranging from intended functionality to the true meaning of user stories. But this is good, developers should be asking questions!
Considering that most clients are not “technical individuals”, what I’ve noticed is that many clients view an estimate as an unchangeable oath written in blood. In contrast, developers tend to view an estimate as nothing more than the definition of the word itself, a rough calculation based on what is known at the time. That said, developers often change estimates as new information and requirements are discovered, often to the dismay of the client. While a software engineer may understand that even the smallest feature or change in functionality can impact the scope of an entire project, most product owners simply don’t see it that way.

Presentation Is Key: Knowing your Audience

Being able to distinguish between whether your client wants a rough order of magnitude (ROM) or a true request for proposal (RFP) can save a lot of time otherwise spent on unnecessary work. Depending on the project, various members of your team may also bring a different point of view (POV) that will impact the estimation approach being used. Believe me, product managers, developers, quality assurance and sales all see things a little differently. While this can be a good thing, having an understanding of your audience is arguably the biggest factor impacting how a technical estimate is made, presented and what level of accuracy is needed – knowing whether your estimate is going to another engineer or to your average joe makes a huge difference here.
In the past, we’ve experimented a bit with different types of technical estimates and have found that other dev teams, technical individuals or companies requiring SAAS solution want the most comprehensive estimate you can give. On top of a comprehensive estimate, they want a list of technologies, the justification for these technologies, and an hour-by-hour breakdown on every individual task – these proposals took a stupid amount of time to create, but that’s what the client wanted, that’s who our audience was. On the flip side, some of our clients were small businesses, they did not have a technical background and simply wanted a web or mobile application. The estimation approach used for them consisted of 1-3 pages where we reiterate their needs and provided a summary of the sprints each broken down by hours. The difference in terms of time spent between these two types of estimates is sometimes multiple weeks or even months.