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.
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.
by Jake Holloway, David Bryde, Roger Joby, published by Gower Publishing Ltd (Farnham, Surrey) as part of the “Advances in Project Management” series, ISBN 978-1-4094-0737-9, 122 pages, £26.50 RRP (review copy provided free of charge by the publishers)
Pragmatic PMO 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.
As a project manager, there are a few things you want in a project sponsor:
- A genuine interest in the success of the project
- Sufficient “clout” and credibility to argue for the project’s priority against other projects
- Availability to give ad hoc direction, sign off key documents, etc., as and when required
Failure on the part of the sponsor to fulfil any of these criteria can cause the project serious problems.
You might think that the sponsor’s interest in the success of the project could be taken as read, but this can be lacking, especially if the sponsor did not initiate the project but was “volunteered” for the role (usually by their boss). If there are multiple potential sponsors for a project, the most enthusiastic supporter of the project is likely to be the one that has the most to gain from project success, or the one who would wake up in the middle of the night in a cold sweat if the project was not done!
“Clout” usually comes from the project sponsor having seniority, or at least from having good connections with those in seniority, so from this point of view the more senior the sponsor, the better.
Availability sounds like a simple requirement, but the lack of it can seriously affect the successful delivery of the project. A sponsor who is too busy to give ad hoc direction on the best business approach to take in a crisis, for example, risks the project going down a blind alley. A sponsor who cannot give the time required to review and approve a business case will not get their project started; a sponsor who cannot devote a little time to removing project roadblocks will not get their project delivered.
It could be argued that a lack of sponsor availability to the project implies a lack of interest in the project, but this is not always the case. Sponsors who hold very senior positions may get bogged down in “Business as Usual” matters, particularly if they are detail-oriented people or adopt a “hands on” management approach with their BAU roles.
One approach that I have used successfully is to anticipate the sponsor’s potential lack of availability, and persuade the sponsor to delegate a significant chunk of their role to a deputy (ideally a right hand man/woman) who can handle the day-to-day sponsorship duties, with the more senior sponsor only being called on when unblocking is required or when the project is fighting for survival. The deputy will have better access to the sponsor than the PM, and thus the sponsor can influence the project through their deputy.
The senior sponsor is then called upon only when they are really needed, and the project benefits from the sponsor’s oversight, albeit through their deputy.
Are your sponsors just too important to be effective, and if so how do you handle it?
…a Case Study showing one approach to evaluating whether a project should be cancelled or completed.
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?