Measurement and the fine art of bidding

Even after 25 years in the IT business (much less other stuff), I find that one of the hardest things to do accurately is bid a sizable time and materials-based project.

If you’re in IT, you know all the reasons.

Stuff changes. Requirements aren’t necessarily what they really are. Features get added, removed, changed and re-added.

It can be troubling if you live by (or try to live by) a schedule.

As long as the communication channels are open, it works out. It works out because over the years, you’re zig zagging across the good bid/ouch line with smaller and smaller zigs and zags each time (mostly).

But I deal in atoms not pixels!

Yeah, that’s another reference to Free. I’ll stop with that eventually.

I wonder how big construction, architecture or engineering firms can afford to do that zig/zag thing.

Pixels are cheap. Atoms are not, especially when you’re talking about a project like a mall, a bridge or 23.3 miles of Interstate highway. Which brings us to yesterday’s measurement discussion.

I was talking to a guy in the construction biz a while ago and asked him about this. Based on all the bidding processes for huge municipal (etc) construction projects, are any of them right? It seems like they all go over budget and over time.

Can you imagine what the expense of being wrong is if you’re the construction, engineering or architecture firm?

Parts is parts

And then I was thinking… buildings, roads and bridges break down into finite tasks just like programs do.

The theory is that you can assess the time/complexity/cost of a project simply by counting the function points it contains. Rumor has it that it works if used properly. Guess how many businesses I’ve encountered using it over the last 25 years.

Doughnut. Zippo. None.

Why? Because it’s hard work. For small clients, it may not be worth the effort. Add to that, it means you have to properly plan and spec the work in pretty good detail. Not a lot of people want to put that effort in before handing a job to a programming staff to complete it.

On the other hand, not even Electronic Data Systems used it when I was there back in the Ross Perot days and we checked, rechecked and re-tested *everything*. Twice. Three times after 5pm.

I beam with joy

Let’s get back to the architects and such.

As I noted, buildings, bridges etc break down into components like beams, walls, pillars, etc. (Now you see why I just had to talk about function points, sorta.)

Like programmers (perhaps more so), these folks deal with complex bids with lots of variables.

They bid a bridge job because they have the best bridge designer in the state. Or condo. Or stadium. Whatever.

3 days before the bids are opened and awarded, she gets hit by a bus. Or gets a 3x salary offer from some Middle East engineering firm. Or disappears to find herself by walking the Great Wall.

Regardless of the reason, she’s gone.

It isn’t unusual, but it sure will throw your design time estimate a wicked curve ball and any technically-oriented business might see this.

What if?

What if your design software had the ability to measure how long it took to design an I-beam that will hold a dynamic load (ie: a load that changes/moves). Or how long it takes to design a retention pond at a factory.

So what, right?

OK…Imagine that your design software has the ability to do that for each staffer, broken down for each possible component of a building, screened-in patio, bridge, truss, lake, or other feature.

Like function points in software, the design software might keep track of all this based on complexity – such as by the number of load points and force vectors, or maybe square footage and materials have an impact.

Maybe experience and type of training comes into play. Maybe you learn that the designer’s college choice impacts these numbers.

Speed, Quality, Complexity

Now, imagine that this software can aggregate all this data by employee, by component.

With a little extra effort, you eventually figure out which designers are the best at designing each type of component.

A combination of speed, quality and work complexity ends up telling you exactly who to allocate to a particular piece of design and most likely that comes along with a very accurate estimate of the time needed to do the job.

If you break down the design of the most complex project you ever had, you know how many I-beams, trusses, concrete walls, pillars and so forth there are, as well as what kind of loads they have.

And now – because you have measurements of what the real work takes – you can make a bid that is far more accurate than the guesses those other folks are making.

Now imagine that you make the software that allows for this kind of measurement.

Your customers are the ones who bid more accurately. They win more bids. They become more successful. Your software becomes their secret weapon. You know what that means.

Imagine soft puffy clouds

Now… consider this discussion in the context of the service you provide, from programming to sports writing to graphic arts to small engine repair to architecture to plumbing or whatever.

You may already do some of this assessment by the seat of your pants / gut feel. Is it accurate? Be honest with yourself, it doesn’t matter what you tell me.

But would it be as accurate as an ongoing set of measurement data that is based on your current staff mix? I doubt it.

Would it help? Let’s see.

Imagine how much easier it would be to manage a project if you knew exactly what each component required time-wise.

Imagine how much easier it would be to manage a project if you knew exactly how to allocate your people to different details of the project.

Imagine what your sales staff would face out in the field when they realize they can confidently bid a job and know it’ll come in on time and on budget and they can whip out performance reports to prove it.

Imagine how your testimonials would change and the impact that would have on prospects.

Imagine how your customer retention numbers would improve.

Imagine what something like this could do for your staff’s morale. Never a late project, ever again. Well, maybe almost never.