Stakeholder-led Project Management (Book Review)

Full title:Stakeholder-led Project Management – Changing the way we manage projects
Author:Louise M Worsley
Publisher:Business Expert Press (New York) 2017
ISBN:978-1-63157-467-2
Pages:191
RRP:£28.45 (review copy supplied free of charge by the publishers)
Rating:****

Overview

  • The aim of this book is to provide a stakeholder-centred analysis of projects, and to explain which stakeholder identification, analysis, communication and engagement models are most relevant to different types of projects.
  • Using case studies from around the world, it illustrates what goes wrong when stakeholders are not engaged successfully, and what lessons we can learn from these examples.
  • The book is aimed at project professionals who find themselves involved in managing projects with stakeholders (so that’s just about all of them then!).

What’s inside

  • This book is based on evidence from over 200 project stories gathered over five years, and the common theme of stakeholder engagement as the key differentiator between success and failure.
  • Having first rejected the term “stakeholder management” in favour of the less sinister-sounding “stakeholder engagement”, the book starts with a review of the current state of stakeholder engagement both in projects (opportunities for improvement) and other disciplines (opportunities for cross-pollination).
  • It goes on to present a range of models and techniques for stakeholder identification, action and review, including the use of emerging communications technology.
  • It continues with an analysis of the difference between communication and engagement, before finishing off with a review of the main learning points, and what to focus on to create meaningful engagement in projects and programs.
  • In classic text-book form (was this book written for PM students?) it finishes each chapter with a chapter summary and a series of questions designed to stimulate reflection.

Some of my favourite take-aways

  • The composition of stakeholder groupings changes over time (sponsors and product users during implementation and after Go Live, widening to include sometimes entire countries in the case of infrastructure projects), so need to plan with the end in mind and engage stakeholders who arent yet aware of or interested in the project.
  • If you think you are doing stakeholder engagement and it’s not making a difference to how you run your project, then you aren’t!
  • Effective stakeholder engagement becomes more important the more greater the technical difficulty of the project, and much more important the greater the human difficulty

    “Projects can no longer choose if they want to engage with stakeholders or not; the only decision they need to take is when and how to successfully engage”

  • Role-based stakeholders are defined by a role they have in the project (Client, Decision maker, Expert). Identify them using organisational breakdown structure analysis, project governance checklists, and asking “who else should I be talking to?”
  • Agenda-based stakeholders represent a viewpoint, usually external to the project, which may not be apparent until a crisis emerges. Although they may be silent initially, these stakeholders often have the greatest impact. Identify these using Focus groups, 1:1 interviews, Strategic tools (e.g. SWOT, PESTLE analysis), successive nomination (snowball sampling)
  • Stakeholder-neutral projects have clear, generally agreed outcomes. Engagement peaks at the project start, and again just before transition
  • Stakeholder-sensitive projects have clear outcomes that affect people and practices. These people need to be considered when designing the outcomes, and engaged throughout the project.
  • Stakeholder-led projects are highly influenced by stakeholder groups and individuals, so engagement is critical.
  • Parallel projects are not directly aimed at programme objectives, but are sometimes set up to safeguard critical success factors for another project
  • Good stakeholder engagement:
    • Gives people a say in decisions that affect them
    • Promises that participation will influence decisions – and demonstrates how
    • Seeks out those potentially affected by, or interested in, a decision
    • Seeks input from stakeholders on how they may wish to participate
    • Provides information, time, and space to allow stakeholders to participate in a meaningful way
    • Is polite

The Verdict

  • This book is written in an easily readable style, is not too long (I read it in 3-4 hours, and I was making notes for this review) and has some useful pointers on how to improve stakeholder engagement, drawn from both theory and experience.
  • With the amount of information and ideas in this book, most PM professionals should easily be able to find enough implementable suggestions to justify the cover price; so this book is recommended.

Related Articles

Images of Projects (Book Review)

This book recommends that project practitioners should consciously view projects through multiple “lenses” or “filters” to gain different perspectives. This approach directs attention to project aspects that might not otherwise be considered, which will affect the action taken, and hence the results obtained.

Considerable repetition of the principles and case study content (mainly to make it easier to use for reference), and overlap between the images caused me to have several déjà vu moments in reading it straight through, but the approach should be useful to PMs (on projects and programmes) and PMOs (to challenge PMs on their view of projects, and to think about portfolios) at all career stages. Continue reading “Images of Projects (Book Review)”

Managing Business Transformation – a Practical Guide (Book Review)

by Melanie Franklin, IT Governance Publishing, Ely, 152 pages,  £24.95 RRP (review copy provided free of charge by the author)
Pragmatic PMO Rating: ****

This book is intended as a practical guide to understanding and managing change that will benefit your business. It covers the differences between change management and project management, and how to integrate the two.

It starts by loosely defining change management (making a large change to a business that involves a large proportion of the organisation), and breaking it into four stages (understanding; preparing; implementing and embedding). Each chapter of the book deals with one stage before finishing with a look at the alignment of change management with the project management that underpins it.

Chapter 1 (Understanding) suggests reviewing the business case to understand the drivers for change, and comparing the “from” state with the “to” state to understand its scale. It recommends cultivating support using a vision statement as early as possible to increase participation and reduce resistance.

Chapter 2 (Preparing) proposes producing a road map to the desired final state, listing what will stop, what will continue and what will start as a result of the change. This “paves the way” for the change and smooths the transition. Plans should be built constructed in both top-down and bottom-up directions, and will not need many updates. Plans should be communicated to stakeholders often enough to ensure the message gets across, and tailored to their needs.

Chapter 3 (Implementing) describes building the change team and ensuring various team roles are represented. It discusses potential emotional reactions to the change, and offers ways to address these to help those affected to move through the change smoothly. It maintains that change managers need more “friends” than average, and offers ways to cultivate this.

Chapter 4 (Embedding) describes how the change progresses from “new” to “normal”. It recommends measuring adoption, and dismantling the old ways. This can be encouraged using financial incentives, celebration, coaching for stragglers, and a managed exit for those who cannot or will not adapt.

Chapter 5 (Alignment with project management) highlights that whilst project teams generally deliver change enablers (e.g. a new IT system), it is others that take these enablers and embed them into organisational culture. Thus the change life cycle is related to and analogous to the project life cycle, but distinct from it.

Conclusion

This book draws useful parallels between change management and project management whilst highlighting differences. The use of voices from people who have “been there” makes the advice real, and the liberal use of diagrams helps to explain the various concepts. At 152 pages this book takes <2 hours to read; with a RRP of £24.95 it is likely to pay for itself many times over with application of just a few principles. Recommended for project managers who want a better understanding of how their projects fit into the bigger picture.

Related Articles:

Dealing with Difficult Stakeholders – A Practical Guide (Book Review)

Full title:A Practical Guide to Dealing with Difficult Stakeholders, as part of the “Advances in Project Management” series
Author:Jake Holloway, David Bryde, Roger Joby
Publisher:Gower Publishing Ltd (Farnham, Surrey) 2010
ISBN:
978-1-4094-0737-9
Pages:122
RRP:
£26.50 (review copy supplied free of charge by the publishers)
Rating:****

This book aims to improve Project Managers’ understanding of their projects’ stakeholders, and in doing so to improve the quality of engagement and hence project outcomes.

It starts by stating the obvious (but easily forgotten) truth that project stakeholders are all human beings (hmmm, not sure if I can say that applies to all the stakeholders I’ve dealt with…) with all the emotions, personal agendas, hopes and fears that entails. It crucially points out that they may not care about or really support the project (even if they say they do), and that behind the scenes they may even be working really hard to ensure it fails.

The book analyses the various motivations for this type of behaviour (which differ according to the stakeholder’s relationship to the project, and their position in the organisation). It deals with each type of stakeholder in turn (Sponsor, Team, internal/external Clients, internal/external Suppliers), using psychological and business research to explain various ways in which that type of stakeholder may behave. It then suggests practical ways in which these stakeholders can be engaged to improve their interaction with the project and increase the likelihood of a positive outcome. It adds colour (and spice!) by illustrating these approaches with real examples drawn from the authors’ experience.

Here a few key “take-aways” that resonated with me and my experience:

  • Accurate reporting may be suppressed or prevented if they differ from the perceptions of a powerful stakeholder (I have seen this in the form of Green Side Up reporting)
  • Changing stakeholder attitudes may not be possible; focus instead on changing their behaviour
  • The most successful approaches for dealing with project saboteurs are generally those in which the saboteur appears to win (or at least not to lose)
  • Project Team members are also stakeholders, with their own motivations, agendas, and objectives. Make sure they are motivated to deliver the project! (the book contains approaches to deal with everything from one or two uncooperative team members to all-out mutiny)
  • When delivering a project for an external Client, make sure they understand you are only delivering the product; it is up to them to use that product to realise the benefits.
  • Enlist the project’s End Users, give them a voice, and use it to influence the Sponsor and Project Board.
  • Pay attention to project Gatekeepers (PMO, Finance). Engage with them, provide what they ask for and follow their procedures as far as possible, and they will be more sympathetic if (when?) you need to do something that breaks The Rules or doesn’t fit inside them.

At 90 pages of actual text, this is not a long read, and is easy to follow and understand. It gave me several “Aha!” moments (NOW I understand why that person behaved that way on that project, and how we could have handled it better…)

I would say that this book is probably most likely to be useful to someone who has a few projects under their belt, and wants to understand and relate to their stakeholders better.

Price per page may seem a little high, but at £5 or less per actionable insight I would say it represents good value for money.

When the Client wants to Pull the Plug

…a Case Study showing one approach to evaluating whether a project should be cancelled or completed.

When the Client wants to Pull the Plug

First, some context…

Some years ago I was managing a project to design and manufacture about 20,000 pieces of equipment for a household name client (let’s call them ClientCo) of the engineering manufacturer I was working for (we’ll call them MyCo).

MyCo’s project costs were to be factored into the selling price of the units (rather than invoicing ClientCo as we went along), and it was crucial to the financial stability of MyCo that we would sell the units at the end of the project.

Part way through the project, ClientCo restructured. Budgets were revisited, and question marks appeared over my project that was a “nice to have” for ClientCo but a “must have” for MyCo.

The challenge I was set by MyCo was to demonstrate to ClientCo why they should continue with the project and make their cuts elsewhere.

We needed them more than they needed us

Design-and-manufacture Projects deliver the benefits right at the end. There’s nothing to be gained from owning component tooling and assembly jigs – you have to make, and use the finished product in order to realise the benefits.

Calculate cost:benefit of completion vs. exit

I laid the finances on the line, preparing a breakdown of the cost to complete the project with a statement of the benefits to be gained, vs. the cost to exit the project early (comprising remaining project costs, plus costs to make the tooling for component manufacture, which had already been contractually committed to). I added this cost information to my (weekly) Project Status Reports.

Let the Client decide (after all it’s their money…)

Initially, the exit cost was considerably less than the completion cost, but exit would have been embarrassing for my customers at ClientCo as it would entail expenditure without benefits. I explained my ClientCo customers that as the project progressed, the completion cost would decrease in relation to the exit cost, and benefit realisation would draw closer. The project remained in funding limbo for a couple of months (with my ClientCo customers explaining the journey towards benefit realisation to their own Sponsors), but it soon became apparent to ClientCo that it was better to complete (and realise the benefits) than it was to exit, and the project continued right through to manufacture.

Have you been in a similar situation to this? What approach did you use? How did it go?