



The Technology of Estimating, Part II
This article appears in the monthly feature, Technology Issues of the May 2002 Transportation Builder, the Official Publication of the American Road & Transportation Builders Association (ARTBA), page 26.
![]()
The following presentation on the estimating process and the selection of an estimating software was written and delivered by Farid Saddik, Information Technology Director of R&L Brosamer, Inc. at the BID2WIN press conference held at CONEXPO-CON/AGG 2002 in Las Vegas Nevada. Mr. Saddik's presentation notes have been edited for publication and are reprinted here with his permission.
Part Two in a Three-Part Series provided by BID2WIN Software, Inc.
Competing for the Contract
The estimating and competitive bidding processes in place today, and for the foreseeable future, collectively constitute a fascinating business sales model.
Think about it: Contractors are expected to price a project relying on a set of - more often than not - incomplete or faulty technical plans and specifications, while agreeing to be governed by a large mix of federal, state, county, and city laws, statutes, ordinances, rules, regulations, standards, and other contractual lingo that frequently conflicts with one another.
And if that wasn't enough, the contractor relies, for a good chunk of the work, on subcontractors, who have to agree to the exact same conditions as the contractor. It's also not uncommon for the contractor to get prices on a quarter of the bid items only minutes before the bid closes!
Anyone involved in the competitive bidding process knows that the intricate details that I have left out (they really qualify for a series of articles on their own) are even more mind-boggling.
In all, the basic idea is to come up with a contractually binding price that incorporates all of the above, and oh yes - it would be nice to be the lowest bidder as well!
When you consider that the typical markup in a competitive market can be as low as seven or eight percent, including overhead, you very quickly begin to sober to the fact that - out of this entirely hilariously - haphazard, imperfect process - the contractor has to produce a perfect estimate with little, if any, margin for error. And you know what is absurd about the whole process? It works! Well, kind of!
Choosing the Right Estimating Software
Because of the inherent shortcomings of the entire bidding process, settling for an estimating software package that adds to its complexity, or forces you to compromise, or promotes errors is really tantamount to professional malpractice. That is why at R&L, we placed a lot of emphasis on selecting the right estimating solution. In the past, and until mid-2000, we used, evaluated, and demo-ed many estimating software packages. Having been through the process, I'd like to share some of the things that are important to consider before purchasing. Keep in mind that the company you choose to purchase from is a critical component of the overall long-term beneficial use of the software.
1. Commit the time and resources necessary to thoroughly evaluate the software.
Once you have a clear but realistic definition of what you deem as "terminating factors," you'll quickly weed through most estimating packages and end up with a handful that are worth a closer look. We narrowed the field down to exactly three.
At that point of the selection, the only way to tell whether the software is suited for your needs is to commit the resources necessary to fully test it - and I am not talking about a half-hour or half-day of controlled demo use. I am talking about either restaging a bid that was just finished, or actually running each of the different packages on a good-sized upcoming bid, with appropriate precautions. In our case we always opted for the latter, as we deemed it more reflective.
2. Look for an estimating program that prepares bids the way you do.
Not far into the evaluation process of one of the packages, we discovered that the very business model the software used (to prepare the bid) was defective - the kind of defect that can cost you a bid, or cost you a few hundred thousand dollars. There were other problems, too. Consider, for example, that the cost detail report could not print out a total cost?! Rather than convolute our bidding process to suit the software, we decided to take that software out of the running. Our decision to disqualify this software was further cemented when the powers that be at that company did not see anything wrong with its shortcomings. That leads me to the next consideration in selecting software and a software company to work with.
3. Work with a software company that wants to work with you.
From the second software company, we tried our best to obtain a trial release - for evaluation purposes. We were even willing to pay a reasonable fee for it. We made our intent clear: We had to test the software fully before committing our company to it. They told us we had to show our seriousness by buying the software first! One would think that the motivation of a potential customer to commit tremendous resources to the evaluation of their software would constitute enough seriousness.
In any case, we ended up actually purchasing the software just to evaluate it - which was not cheap. We worked with it extensively and here is what we found...
The software allowed only three levels of detail. To give you a sense of how significant this limitation is for a contractor that does bridges, paving, or underground, I'll offer the image of trying to fit 11 people into a Volkswagen at once.
We called the company and spoke to one of their VPs, who told us that they had no intention of adding more detail levels to the program. Although as a customer we were disappointed in the response, the IT person in me understood why. Their development environment (which is probably what caused the limitation in the first place) would make it very difficult for them to modify the software in that fashion. Indeed, one of their major shortcomings was that each level of detail behaved completely differently from one another and there was no uniformity to the user interface whatsoever. And by the way, their custom reports were expensive, which is again a function of the programming environment! Essentially, poor software architecture ruled out this company's product from our selection process.
4. Consider the development environment and programming language of the software.
A fundamental requirement that is often overlooked when selecting any software, but is doubly important when it comes to selecting estimating (and accounting) software choices is the programming language and development environment in which the software is written. Why is this crucial? Because it tells you about the quality of the software and where it is headed in the future.
Five years from now, much will have changed in the technology sector, but it will be a lot less likely that you'll see the demise of Microsoft; Oracle, or IBM than you'll see the demise of a lot of off-the-wall development environments some companies are using. Paying tens or hundreds of thousands of dollars for a software that is not anchored by one of the top development environment vendors just does not make sense. Though some people may dismiss the appearance of a Microsoft Certified Partner logo, for example, as merely a "marketing strategy" it usually proves to be much more!
The right to align one's company with any of these industry giants typically has to be earned through rigorous and strict development processes, which require that certain guidelines and standards be met. This usually translates to better planning and a well thought-out architecture. Remember software company number 2 (above)? They could not make modifications to their software because the product was poorly designed in the first place! You'll have a better chance selecting an estimating package that is consistent, accurate, easy-to-use, powerful, and dynamic if you choose a company that values and understands the architecture of software design and the planning process.
While I have no problem trying out a small company product that purports to be "innovative" or "better" I wouldn't allow it to control mission-critical applications (such as estimating) that directly affect the livelihood of the company.
5. Work with a company that has a vision.
Some software companies have the opinion that once they've developed their software they need only to crank out the regularly scheduled new feature updates, but see no need to further enhance core development on the product. Let's face it, it's easier not to! But the reality is that companies who ignore advances in technology and choose to rest on their current success - rather than continually quest to improve their product - are destined to become outdated. In the software industry, it is the duty of a software company to be regularly seeking the next best way to improve their product, and that means never being completely satisfied with their current offering and always pushing the envelope!
Farid Saddik is the chief information officer at R&L Brosamer, Inc., a Northern California heavy/highway construction company. He has 22 years of global experience in the fields of engineering, estimating, project management, claim recovery, and information technology, and has authored and co-authored recent industry-related articles published in the California Constructor, and Construction Business Computing, including an article on software evaluation.
BID2WIN is Farid Saddik's estimating software of choice.
For more information, please contact Karen Finogle via phone at 603-427-0440, ext. 104, or e-mail at marketing@bid2win.com
