It seems that the bookshelves are inundated with books about building successful systems. “Build a successful business in 2 weeks or less”, or “How to go on the Web in 30 days”.
To me, the real key to building successful systems, Web-based or not, is to understand the underlying causes of what makes a system fail. So, I decided to write my own set of articles entitled “Why Systems Fail”, beginning with this — The Slinky Style of Project Management.
The What Style of Project Management?
You know what Slinkies are. They’re metal or plastic springs that can be pulled apart and spring back together. You can buy a slinky in its pure form, or as part of another toy. For instance, you might have seen them as the body of the Slinky Dog™ in Disney’s popular movies Toy Story and Toy Story 2.
I have a slinky at my desk, and whenever I get stumped on a technical problem, or I’m trying to figure out how to word a paragraph, I grab my slinky and move it back and forth between my hands. Back and forth, back and forth — really quite soothing. Okay, yeah, a bit mindless too, but that’s okay sometimes.
However, the fame of a slinky is its ability to “walk” downstairs. Put a slinky at the top of the stairs, tip the toy over the stair by its top and watch it go — the thing won’t stop; moving head over tail, overhead, over tail, until it hits some obstruction along the way, falls off the stairs, or hits the bottom.
The thing about a slinky is that the toy has momentum generated by the action of the spring and the force of gravity, and this momentum doesn’t cease until something blocks the action of the springs or the slinky is no longer falling.
Project Management can take on a strong resemblance to the slinky, particularly with system projects that are based on the Web. The real key characteristic of the Slinky type of project management is to continuously move, building on the previous momentum, and whatever you do, no matter what, don’t stop.
Doing design specifications and getting buy off from the clients means stopping — can’t do that. So is documenting the system as its being built, or using documentation in the code, or diagramming the application or the database supporting the application. All of these mean that you will be spending time Not Delivering Content — and not delivering content is evil, it means you’re stopping. So you just keep on putting content out, and putting more content out, and more and more. Just like the toy on the stairs, you hope that the momentum of your effort keeps the project going and going and going.
However, with this kind of project, when you do stop (and you will, eventually), just like the slinky your system is going to sit there most likely fallen over on its side. Folks are going to be able to look, really look, at what you’re delivering: applications quickly delivered but not very robust, that are hard to maintain and difficult to modify; they might have security leaks and the database data might be a bit suspect.
Some poor soul or group of souls will be brought in to support the system and they’ll get all the late night calls with system failures, and the code re-writes, and they’ll probably not like the originators of the system very much especially when they’re going through the one thousandth line of code trying to figure out where the bad data is coming from.
Normally, folks don’t use the phrase “Slinky style of project management” when they refer to this style of systems development. No, usually they use terms such as Rapid Application Development (RAD), and Content Focusing, stuff like that. But you can still see the faint gleam of metal of the slinky underneath.
RAD does not mean any documentation, nor does it mean no design: it means starting small and building on the successful completion of each task BUT (big but here), you still deliver specs, and you still deliver docs, and you still make sure appropriate T’s are crossed, and I’s are dotted. RAD is not a shortcut for doing things Right.
In the Slinky project management style, there are no system design documents, there are no system implementation documents, there isn’t an overall plan, there are no standards, source code control is a bit of a laugh, and there is no documentation of the database —
But hey, the ride was sure fun, wasn’t it? Just don’t stop, just don’t ever stop…
