Estimating Categories & Comparisons (Mar 8)

Any estimating software needs to divide projects into smaller pieces. It helps mathematically: if you split the estimate into many smaller calculations, the errors will usually cancel out. It also helps prevent errors: when we did construction estimates by hand, it was very easy to forget a few things. Categorizing also specifies the project in detail: clients know exactly what they are getting, and the building crew know what they’re building. As a bonus, a good category system integrates estimates with accounting software, so you can compare ‘estimated vs actual’ costs in a useful way.

Most construction projects can be sliced in at least two different ways. You can divide by categories of work: foundations, framing, roofing, trim and so on. Or you can divide physically by rooms, units, buildings, stories or whatever. There probably are other ways to slice up a construction project, but those are the most common.

For our own programming projects, it has been a challenge finding ways to categorize the work, for both estimating and job costing.

When we first started to program Goldenseal in the mid-1990s, project management consisted of a print-out of all the menus, with ‘completion bars’ drawn in atop each command. It was a nice, tangible way to see progress, but it also made the work seem like it was moving faster than it was. About 80% of the commands were easy, and each took only a few hours to complete. Some commands like Estimates and Print Forms took months. A couple (Write Payroll and Custom Layouts) took almost a year each. The chart looked like 90% done, when it was more like 50%. I guess that’s proof of the 90/90 rule. You can make the same mistake on a room-by-room construction estimate, if you count the kitchen and bath the same as other rooms.

A few years ago, we listed the Goldenseal Pro update on eLance, UpWork and guru.com. Over 100 subcontractors gave price quotes. Most just guessed or tried to talk us into T&M, but some sent detailed bids. Since we are still exploring the best category system for our own projects, it was interesting to dig them up and see how other programmers divided the work.

Several had a few broad, chronological phases. For example, one had 25% (prepaid) for ‘team selection’, 25% for ‘evaluate code’, 25% for ‘alpha version’ and 25% for ‘bug fixes’.  Basically, they wanted half prepaid before even starting. A few counted windows or menu commands, similar to our first method. The rest sliced the project into 10 to 25 categories, similar to our approach last year.

Looking at other people’s cost estimates is also useful. It’s similar to ‘comparison estimating’, where you start with a similar project and then calculate the differences. It’s a good approach if you know the total cost of past jobs, but don’t have enough detailed job cost data to calculate unit costs.

About 2/3 of the bidders planned to use QT, a popular library that builds code for both Mac and Windows.  Those estimates ranged from 40 to 150 programmer-days, or from $7,000 to $60,000 in cost.

We hired one of those in early 2015. The project started well, but ground to a halt after a few months. Then we discovered the contractor had used many shortcuts to get to the first draw payment, and we probably shouldn’t have paid for that. At least we learned that QT was the wrong tool for the job. The code was just too ugly.

About 1/3 of the bidders planned to convert Goldenseal the way we are doing it now: on the Mac, from Carbon to Cocoa; on Windows, from QuickTime to MFC; on both platforms, from 32-bit to 64-bit. Very few of those were willing to give a firm price, and none gave a detailed breakdown.  We hired two contractors who gave up almost immediately, and one who worked part-time for a few months before “getting stuck”. At that point, our staff had finished the back-end work, so we just started the interface code in-house.

Looking back through the list of bids, it’s clear that almost nobody understood how difficult the work would be. At the time, we assumed that tons of other software apps would already have made a similar conversion: meaning that there would be scads of subcontractors experienced at it. Reality is, those 64-bit updates never happened. Most business apps are still 32-bit, up to and including the big boys like QuickBooks and Sage.

Meanwhile, work proceeds on tables. Our estimate says they’ll take 2 months, but we aren’t far enough along yet to know how accurate that is.

Dennis Kolva
Programming Director
TurtleSoft.com

Author: Dennis Kolva

Programming Director for Turtle Creek Software. Design & planning of accounting and estimating software.