Published here July, 2009.

Introduction | Book Structure
What We Liked |  Downside | Summary

What We Liked

We liked the way the book is laid out and its logical and progressive structure. The book contains much that is standard project management fare. That is, the sort of stuff that is repeated over and over in somewhat different forms by project management authors far and wide, especially those commissioned to write short articles for magazines and the Internet. However, this is necessary to complete the coverage of the subject.

What is refreshing are the snippets of wisdom culled from the personal experience of the author or his colleagues. For example:

"Effective project leaders identify opportunities to align what the project needs with what individuals want to do, and they assign responsibility for project activities accordingly."[5]

We are not sure we have seen this expressed quite so clearly before but it is a very effective ploy. The reason why it works is because technical people are usually passionate about their expertise and if you give them an opportunity to show off their skills, they will be happy with the assignment and tackle it with enthusiasm.

Another example:

"Another key to influence is effective communication. Project leaders are either good communicators or they are not project leaders for long. Communication is the one absolutely undisputed responsibility owned by the project leader, regardless of project type, other responsibilities, or authority. To succeed and retain control, you must manage information and communicate effectively."[6]

The reason why this is true is simple. Without people there is no one to get anything done, but without communication, no one knows what to do. And the author goes on to explain:

"Using the power of your pen, you can control your project through filtering and summarizing, and deciding how best to distribute information and when."[7]

This thought is further elaborated in Chapter 2 under Information Management.[8] Of course, this idea does require that your team actually reads the stuff you distribute, so make it relevant, concise and to the point. But it also needs to be transparent, not obscure.

Given the importance of communication thus expressed, is it not surprising that so little attention is given in the project management literature to the underlying skills required for this activity?

Another snippet of good information:

"Some of your power to control and manage your project comes vicariously from others who do possess organizational power. Your sponsor can confer status on you by formally appointing you as manager (or at least leader) of the project; you can even offer to write the memo for your sponsor to sign or send that announces the start of the project and your responsibilities."[9]

Of course, if the "sponsor" is not willing to sign and/or send that missive, you know that s/he doesn't have the necessary power either - and your project may be doomed from the start!

On a related issue, isn't it interesting how, in that short text, "leader" is viewed as subservient to "manager"? And yet, in project management circles at least, project "leadership" is more highly valued than "managership".

Another piece of good advice:

Preferred communication styles vary a great deal, with some people preferring informal interactions to be verbal and others who prefer more distance and communications in writing. Uncovering these preferences is an important part of establishing a relationship with each of the members of your team. This can be a challenge, especially when the interpersonal differences between you and a contributor are significant or the team member is located far away. Nonetheless, to the best of your ability you need to minimize the effects of your cultural and other differences. This is easier said than done, but one tactic that helps is never to pass up a chance to visit distant team members, to see for yourself where and how they work. Going alone is most effective, because traveling with other people can result in a "bubble" that creates a barrier to really understanding the places and people you visit."[10]

From Chapter 5 onwards, the text is laced with short anecdotes illustrating the point at hand such as the "RACI" chart that displays levels of responsibility and the name stands for "Responsible; Accountable; Consulted; or Informed". The story goes like this:

"Scott Beth, a senior manager with the XYZ paper company tells this story about starting a project to convert the company's paper stock to recycled paper. After initial discussions with the sourcing manager for office and paper supplies, I asked her, 'Who's the Driver[11] for this project?' She said she wasn't sure, and we realized there really was no owner for that area. I agreed to be the Approver and to be accountable for the decision to convert to recycled paper. After discussing this, I asked the sourcing manager to own the Responsibility for making this change. We set up milestones for reviewing progress. When we clarified the RACI for the project, we immediately started making progress and easily met all the timing and expense goals for converting to recycled paper. Defining the roles and responsibilities, especially in writing, is a very effective way to secure the reliable commitments that you need to depend on to control any project."[12]

We were delighted to see Tom address one of our own particular hobbyhorses. About "Life Cycles and Methodologies" he says:

"Life cycles (or stage gates, phase reviews, or other sequential project timing structures) and methodologies are related in that they impose discipline on projects. Life cycles primarily serve to coordinate related projects, whereas methodologies strive to ensure consistency in how project work is done. Mandatory process aspects of either (or both) can significantly enhance your project control."[13]

Amen to that. Translation: Life cycles (or spans) are how you manage the project through its natural time span. Methodologies are how you go about handling the specific technology involved in producing the project's deliverable. Or, in other words, managing the project and managing the technology are two different things.

Book Structure  Book Structure

5. Ibid, p5
6. Ibid.
7. Ibid.
8. Ibid, p23
9. Ibid, p80
10. Ibid, p182 (emphasis added.)
11. I.e. "Who is Responsible?"
12. Kendrick, T., A Project Manager's Guide, Results without Authority, p106. (Text slightly simplified.)
13. Ibid, p9
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page