What We Liked
The Project Management Institute recently added a new section to its Project Management Body of Knowledge (The PMBOK® Guide) titled "Project Stakeholder Management".[9] In the interests of conformity throughout the PMBOK® Guide, this new section is structured the same way as all the other sections. The result is that the contents read like you are dealing with clearly cohesive groups just like you would manage sets of costs or activity schedules, and all more or less at "arm's length".
Moreover, the Guide identifies stakeholders in groupings such as "customers, sponsors, the performing organization, and the public who are actively involved in the project, or whose interests may be positively or negatively affected by the execution or completion of the project."[10] Interestingly, the Guide does not specifically include probably the most important stakeholders of all — the members of the project's own team.
While our authors take a somewhat similar approach to the Guide in terms of the process of identification, they take a distinctly different approach to grouping and handling their definition of Stakeholders. First off, as the Table of Contents shows, the authors choose to identify all the potential stakeholders in only four groups. These are: the Project Sponsor, The Project Team, The External Clients and Contractors, and the Internal Customers and Gatekeepers.[11] We think that this grouping is much more practical, meaningful and manageable.
Secondly, the authors avoid the use of the term "managing stakeholders", and instead prefer to use the term "stakeholder engagement". This makes enormous sense because stakeholders are, for the most part, influential and powerful in their ability to disrupt or delay the project, and do not like to be thought of as being "managed" by a project manager. So this book is not about "Textbook theory" but about practical reality. It is also laced with a little bit of typical British humor.
As an example, in a table comparing "Textbook v Reality", the first of eight examples characterizes the "Textbook" as follows:[12]
"Projects are started because there is a business case or positive outcome identified and the detailed plan shows that there will be a positive Return on Investment (ROI)"
Whereas in Reality:
"Projects are started because one or more powerful stakeholders want it to start. They believe that a positive ROI should be achieved (probably by you, the project manager) but have little or no evidence that it's possible."[13]
To give some idea of where the authors are coming from, the following is a very brief summary of the anecdote provided in Chapter 1 by David Bryde. It's called "A Failure to Persuade":[14]
"This incident occurred early in my career when I was a junior project team member. I was working on an infrastructure project that was mid-way through its implementation stage and going well in terms of performance. However, things changed when the project manager announced that they were leaving to take up a role in another company... .
It was not long though before word came from senior management that a replacement project manager would be arriving soon... .
The new project manager duly arrived for their first meeting with the Team, including myself, with the serious task of establishing their credibility in doing the job. Looking back now on what was a fairly embarrassing and unpleasant meeting it is clear that this need to establish credibility had not crossed the mind of the new project manager. They did the most cursory of introductions and got straight into the nitty-gritty of the tasks and activities remaining to be done to complete the Project... .
The major lesson I learned was never to assume anything. In this case the company assumed that the team would automatically accept their appointed person... ."
My, how things must have changed in the work place since our early days! Firstly, we too would never have thought of the issue of personal "credibility". After all, the Project is the company's Project, it's their money and their responsibility to manage at the staffing level. Secondly, we take a poor view of a project manager that fails to complete their responsibilities before moving to another company. And thirdly, we've always made a point on first arrival of doing a thorough research of all of the project's documentation from governance on down to the last change order. With this background in hand, perhaps credibility at our first team meetings was always a non-issue.[15]
What this example does emphasize is that people don't like change.
9. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Fifth Edition, 2013, p391
10. Ibid, p394
11. A Practical Guide to Dealing with Difficult Stakeholders, Chapters 2 through 5.
12. Ibid, Table 1.1 Textbook v Reality, p4
13. Ibid
14. Ibid, p8
15. We cannot resist adding that we have always liked to take on a project that was in failure mode. That's because management was then always more willing to open the purse strings when presented with a good, but likely expensive, recovery or salvage plan. Moreover, it is usually difficult to do worse than the previous incumbent — the "bar is simply lower".
|
Book Structure
