IT Management Must-Read Books: Death MarchBy Bruce F. Webster | Posted 2008-11-17 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Post-mortem meetings are important, but they will only get you so far. Baseline columnist and senior IT project lead Bruce F. Webster reinforces one of the most overlooked aspects of IT management: Reading books. Webster outlines 5 books that are easy to read but chock full of real, practical project information and strategies for making IT management a better, less risky and more successful, less stress-inducing process.
Brooks was not the first to comment in print on the incompressibility of IT schedules; Jerry Weinberg actually did that in 1971 in The Psychology of Computer Programming and even used the pregnancy analogy (i.e., using nine women to produce a baby in one month) in doing so. But Brooks was the one who named his book after it, then went on to coin the still-controversial Brooks’ Law: “Adding manpower to a late software project makes it later.”
Brooks other observations – on how projects become late (“one day at a time”), on the need for conceptual unity via a chief software architect, on the second system effect (“the most dangerous system a man ever designs”), and on planning to throw away your first attempt at a given system (“you will anyway”) – all remain lessons that IT managers ignore at their own peril.
Death March (2nd edition) by Edward Yourdon. Edward Yourdon has been writing about software engineering and IT project management for decades and has published over two dozen books, but this is possibly his most important and timeless work. The term “death march” refers, of course, to major IT projects that appear to have a significant probability of failure (Yourdon uses >50% as part of his definition) but yet is pushing ahead anyway. Those of us who have been on death march projects know exactly what this is like; to quote Pete Seeger, “We’re waist deep in the Big Muddy, and the big fool says push on.”
Yourdon addresses, among other things, three very critical issues. First, how do IT projects turn into death march projects in the first place? After all, few organizations set out on a major IT project with the idea that it will go seriously over budget and schedule or fail altogether, yet it happens quite frequently.
Second, when it becomes clear that a given project has become a death march project, why do organizations often push ahead anyway, instead of pulling the plug or re-scoping the whole project? Here’s a clue: organizational politics are often involved.
Third, once a project has become a death march project, how do you get it out of that state or at least try to bring it to a successful conclusion? The answer involves negotiations and improved project management, but it also involves the reality that you might not be able to do it – and the decisions that you will need to make in that case.