Monday, October 29, 2007

When Is Software Like A Fence?

When is a software project like a fence?

Building a fence a time or two gives one a sense for how much time a fencing project will take. Removing the old fencing, old posts (and concrete), and cleaning up the work area for the new fence are all part of the project. (And so is hauling it away, but somehow I've failed to negotiate that point with tradesmen a time or two!). Computing how much and what types of wood one needs, how much concrete, and how much time is needed for each fence section are relatively straight-forward.

Things that will affect a "linear" computation of cost and time will arise, such as terrain, difficulty removing concrete for the old posts, weather, permits, and so on. However, after doing a few fences one can become pretty accurate in estimating the cost and duration of a fence project.

A few things that really help this are: the fence is tangible; one can see the terrain; one pretty much knows what the owner wants; it is unlikely the fence requirements will change drastically half-way through.

But that is the art of software project management: reducing concepts and intangibles into "real" things that can be visualized, estimated, and built. Seeing the unforeseen. Letting the users know that changes to certain specifications are like tearing down a fence and starting over. That changing specs early on (before the concrete dries around the fence posts) are easier rather than doing them later. That changes are doable, but changes have two side effects: time and money.

Just as building a fence requires a progression of tasks (e.g., one cannot put up the fencing until the posts are in place and the concrete is dry), so does software development. Just as there is a point where adding people to a fencing project will have no positive effect, so it is with software teams. Just as one can look at the amount of fence standing and conclude what percentage of the project is done, so must a manager know how much of the project's tasks are complete so he knows where the project stands.

While a software project usually has many more complexities than a fence project, at times it is helpful to step back and try to see software projects from a more practical viewpoint and less as a morass of out of control details. A manager must be able to translate intangibles into tangibles.

1 comment:

Anonymous said...

Good similitude!

Some other common denominators -

a) Stakeholders: customers, bosses and team members could impact projects during crucial phases.
b) Risk management: projects are fraught with guesses, estimates, assumptions and hunches
c) Larger context like policies and politics: a software project could be halted due to company downsizing; a fencing project could be halted due to a government policy which stipulates all owners to use 100% virgin vinyl!