Power tool safety for estimators Part 1 : Software hazards

There are no shortage of software “solutions” for construction estimating.  It seems like every one is advertised to deliver greater accuracy with less effort so one estimator can do more.  Experience has taught me to be pay attention to the problems these software systems are claiming to solve.  I’ve worked with several of the most popular estimating programs and all of them exhibited basic problems that can really mess up a bid.  Speed and ease are selling points for systems that are very difficult to override when they screw up.   If we think of these programs as the “power tools” of estimating, we can easily see the need for “safety training”.

There is no more important estimating safety tool, than to wear your reading glasses…

Looking at a floor plan, it might be fairly obvious that the flooring is 60% carpet and 40%  vinyl tile.  When the quantity measurements are entered into the Construction Specifications Institute (CSI) format , it’s difficult to see the carpet quantity relative to the vinyl flooring because they’re often separated by hundreds of lines in the final estimate.  Many Quantity Take Off (QTO) programs will convert to  square yards when measuring carpet versus square footage for vinyl flooring.  This means that the numeric difference between two installations that are commonly installed in the same areas, will appear nine times less significant than they really are.

Research on perspective enhancement is ongoing…

Take the 60-40% split mentioned above with 1,000 square foot total.  1000 * .6 equals 600 square feet.  Divide 600 by 9 to convert to square yards and you get 66.66 SY.  Compare that to the vinyl at 1000 * .4 and you’ve got 400 square feet.  If you are quickly scanning the output numbers looking for obvious errors, 66 looks a whole lot smaller than 400.  Depending on the software’s report settings, the units of measure might not appear immediately alongside the measured quantity you’re checking.  Trying to check quantities and units in the software can be very tricky when the software doesn’t allow the user to highlight or increase the contrast of a particular line.  That’s a serious downside to software designed with a minimalist aesthetic.  This is why some  estimators prefer to check their work with a printout and a straight edge.

Caution, powerful settings buried below

While I’m on the topic of minimalist aesthetics in software, there are a few other issues that bear mentioning.  Program-specific terminology can be a major stumbling block.  One industry-leading QTO program conceals its ability to multiply repetitive takeoffs like hotel rooms in a multi-story building behind a two item drop-down list.  Neither item on that list alludes to this functionality.  Making things even more difficult, the relationship between floors and rooms are defined by a matrix where the rows are defined through completely different menus than those to define the columns.

The matrix menu allows changes to the rows, but not the columns.  This means that an estimator who’s discovered an error in the columns of the matrix, must close out the screen showing the matrix and return through a completely different set of menu options to fix it.  The window displaying the matrix is limited in size and is only open while a menu is active which means that an apartment building with ten or more unit types cannot display all the rooms and all the floors in a single screen.  This makes error checking much more difficult than it needs to be.  Answering simple questions like “how many apartments are in the estimate?” is profoundly difficult because the program’s design isn’t effective.

QTO programs are often bristling with options to adjust the scale, alignment (level), image rotation, image contrast, etc.  Rarely are these options identified with meaningful terminology, nor are they located to minimize the mouse movement required to operate the program.  Terms like invert, flip, and rotate are scuttled in preference to diminutive arrow icons that all look the same.

I’ve worked with a market leading QTO program that won’t allow a to scale setting change after any substantial amount of takeoffs have been done.  If you discover that the scale is wrong on a page, you have to delete all the takeoffs before you can correct the problem.  Always check that the labeled scale is correct by measuring a known feature.  Be sure to check vertical and horizontal measurements.  More than once I’ve encountered .pdf format drawings with an aspect ratio problem.  Most QTO programs cannot accommodate a separate scale for horizontal  and vertical.

Even relatively innocuous changes can be harder than necessary.  Some programs require multi page menu navigation to achieve what other programs do with a single drop-down list.  All of them get slower in proportion to the total file size of the job.  This leads to an infuriating situation where the program reduces workflow to a crawl right when the estimator has the least amount of time to wait.  The critical lesson here is to confirm that your settings are right early on.

Warning! This machine has no reverse!

Some estimating programs are only capable of importing QTO measurements that add to a takeoff smoothly.  Any sort of deduction, or change of breakout to imported quantities may require a manual import for each individual measurement.  For many estimating systems, the manual overriding triggers an overall update to the estimate which can take several minutes on a large estimate.  If that wasn’t bad enough, it’s not possible to group import several negative measurements.

To the user, this means scrolling through thousands of lines of small print text looking for items that don’t have a small check mark in the “imported” column.  There’s no “search” or “sort” functions to cull the data, nor are there any means to adjust the diminutive single-spaced fonts.  These programs are like a drag race car.  Everything is optimized for moving in only one direction.  If you need to back up, you have to get out and push!  For an estimator with an error in their QTO and a deadline rapidly approaching,  they may need to make some hard decisions.

I recommend using a proposal template that is completely separate from the estimating or QTO program.  A simple spreadsheet or word-processing program will allow the estimator to enter what’s actually needed when time is short.  If/when a situation arises where there is an error in the estimate without sufficient time to  fix it, the totals can be manually adjusted on the proposal template.  I’ve known several contractors who missed a deadline because they couldn’t generate a proposal without fixing a simple subtraction problem with their intractable estimating program.

Repetitive Stress Injuries

Some QTO programs will attribute each assembly takeoff to the plan page of the drawing set.  This gives the estimator a way to determine where the quantities are coming from.  Other QTO programs will allow for repetitive applications like hotels or apartment buildings.  Each “Unit type” can be taken off one time, then their resulting QTO can be attributed to however many repetitions the design requires.  The time savings can be profound, however estimators should be very cautious lest a mistake be multiplied throughout their estimate!

One particularly tricky aspect of this practice pertains to rooms that only appear to be symmetrical.  For example, consider a hotel with L shaped rooms running along a hallway oriented North to South.  The “L” shape intersects between pairs of adjacent rooms so that the “L” is upside down on alternating rooms.

Now for sake of example, let’s say they are all the same room dimensions.  The room finish schedule defines the walls by cardinal directions (North, South, East, and West).   Let’s say that the finish schedule defines the West wall finish as wallcovering (a.k.a. Wall paper).  It’s tempting to simply choose a unit, and measure the West wall to define the wallcovering takeoff for all the rooms.

The problem here, is that the rooms with a long axis on the West wall will have more wallcovering than the rooms with a short axis on the West wall.  Depending on the overall design, and the discipline of the Architect, the odd room numbers may correspond to one condition, with the even-numbered rooms corresponding to the other.   Estimators must  verify for themselves because they are responsible for knowing what is actually required.  Be very careful about getting these measurements correct because even small errors get compounded in repetitive takeoffs.

Transfer traffic safety

Every QTO and estimating program I’ve ever used allowed for user-customized parts/items in the estimate.  The “rules” for how these customized parts work within the larger estimate are similar to pre-defined parts with a couple of notable exceptions.  In most situations the QTO program and the Estimate program are “patched” together via an import/export relationship.  In theory, it’s possible to generate the custom part in either program.  If the part is generated in the estimating program, it needs to be exported to the QTO program to be used for measurements.  On the other hand, if the part is  generated in the QTO program, it needs to be imported into the estimating program.  Depending on the specific nuances of the programs and how the patch works, there will be one direction (import vs. export)  that works better than the other.  Generally, the provided training or tutorial videos accompanying the software bundle will present the direction that works the best.

“Sure, there’s a faster way to get where you’re going but I… wouldn’t recommend it”

Keep in mind that some exports need to happen with the receiving program closed, while others won’t reliably work unless the receiving program is open.  Training videos and software instructors often neglect to mention when the receiving program must be closed for reliable transfer.  It’s on the estimator to pay attention to whether they are opening verses maximizing the receiving program.

Savvy readers will have noticed that I emphasized reliable transfer.  I’ve used several program packages which appear to import and export without any particular issue or error message.   Yet when I check the received information against the sent information, I’ve found custom parts that were not fully transferred.  In my particular case, custom parts that are generated in the estimating program, then exported to the closed  QTO program, will work like any ordinary part for QTO, then will import properly into the open estimating program.  Any other combination leads to failures in about one-third of the cases.

It took me a long time to figure this out because the problem was intermittent.  Once when I was on a technical support call regarding another issue with the software, I mentioned my discovery to the technician.  The technician told me that was a known issue and pointed out that their training videos only depict that specific approach.  It was only after the call that I noticed that their video left out any sort of warning about doing things differently than they recommended.  There’s a lot of that sort of thing in estimating software.  If you’re using the program differently than they envisioned it, there’s no guarantee that it will behave as advertised.

Pop up windows, the Big Red Button of estimating software

Manual overrides are any kind of user-input that interrupts, or changes something during an automatic function.  An estimating program might be configured to provide a pop up window for the user to adjust a variable, or to confirm that a default is acceptable.  Very often, a user-generated custom part will trigger a pop up window during the import.  Every pop up halts the import until it is answered.

In use, the estimator has completed the QTO and has imported all the measurements into the import stack of the estimating program.  The whole import stack is selected and “import all” is initiated.  At this point the program will import the data serially which may take some time if the estimate involves a lot of measurements.  As soon as a custom part is encountered, the pop up window interrupts the import.  Nine times out of ten, the estimator only needs to press the “enter” button to accept the value and continue the import.

This means that the estimator is looking at a twitching display of all the data being imported waiting for a pop up to tap the “enter” button again.  If there are a lot of custom parts, this can mean tapping the “enter” button every few seconds as the program makes its way down the import stack.  Since this is one of the final steps of an estimate and time is always short, the estimator might get anxious for these interruptions to be over.  Woe betide any estimator who taps “enter” before the pop up screen appears!  Inexplicably, this automatically excludes the next part requiring authorization from importation.  There won’t be any error message or notification that this happened.  The program will bury that custom part next to something  in the imported stack and leave it for the user to find.

Similarly, any other manual override pop-up that is “answered” prematurely will generate unpredictable yet consistently counter-productive results.  It behooves the estimator to be patient with these lumbering pop-ups.  A word of caution, if you decide to work on something else while the import is running, be sure to minimize the estimating program entirely to keep it from responding to the “enter” button.  Just be sure to check back periodically to see if there’s another pop up holding up the import.

 Safety net, or hidden snare?  Don’t let dopey defaults do you in

Trade-level estimating programs often feature default functions meant to avoid common mistakes.  For example, an electrical estimating program might trigger an error message if an estimator tries to put an oversized wire into an undersized conduit (protective pipe for wire).  Since these relationships are based on uniform standards like building codes, the defaults here are able to catch a lot of mistakes.  The savvy reader might have noticed that the default “saved” the estimator from mistakenly overfilling a conduit which ranges from a safety hazard to a physical impossibility depending on the degree of the mistake.

Now consider the relationship in reverse.  If the conduit is oversized for the wires within, there is no safety issue.  Since larger conduit is more expensive, it’s important to use the correct size for the application to keep the pricing competitive.

The “safety net” of the defaults only protects against underbidding the job in very specific situations.  Efforts to guide estimators to “just right” assemblies generally revolve around incredibly long lists of every possible permutation.  This is a terribly inefficient approach because the programs lack the intelligence to make reasonable suggestions for what is needed. Forcing an estimator to select one item from a list of one thousand means 99.9% of what’s presented is wrong!  These default lists are tightly packed error inducing machines.

Automatic update, friend or foe?

Another aspect of defaults that can play havoc pertains to “quoted” goods versus commodity pricing.  Trade-level estimating software often features commodity pricing which is updated periodically according to national, and local average databases.  Several trades involve thousands of different parts available in dozens of sizes which means that the complete list for commodities can have 100,000+ items.  Even a modest commercial project can require a thousand or more unique parts.  If all the contractors  requested distributor quotes for every line item on every one of their estimates, the distributors would be overwhelmed and gridlock would be inevitable

Commodity tracking systems are an invaluable aid to trade-level estimators because they automatically adjust the pricing of hundreds of thousands of parts to reflect current market conditions.  Errors can and do happen so it’s important to scan the estimate for anything that stands out.  One very embedded error that occasionally pops up is in the unit of measure for a commodity price.  Some parts are priced per each, others are priced per the hundred count, and still others are per the thousand count.  Commodity price updates might have the correct commodity price with the wrong unit of measure which can shift the commodity cost in your estimate by three orders of magnitude!  I’ve encountered situations where a single unit of measure error in the commodity pricing update added several million dollars to my estimate!

Continued in next article:  Power tool safety for estimators Part 2 : Safety in the estimators shop

For more articles like this click here

© Anton Takken 2017 all rights reserved