I can tell when I like a PM book after I'm done with it, and I don't mean from a kinesthetic standpoint, I mean from a physical standpoint. When a Project (or in this case, Program) Management book gets to me, it has dog-eared corners, drawings, notes, and yellow highlighter marker all over it.
And this book is one of those that has a whole mess of bent corners, drawings (one of which I actually will share with you), and it caused the demise of my trusty yellow marker. May it rest in peace.
Dr. James T. Brown has written the book to which I refer, "The Handbook of Program Management". As you can tell, I like the book even though I disagree with Dr. Brown on some points. One of those points is the title. First: the word "Handbook". This book was better than a handbook, at least how I think of handbooks. It read very well (unlike my stereotype of a handbook which a choppy, reference guide) and was full of "gems" from real example projects and programs. The other word is "Program". While it's of course true that the book focuses on Program Management, my issue is that it is an excellent book for Project Managers, as well. This is covered in the subtitle, "How to facilitate project success with optimal program management". I know it's long, but perhaps that - or some shorter version of it, like "Project Success through Optimal Program Management" - should have been the title! I guess I just don't want to see Project Managers miss out on the good things in this book - and this is one of the reasons I am blogging about it on a Project Management post.
I really liked the way in which Dr. Brown distinguished project and program management. For example, there is this:
Typically, the project manager is and should be more delivery and execution focused whereas the program manager has to also be concerned with the overall health and effectiveness of the program over the long term.
When he talked about the way that program manager and project manager view the projects they oversee, it actually inspired me to create a figure for the book:
Program managers see the projects in their context, where as project mangers may not necessarily see this - they instead see each as an independent entity. In fact, I personally think the more effective, enterprise-oriented project managers do take on this program view. Which is why I think this is an important book for project managers, not just program managers.
But here also is one other area where I found myself disagreeing with the author. He says that "Project management offices that establish policy as a primary function should be scaled down or phased out when that policy is mature. ". I agree that the push to follow the policies should be phased out, but not necessarily the whole PMO, and that the phase-out doesn't begin when the policy is mature, but rather when the project managers understand it, are following it, and it is reaping the benefits it intended. It's a matter of PM Maturity, which is always about more than the policy itself.
I point out this difference, but generally I found myself often shaking my head (vertically in agreement, that is) as I read the book. In fact, in some cases, especially in the excellent section on Program Communications Processes, the text was exactly in line with the kind of advice and consulting I have been giving PMs for the past decades - the author and I are definitely in tune on this whole section. In particular, his guidelines on p"Presentation Basics" is a great read not just for program managers, but for ANYONE who has to make a presentation, which, these days, seems to include almost everyone of nearly adult age.
One other example of violent agreement: the section on Identifying Stakeholders. I have already blogged about this and will undoubtedly blog about it again. But Dr. Brown eloquently put into words how important this is but how to do it with these guidelines to fully identify stakeholders:
- Follow the money! Whoever is paying is definitely a stakeholder. Also, if the program produces savings or additional costs for an organization then the organization is also a stakeholder
- Follow the resources. Every entity that provides resources, whether internal or external, labor or facilities, and equipment, is a stakeholder. Line managers and functional managers providing resources are stakeholders
- Follow the deliverables. whoever is the recipient of the product or service the program is providing is a stakeholder.
- Follow the signatures. The individual who signs off on completion of the final product or service (or phases thereof) is a stakeholder. Note: this may or may not be the recipient referred to in the previous bullet. Often there may be more recipients than signatories.
- Examine other programs stakeholder lists. Include active programs and completed projects.
- Review the organizational chart to asses which parts of the organization may be stakeholders.
- Ask team members, customers, and any other confirmed stakeholder to help you identify additional stakeholders.
- Look for the "Unofficial People of Influence". These may be people who are trusted by high-level leaders or who wield a lot of power through influence and not position.
The sections of Dr. Brown's books which cover Risk, Execution, Communication, and Team Building are extremely well -assembled and illustrated with "tips", "keystones", and actual snippets of program and project best-practice documents. Many of these are gems and are the cause of the folded-over corners and the death of my highlighter. Importantly, they are a great read not only for Program managers, but for Project Managers as well.
Upcoming review:
50 Lucid Thoughts: Shedding Light on Current Project Management Practice, by Ruth Murray-Webster & Peter Simon
.
The new PMBOK(R) Guide has a new process called, Identify Stakeholders.
