Book Review: 97 Things Every Project Manager Should Know
Buy it now
One Minute Bottom Line
|This book is more than a reference. It's a tool to find the insight you need to remove the obstacles that are putting your projects at risk and a reminder that what makes or breaks a project is communication and understanding among peers.|
Review"97 Things Every Project Manager Should Know" is the kind of book that you read cover to cover and then keep near your workspace. Then, when you need advice, inspiration, or when you wonder what you're doing wrong, you pick it up again to find the insight to pull you out of trouble or to remove a roadblock that is hurting your project. And after that, you keep it even nearer because you know you'll need it again.
The book is very pleasant to read because of its high-quality yet fluent content and because of its clean design and excellent binding. The chapters are mostly two-pages long and they're deep and fully developed while incredibly straight to the point. Part of the appendix lists all of the author's biographies to establish credibility.
The depth of the insights and the value of the experience condensed in the small, easy-to-read chapters makes this book a great tool. Since the two-page pieces are all about real-world situations, and not a taxonomy or a condensed view of the PMI exams, you don't use it to look up a definition, but to find the idea to guide yourself out of a troubled situation or to reinforce your faith that things can be done better. And the format makes all too easy to pick it up, use it to resolve the current situation, and then put it down until it is needed again.
I once read a blog post that lamented the lack of lore in the IT profession; the fact that our work moves so fast that we can't accumulate and distill experience in a form that gets trasmitted from one generation of professionals to the other, something many other crafts and arts (much, much older than IT, to be honest) have and build on. The 97Things book may be a good answer to this problem, being about reviewing the various experiences some of the top professionals in the trade had in their projects. It captures the common factors of success and failure which have nothing to do with tools or technologies, but instead with human relationships, communication between peers, and professional behaviour.
If you read the book front to back (as you should the first time you pick it up), you'll immediately notice the recurring theme: it's the teammates that make or break a project. It's communication that fuels the team's speed, it's clear and honest relationships that direct the team toward success, and it's discipline that keeps a project from derailing to failure. It's very interesting that a subject matter like IT project management that many see as cold (as in "budget cash") and technical (as in "latest technology") is in reality heavily dependent on human interaction and collaboration.
The good project manager has to keep his WBS in order and his GANNT straight, of course; but those tools are needed more to keep his interactions with his peers in order. A 100% status report is worthless if it's based on flawed understanding of what "done" means, on a false perception of what value the result of the project is intended to produce for the end users, or even worse on fear of the consequences of reporting the real problems. So, like Eisenhowers' plans, WBS are worthless, but writing them is essential to elicit and facilitate interaction among team members and project stakeholders, and to promote truthful and honest communication among peers.
Put this book in a place where you can easily find it because you'll need its advice sooner or later. Reading the author's biographies, you see that there are people that know how to "do it right", so you can reassure yourself that you can, too. And reading the right chapter at the right moment, you can find that idea that you need to restart your project and bring it back on track, even when all the technology and methods have failed to you.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)