The 5 books every IT manager should read right now

In a prior post I talked about setting up a reading program for your IT department. However, whether or not you can get your IT engineers to read, you yourself need to be aware of the fundamental realities of IT project management and software engineer that have been discovered again and again. In other words, you need to lead by example and read this stuff first.

So here are five books that you should buy and read as soon as possible, if you have not already. And, honestly, if you have already read these books, you should probably read them again.

These are not the only books you should read — here’s my full recommended reading list — but these have the advantage of all being relatively thin and easy to get through, as well as all being currently in print.

The Mythical Man-Month (Anniversary Edition) by Frederick P. Brooks, Jr.. Brooks first published The Mythical Man-Month in 1975. It was a collection of essays from his experience as project manager for the IBM OS/360 operating system team, and it became an instant classic, both for its readability and its fundamental truths.

Every time over the years that I’ve thought I’ve come up with some new key insight in IT project management, I’ve usually been able to find some passing reference to it in TMMM. In 1995, Brooks published an anniversary edition, which contains the text of the original edition, plus several more essays, including the classic “No Silver Bullet—Essence and Accident” as well as Brooks’ own analysis of how well his observations have held up.

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”), which Brooks now says presages the concept of iterative development — 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.

Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister. I cited this book in an earlier column on risk management, but it’s worth citing again. As with the other authors named in this column, DeMarco and Lister have been writing on IT project management and software engineering for a long time; I had a hard time choosing between this book and Peopleware, their book on IT team management, which should provide you with a hint to go read Peopleware as well.

What is useful — and in fact critical — about Waltzing with Bears is that it takes you step-by-step through the process of identifying, analyzing and, where possible, quantifying the risks your IT project currently faces. DeMarco and Lister then discuss how best to mitigate those risks, either up front or as they arise. Their simplest answer is the most obvious, yet the one most often ignored: start earlier and build cushions into the schedule.

After all, as they point out, when we travel to another city for a critical business meeting, we usually leave lots of safeguards into our travel plans to account for traffic jams on the way to the airport, delays in getting through security, flight delays or cancellations, and so on. Yet when we plan an IT project, we tend to rely upon highly optimistic assumptions for every aspect of the project — and then get upset when those assumptions turn out to be wrong.

Facts and Fallacies of Software Engineering by Robert L. Glass. Having spent decades both in the software engineering trenches and writing about his experiences, Glass now summarizes much of what he has learned in a highly readable and well-documented list of , well, facts and fallacies about software engineering. He gives 55 facts and 10 fallacies, each following the same format: he states the fact (or fallacy), discusses it, identifies controversies regarding it, then gives sources (with specific references). The facts are group into four major categories — management, life cycle, quality, and research — and the fallacies into three — management, lifecycle, and education.

My personal favorite is Fact #14: “The answer to a feasibility study is almost always ‘yes.’” Billions upon billions of dollars have been lost in major failed IT projects for just that reason alone.

I would say that many of Glass’s facts are obvious, except that I repeatedly see IT projects where they were clearly ignored. As an IT manager, you may find that the best use of this book is to quote sections of it wholesale into memos for upper management. Keep this book handy and review it often.

Perfect Software and Other Illusions about Testing by Gerald M. Weinberg. And then there’s Jerry Weinberg, who has forgotten more about IT project management and software engineering than most of us will every know – and he doesn’t forget much. I could have picked any number of his books – and almost picked The Psychology of Computer Programming (which you should read anyway) – but Perfect Software tackles a subject I feel passionately about, namely the issues of quality engineering in major IT projects.

Weinberg’s style is to tell stories and then capture the essential truths into clear, simple statements. His focus always encompasses the human factors that overwhelmingly dominate IT systems development. In Perfect Software, Weinberg turns that focus onto why we test software, how we test software, and where we usually go wrong.

Each chapter ends with a list of common mistakes – one of my favorites is “Confusing documents with facts.” As with the other four books above, this is a book that you should carefully read and ask yourself, “Where are we making these mistakes?”

There’s your list. These five books together make a stack less than 3” high and comprising about 1100 pages — which is to say, a bit shorter than some of those massive programming language tutorials. But unlike those tutorials, which will likely become outdated within a few years and be thrown out not long after that, these five books will be useful and meaningful for decades to come.

But only if you read them.

[Adapted from an article originally written for the online version of Baseline.]

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.