The construction analogy — estimation
What got me thinking about the construction analogy with software development was a recent conversation I had with a design/build contracting company. We’re in the market for a new house. We sketched our design (which we’ve worked on for quite some time) and wrote up a list of general assumptions about level of quality and some details that we wanted. We sent this out as a letter to a bunch of builders.
That sounds somewhat like your typical business requirements document, doesn’t it? It’s too detailed (specifying implementation details) while simultaneously failing to mention important points. But it’s a starting point for conversations.
A small number of builders responded to our Request For Proposal. The first one to come by and talk with us brought a very nice portfolio of photos of houses his company had built. He explained how his company ran projects and told us he could give us a fixed-price quote once the design was complete. Oh, and we would pay for the design effort by the hour.
This sounded a little waterfallish to me, but then he explained that, as the design progressed, we could make better and better estimates of the cost and that we could call a halt at any point. Ok, that’s a little better. I understand about refining the estimates. Of course, abandoning the project is really not acceptable to us. We still need a house, and we’re willing to make adjustments to get a house that we can (almost) afford.
The kicker came when I asked for a ball-park estimate. There are times when I’ve felt very uncomfortable giving an estimate on too-little data because people are wont to treat them as promises or commitments. Knowing this, I gave him assurances that we just needed a figure for planning purposes. After all, the bank wasn’t going to give us a blank check. Just an estimate to the nearest $50K dollars would do.
The response was disheartening. He couldn’t tell us whether our house, as described, was closer to a $200K house or a $400K house. It seemed to be a small thing to him. After all, we only had to pay their designers $85/hour for a “Preliminary Design/Feasibility Study [costing] up to a maximum of 3% of estimated project cost.” Ignoring the fact that the cost of the study was estimated as a percentage of the total cost that the study was estimating, this proposal was totally unacceptable to us. All we had been given for making a decision on whether or not to choose this builder was some glossy brochures and a talk about how wonderful they were.
Unfortunately, I fear that some software development teams approach estimation in much the same fashion. Perhaps this has engendered some of the much-discussed “agile backlash.”
While it is true that the more you work on the project, the better (if you approach it well) you can make your estimate. And while it is true that there’s an unfortunate human tendency (often magnified by an unequal power relationship) to hear an estimate and take it as a commitment. It is also true that the person (or company) commissioning the work needs some sort of estimate to make rational choices about how to proceed.
Ken Auer has a wonder description of using a simplified Planning Game to provide such a description in Extreme Programming Applied: Playing to Win (see pp. 112-114). This sidebar, alone, is almost worth the cost of the book.
For the 12 years or so I’ve been designing and building software and managing other people doing those thing too. Once upon a time I was a General Contractor (California License 575363, now expired 😉 and I think you are both right 🙂 and in 1987 I worked with Chris Alexander, a designer/builder whose name is probably familiar to many software designer/builders.
You *can* get an upfront estimate from a good, honest design/build firm, if you are successful in convincing the contractor that you really do think of it only as an estimate. Perhaps one of the best ways to do this is to examine several of the houses they have built and ask the price. Divide the price by the square footage and make notes about exceptional items (solar electric? swimming pool? difficult building site? etc.) This should get you a rough cost per square foot. Then the real difficultly is reminding yourself that it really is only an estimate, because you will of course, want to stick to that price 😉
Also, some suggestions:
– Examine the builders’ process – visit a job in progress. Talk to two prior clients.
– Try spending a couple hundred bucks and see what working with them is like. $200 and 3 hours should tell you a lot.
– Find out what homeowners’ insurance in your area estimates for rebuilding costs.
– Take deep breaths. I think if people knew what a construction project entailed maybe half of them would not do it. Do it as a couple – your relationship is more important than the color of the roof.
– See this as a chance to carry out everything you know about project management – it’s your project, your money.
Good luck!
Oh yeah – I forgot one of the best techniques, when you can use it: Come up with a budget first, and then design to meet that budget.
Thanks, Matisse.
I doubt we’ll be able to stay within our budget (which we’ve already increased based on estimates), but we can’t afford to go TOO much over.
We’re talking to past clients they’ve provided as references. Mainly we’re looking for a builder who will work expeditiously, and not let the project lag when new opportunites arise. We’re also looking for honesty and openness, not someone who’ll low-ball the estimate and make it up in change orders.
And, what we really want is one who can discuss the costs of features, and the relative costs of doing things two different ways. We want a cathedral ceiling in the living-dining room. What’s the cost for doing a stick-built (where the ceiling slope will match the roof slope) versus using scissors trusses (where they won’t)? Aesthetically we’d prefer the traditional, but not if the cost seems exhorbitant. It’s like the XP planning game, but the builders aren’t very familiar with that.
I’m sure the process will give me plenty of raw material for blogging.
Sounds like you are taking a reasonable approach. I guess because I think of myself as a Builder I want to remind you that the discussions you want to have are consulting services yo want to get from the builders and you’ll probably get better results if you let them know that you value their time and expertise – that doesn’t necessarily mean paying for the discussions, although it might.
I’m guessing that you have a list of these ‘stories’ and their alternates that you want to discuss, and I bet that helps – the builders can take the lists home and think about them if they are not comfortable talking it through in person – they may feel put on the spot.
Most clients of builders (who do not have an architect) do not have their desires organized in a way a builder can easily respond to, so I think you are ahead of the game.
Remember – Software is not a Building, but the *process* of making software *is* like the *process* of making a Building, so you know a lot already.