The 5 Books Every IT Manager Should Read Right Now - IT Management Must-Read Books: Death March
(
Page 2 of 4 )
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.
IT Management 
