Postscript
Editor's Note:
As a matter of editorial policy, upon completing a book review we always try to reach
the author to give him or her the opportunity to review our observations on their
work. We are not always successful in making contact, but the purpose is to make sure
we have not made any errors of fact in our quotations or observations such that might
compromise our opinions. While not all of our observations are complimentary, most
authors appreciate this opportunity.
In this case, author Tom Kendrick has written an interesting response in which
he explains how his book came about, and why it is the way it is. We thought that
readers would like to hear what he has to say. We also wish him well in his new-found
retirement and expect that he will be busier than ever and, like us, wonder how he
ever had time to go to work.
Date: Wed, 03 May 2006
From: Tom Kendrick
Subject: Re: The Project Management Toolkit
To: R. Max Wideman
Hi Max:
First, let me thank you for the review and for your taking the time to read through and consider the book in such detail. I am flattered by the kind words and there are not really any "errors" to comment on; your comments reflect either a consequence of the constraints I accepted when I took on the book or a difference in perspective, which is inevitable.
One of the AMACOM editors approached me in 2003 looking for a "200-page, 100 Chapter" PM book. He sent me the AMACOM "Manager's Tool Kit" as a sample of what they had in mind. I thought it would be an interesting challenge, so I agreed to write it. Unlike anything else I had written, The "Tool Kit" had to be written in its entirety, all at once not one chapter after the next.
For the proposal, I listed 100 topics that seemed logical, including the (then) 39 PMBOK® sub-knowledge areas. For topics in the 39 that seemed too big for a 2-page summary, I created new ones to break out some content. I added a few more topics that are not really explicit in PMBOK, particularly those relating to interpersonal PM aspects (where PMBOK is rather weak). As I got started, I wrote all 100 topic sentences (these turned into the header blocks). This uncovered some redundancy as well as missing topics, so the 100 morphed somewhat into a new list. The next step was to write a detailed outline for each short chapter, including all the cross-references. This revealed even more redundancy and missing stuff. Through further modifications I created a stable, final list of 100. This process did make some PM ideas less obvious because they ended up embedded inside one (or several) of the resulting chapters.
On things you noted as missing: Maintaining a "risk list" is included (as in PMBOK) in the risk identification and risk control chapters. Managing project issues is central to about a half dozen chapters (including those on meetings, performance management, conflict management, problem solving, decision making, and problem escalation). I decided to cover issue management in the context of issue sources, but that was a personal choice. User acceptance and transfer could also have been more obvious, but I decided to include it in "Scope Verification" since I had committed to including a chapter on all 39 PMBOK topics and it did seem to fit there.
Quality is unquestionably a key PM topic, but in most of the project contexts where I have worked in, it substantially overlaps with scope management, and I covered a lot of traditionally quality-related topics in those chapters. Estimating remaining work and cost (and when necessary, shifting the project baseline) are addressed to some extent in the project review chapter, as it is not typically something done for most projects in every single status cycle. I do take your point that re-estimating cost and timing could have been addressed more explicitly.
Two other areas worth a brief comment are infrastructure and "MBWA".[14] I have typically worked, as many do, in a project environment that is not very rigidly structured. There are usually few enforced methodologies or standards, and fewer "project offices." I think of the decisions review to tidy up the framework for a project as a "bookend" to lessons learned - a chance to actually respond to things that have not gone so well in the recent past when you are initiating a new project. It is also a useful place to be skeptical and question any choices made organization-wide that may no longer make much sense. (I have a new book coming out in July: "Results without Authority," that goes into this in a good deal more detail.)
Another bias I have comes from the 20+ years I spent doing projects at Hewlett-Packard. I took early retirement from HP last week, but the principle that projects are mainly about people is one that I am unlikely to surrender. I have seen a lot more projects fail because of conflicts and poor motivation than from faulty Gantt charts and imperfect WBSs. Dave Packard and Bill Hewlett both believed in "Management by wandering around"- building relationships and interpersonal trust. It is central to the so-called "HP Way", and remains strongly encouraged for all HP managers and leaders. MBWA is certainly about listening, but it is really more than that. Projects, especially today's "virtual team" projects, are all at risk when the project leader fails to understand this.
Anyway, this has rambled on long enough. Thanks again for your review, and if you have any more thoughts or comments, let me know.
Tom Kendrick
San Carlos, CA
14. MBWA = Management
By Walking Around
|
Summary