Project Management When You Don't Know What You're Building

Next time you’re flying somewhere in the US, consider this: the air traffic controllers that are guiding your plane are using technology originally developed in the 1960’s and 1970’s called ARTS to make sure you don’t crash into another plane. They started working on a new system called AAS in 1983, canned it in 1994, and resurrected part of it in 1996. Now we’re already in 2006, and they’re saying Phase I deployment won’t be done for another year.

I won’t bore you with what happened, because your tax dollars produced a nice report from the House of Representatives that goes into enough detail to put you to sleep. But the FAA, and subcontractor IBM, faced a problem that isn’t all that uncommon in software development: they were trying to build something and they didn’t know what it was.

It’s a problem frequently faced by startups. You’ve got six customers, two of whom want to do something that you never dreamed your product would do. But they are paying you money. Maybe even A LOT of money. You need money to make things like the weekend company ski trip happen. Also things like payroll. So what now?

What you need is a good strategy for managing the changes, letting them happen but keeping your product plan on track.

So what is that? Here’s what’s worked well for me:

• Define short release cycles for your product. The “we’ll-wait-five-years-between-releases” model of a certain Redmond software firm doesn’t work very well. If you’re a web startup, you might try the hyper-speed release schedule: every few weeks. LinkedIn, for example, spaces releases by two to four weeks! If you’ve got a more conventional model, or you can’t roll out your product to the world by typing cp dev/* live/, you might want to look at a 3-6 month cycle.
  
  No matter what you choose, it means your product has to go through the full cycle – requirements, design, development and testing – all in an extremely short period of time. Believe me, it cuts down on extraneous crap.

• If you’re releasing every two weeks, you run the danger of always being the rat on a wheel. Working really hard and not getting anywhere. To counter this, I usually like to write a vision document. Use KISS on this one.
  
  Need to know how to write it? Why, I’ve got a Software Vision Document Template.

• So what DO you do for the requirements, the testing plan, and the like? Monolithic ain’t gonna work. So do the same thing: do really lightweight versions, and keep it simple. Nobody reads these anyway, especially not in a startup. So if you put too much in there, it its just about the same as not having one at all. You might consider doing some of these visually – a PowerPoint or screen mockups or a Visio doc. It doesn’t all have to be written.

That’s it. There is no number four. I specifically don’t advocate adding a lot of layers to the management of the software project: don’t do change documents, risk analyses, and all those other things that ‘good’ software development requires. You’ll waste time thinking about them.

The key here is to have documentation, and have plans, but keep everything really lightweight. That way, if the guano hits the fan, you can react quickly.

As for the FAA? The good news is that they seemed to have learned some lessons. They’ve been deploying measurable technology upgrades for the last several years, such as the new ARTS Standalone Tower Display System, which first came online in 2003 and helps smaller towers control their airspace. Of course, not everything at the FAA is up-to-date: this 2003 system uses Windows NT 4.0 running on a 366MHz PC with a 9.2GB hard drive. But you take what you can get, right?