Don’t Go Chasing Waterfalls

Let’s assume that you’re going to build an XML-based publishing system. You’ve gathered requirements from the various stakeholders, have a design in mind, and have vendors or your own people lined up to make it happen. You’re good to go. You still have to decide one key thing: how will this system be built?

We really didn’t think about this. We came up with a fairly standard method to manage our project. Requirements gathered. Check. Systems designed. Check. Programming implemented. Check. System tested. Check. Boom. Done.

Sounds fine, right? You need to do certain things in a certain order to accomplish anything. But then reality hits. What if the requirements aren’t captured completely? What if the design doesn’t deliver what was expected? What if, and this is completely hypothetical because it never happens in the real world, something changes during the course of the project?

We weren’t consciously aware of it, but we had adopted the waterfall method of project management. The whole project with all its moving parts is considered at once. Everything is developed at the same time. When one stage is finished, that’s it, because it’s very detrimental to the schedule and budget to revisit past decisions and do rework.

Why is this a problem? Because this programming methodology was developed when guys in white shirts and skinny ties were doing projects on room-size computers that only the richest kings of Europe could afford. You had to have everything planned and ready to go because your computer time was Thursday from 4-5:30. These people did amazing things of course. You try launching rockets to the moon using only punch cards and slide rules.

Of course today, in the impossibly futuristic year of 2009, computers are somewhat more available. There are computers in greeting cards that play stupid songs when you open them. Then you throw them out. My washing machine has more computing power than that room-size thing from 50 years ago.

So why would we use such an outdated project management methodology? I don’t know. Seriously, who thinks about stuff like this when you’re trying to build a hugely complex new thingie on time and within budget? Well, add it to the list of things to talk about while planning a project.

It became clear during development that our methodology was hurting, rather than helping us. The core reality of our existence was, all together now, WE DON’T KNOW WHAT WE’RE DOING. All the requirements and design done before implementation were based on our assumptions and the prior experience of our vendors. Speculation, really. An image of the future that we thought made sense at the time. Something like this.

Then the thing gets built and the testing starts, and we realize we’ve made horrible mistakes. Gross miscalculations. Silly omissions. And, by the by, the market has changed a bit during all that planning so some of the stuff we planned for and built was no longer needed, and new things that were now needed weren’t included because, um, they didn’t exist during the planning phase.

Inflexibility is the downfall of the waterfall. It’s just too costly to redo the thing once it gets started. Rather than rethinking and reworking major missteps, we were forced to make slight modifications to what we had, which resulted in inadequate solutions and workarounds. Spending all that time and cash, and ending up with something that doesn’t quite do everything it needs to do is beyond disappointing.

Next week we’ll look at another methodology that may help solve some of these problems.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: