As someone on the fringes of software development (by which I mean most of the projects I’ve worked on over the past dozen years or so would be considered trivial in programming complexity by developers outside the multimedia community) I don’t do a lot of reading in programming theory, design, or management. Once in a while, though, I’ll dip my toe into the water and read an article that’s not specific to one of the applications I use. One that came through from the Gamelan Java Update e-newsletter today was particularly interesting, both professionally and — amazingly enough — in a political context.
The lead article in the latest GJU is an excerpt from a book on software project management by E. M. Bennatan. Bennetan was a senior director at Motorola and a vp of engineering at Midway Corporation. His book — published last spring — is titled Catastrophe Disentanglement: Getting Software Projects Back on Track.
The chapter discusses what exactly constitutes a “catastrophe” in a development project. He relates the case of a company that attempted to capitalize on a project written in the COBOL language in the post-Y2K era — after older COBOL applications had been converted to more modern languages — only to have their experienced programmers reach retirement age or leave, leaving the company with a partially-updated project, not enough experienced programmers on board, and a shrinking pool of talent to draw from outside the company (does that sound familiar Lingo gurus?).
This case illustrates the difficulties decision makers have in accepting the need for drastic measures and is reminiscent of a gambler who cannot get up and walk away. First, there is the natural tendency to put off making the difficult decision in hope that conventional methods will eventually get the project back on track. A second difficulty involves over-commitment to previous decisions, prompting the investment of more resources to avoid admitting mistakes (this is known as escalation).
The whole article is well worth a read (as is a recent New Yorker piece by John Cassidy on neuroeconomics). It places its points in the realm of software development, but there’s nothing there that’s technical in nature. It could easily be applied to many other types of projects.
Near the end of the excerpt, Bennatan states the steps needed for the catastrophe disentanglement process:
- Stop.
- Assign an evaluator.
- Evaluate project status.
- Evaluate the team.
- Define minimum goals.
- Determine whether minimum goals can be achieved.
- Rebuild the team.
- Perform risk analysis.
- Revise the plan.
- Install an early warning system.
The ten steps should be completed in sequence, and the entire process should take no more than two weeks to complete.
I can think of a couple of people this book would be worth sending to. If only they actually read books.