Downside
Chapter 3 — The Project Team is by far the largest chapter in the book. This is not really a "Downside", but the contents are certainly different to what you might expect. In fact, by way of Introduction, the authors assert:[16]
"Not all project management theorists consider the project Team as Stakeholders. However, as people who have massive influence on the Project, of course they are. Without the Team and their efforts the Project is not going to deliver — so you need them not just as resources but [also] as supporters. [So] In the first part of this Chapter we provide details of the various objectives and responsibilities that exist. [And] we focus on typical team members and on understanding what might be motivating them and how best to meet their individual objectives, whilst at the same time keeping the project goals firmly as the top priority."
In our view, the goals of the project itself should be the primary motivation for the members of the project team. If that is not the case, then either the benefits of the project have not been adequately explored and conveyed to the team, or you have the wrong team. Or, of course, you have a loser of a project in which case it should be modified or scrapped.[17]
The rest of the chapter tackles two general scenarios: a) A Demotivated Team, and b) Support for the Project has clearly evaporated. In the first scenario, the authors introduce a Cause-Effect Diagram of Project Team Demotivation so that the reader gets advice on dealing with such issues as: Team Boredom; Team Distractions; Frustrations; Disharmony, and (excessive) Stress. The last is typically from above and imposed on the project manager and team to produce results.[18]
The second part of this chapter, where Support for the Project has already evaporated, is downright scary, but nevertheless very necessary. It describes Team Mutiny in two shades: total or individual, and suggests four Tactics to Deal with Mutinous Situations.[19] Failing that, then how about Getting the Team to Work in a Different Way?[20]
Moving on to the final chapter: Internal Customers and Gatekeepers, the authors observe:[21]
"As noted throughout this book, sometimes projects get into trouble.[22] At these times most could benefit from help from their Stakeholders, but which has the most power? It's tempting to go straight to the Sponsor and the project board. However, there is a compelling argument that using other internal Stakeholders of the Project can ultimately be more effective — even if they are "just operations". The reason for this is that these internal Stakeholders are often either the direct Customer (or End User) of the Project, or that they represent or act as advocates for the end Customer (for example, if they are the Sales or Customer Services Operations team)."
We do have some difficulty with this advice. Firstly, the framing of this piece of text implies that the whole book is just for Information Technology readership. That's a pity, because most of the book provides good advice for any and every type of Project in the whole wide world of project management application. And certainly all projects are confronted sooner or later by "Gatekeepers".
Secondly, whatever you do as project manager, always, always keep your Sponsor informed. In other words, take your Sponsor with you. If your Sponsor should ever get wind of a real or perceived end run round him or her, your tenure will be short-lived indeed.
16. Ibid, p29
17. Don't be afraid. Go tell that to your project Sponsor!
18. Ibid, p31-48
19. Ibid, p49-51
20. Ibid, p52-54
21. Ibid, p75
22. Ibid — Oh really? We didn't know that.
|
What We Liked
