Author
Rating
Published
Thursday December 29th 2011 11am
Maybe it is like building houses
Software
Test and QA
Development
Editorial
Process
Strategy
Teams
Testing
A few years ago, I overheard part of a conversation between an academic department on how to teach project management at the graduate level.
One professor thought that project management for IT projects is "just like building houses" -- you break down the work into very small chunks, add the chunks up, make a plan, and manage to conformance to plan. The second thought it was more ... nuanced than that.
The argument split the department so much that the department chair ended up appointing a third person to teach the slot - one of the few people in the department with a couple of decades of relevant experience. The thing was, this guy only had a mere master's degree. Oh, what a big deal that was; people went to the regulations for accreditation to prove that teaching at the graduate level requires a PhD.
Except, of course, it doesn't.
Which brings us to today's question: Is Project Management for software the same as it is for building a house?
Here's the thing about that analogy: I suspect the person who was pontificating not only knew very little about software development, but probably didn't know much about building houses, either!
I will explain
Of Averages and Large Numbers
Some builders can make predictions and targets for buildings and actually meet them. The way to do this to develop a series of housing complexes, each about the same size, perhaps 80 to 120 acres, and with, say, six to ten different home designs.
You've probably seen some of these -- cookie-cutter developments with names like "Whispering Pines", "Shady Acres", or "The Back Forrest" -- the kind of places that, ironically, have no pines, no shade, and not forrest.
It turns out that if you build the same ten houses over and over again, cookie-cutter style, in the same area, built out of the same material, over time, you can get pretty predictable about cost.
That's good, but, I am afraid, software development, that ain't.
If we have an existing piece of software to use, cookie-cutter style, why, that's an integration project, not software development. Copy some files, run the installer, customize the UI and we're done.
The actual building part is custom work, and, like building a house, it's extremely hard to predict costs and schedule.
When you think about, though, most software projects don't start from scratch. They are maintenance projects -- more like remodeling than building.
And that's the rub.
This Old House
I have an old house; at least, building in 1871, it's relatively old for the midwest.
That means the house pre-dates electricity. It predates the common use of running water inside the house. Why, a few years ago, a couple of amateur archeologists dug to find the old outhouse. It turn out, that's what people used to use as a trash bin, so they found a nice pile of old medicine bottles and broken china.
In other words, new, modern technologies exist to make life easier, but retrofitting them into the old house is painful.
In 2002, we put in a new bathroom upstairs. Half-way through the project, the contractor approached me about the tub. He was worried that it was too heavy and wanted to put a closet in to support the tub on the next floor, for an extra $500. I reluctantly agreed.
That project was a mess. We signed the contract in September or so, and he thought there would be "no good reason" to not have everything done for a family visit late in October.
It wasn't done until after January. Oh, and thanks to change orders, the project was probably 30% over budget.
Then I look at my closet. It doesn't extend to the ceiling - instead, it sits perhaps a sixteenth of an inch below the ceiling tiles. What was it there for?
Then you look in the closet, and notice the false back. From what I can tell, the contractor cut a hole in the floor and the ceiling to run the water pipes and electrical power through, then built the closet to hide the pipes and wires.
Yeah.
But we have the same problems in technology projects; we really, really do. We want to use some whiz-bang fancy tool or component, then have to figure out the screen-scaper, spider, SOA Wrapper, or some other trick to make the new technology work with the legacy system. It's classic.
Last month I had a run of my basement torn out - the chicago brick was decaying - and had it replaced with concrete block. While they were at it, we asked the contractor to restore the grade around the house. That is, to put dirt down so that the grass sloped away from the house, so rain-water would go away from the house, to keep the water pressure off the basement. (No, I can't get gutters, at least not easily, it's a historic home. So the water drops off the house in sheets and erodes the land, causing a negative grade.)
I also asked him to put on a new basement door and paint it.
Let's see what went wrong:
The contractors told me it could get started in "a few weeks", starting in September, and, once started, would be done in "two weeks."
We eventually signed a contract Sept 23rd.
Work started after Thanksgiving, Late in November. It 'finished' on Dec 8th.
Let's talk about what finished means.
* There is a small gap between the new basement and the bottom of the house. The weight is supported, but the wood is 130 years old and uneven. This gap is just big enough to let a little air in ... or, say, a mouse.
* We have a wheelchair ramp; it is higher than it used to be. It is also a few inches off. To fix this, the contractor put in filler wood, which is now exposed. He has offered to put in new carpeting to over this ... at our expense.
* The dirt filler was pulled from the excavation and brick tear-out. It is full of brick pieces and more than a few pieces of glass. After a few rain falls, the filler has noticeable erosion around the water-line - a trough. The contractor has offered to put rolled grass down in the spring, at our expense. This should help prevent further erosion. He has also offered to try to get some of the bricks and glass out, at his expense.
* The basement door is replaced, but it's not painted. It is too cold for that; that will have to wait for spring.
* There is sand all over the front area. The contractor tell us that the grass will grow through the sand in the spring; if it does not, he will seed the ground for us, at his expense.
... I could go on.
What you see here is a bunch of problems, all of them which will delay the project, most of which the contractor will fix (later) (for a price), some of which he will fix (later), at his expense.
The contractor wants to get paid now. After all, the work is done, right?
Does Any of This Sound Familiar?
My goal here wasn't to complain about the contractor or get some sympathy because "woe is me." Nor is it to seek advice; the contractor and I have worked out our differences amicably.
Instead, I would like to make a few points.
The issues above are not unique to this contractor; I have had them with nearly every organization I've worked with of more than three people, where the folks who will do the work are different than the estimator or the work is unique. I do have a wonderful experience with some roofers a few years back, who could estimate the roof in square feet -- a somewhat stable, predictable, repeatable job.
For everybody else, the first project is getting the work scheduled, which is a portfolio management project remarkably easier for a ten-person contracting firm than for the typical software project. And yet even organizing those ten guys is a challenge.
Then you've got to sync up on expectations. What I wanted was my ramp back in the same place, looking the same as it started, and if you couldn't do that, talk to me before you do anything.
To the contractor, this seemed like a completely foreign idea. And I believe him. To him, it was foreign. It was not what he expected, even in good faith. He really believed it, or, at least, he really thought his changes were "good enough" or "no big deal." (Have you ever heard a programmer say that?)
Finally, there are quality issues. I mean, the dirt was going to erode in a few weeks and it had glass in it, yet the contractor wanted a check.
This is what software is like without QA, right?
In other words, maybe software development is like a house. It just turns out that building or remodeling a custom home is freakishly hard.
Back in 2002, when we put the bathroom in, I had one contractor tell me he charged $25/hour plus 20% markup on materials. He said he would not give us an estimate, but he would be on-site forty hours a week and we could see him working hard, and if we didn't see progress, we could fire him.
At the time, I thought the comparison to Extreme Programming, or Agile Methods, was striking.
Today I'm sad that I didn't hire the guy.
The Final Secret
A relative of ours just bought a big house in a beautiful suburb of a large metro area. As I was thinking about his house in regards to this article, it got me to thinking.
I mean, the original contractor build that house for the original owner probably at some sort of fixed-big situation. There's no way the original owner went with $25/hour per person and we'll fire you if it's not working out. How did the contractor possibly do it?
Sure, they were probably late, but that would still eat into the builder's profits, right?
Here's what I think ma have happened.
First, the house was comparable, in square feet, to a lot of other houses around. The contractor knew the general amount it would cost to build (say $100K) and the general length of time it would take to build, say six months.
The contractor then sells the house for $500K and nine months and takes some risk. Heck, even if the project is 100% over-budget, it's still a $300K profit, right?
That's the final secret: We should be running software projects that are successes even if the are late, even if they are over-budget. Giving ourselves a 10% margin for error and a great big penalty when we are late isn't an execution problem, it's a management problem.
Tom Demarco and Timothy Lister describe something they call "The Dead Fish Project" in their book Adrenaline Junkies and Template Zombies. They define the dead fish project as the sort that is dead before you've even got started -- the schedule is too aggressive, the risks too high, the payoff, even if you made it, too low.
If software development is actually like building an actual house, we shouldn't just be asking for projects with a potential 400% profit, where, if they are late, our profit is only 200%.
We should be demanding them.