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.

Friday, October 26, 2007


For this inaugural post I thought it appropriate to state what I hope to achieve here.

Whether you have been at the helm of project management or directing technology efforts, have been at the "receiving end" of such, or perhaps you are a technician caught in the middle, you know the effort and frustration that can accompany software development.

I have been in all of these places. I've been part of failures and successes, fun companies and miserable, profitable and not so much. I have worked with highly skilled people and with those who should not be responsible for managing a lemonade stand.

What I have learned is what we all do: people (at least the ones you want on your team) like to be part of successes and to feel as though they have achieved something with their time. Your definition of success may differ from mine, but you know when you've had one. It usually involves staying within schedule, and budget, and delivering quality. Some fun along the way and a bonus is even better!

So, this blog will attempt to deliver some practical advice and stir your thoughts towards more success in software project management -- whether you are a director, a project manager, a developer, or a user.