There are new versions of A Guide to the Project Management Body of Knowledge (PMBOK Guide®) – Fifth Edition (which will be the Sixth Edition) and PRINCE2® due out soon and I’m keen to see what, if anything, they have updated regarding how best to work with stakeholders on projects.
When I sat down to think about what I would write into the new guidance, it was hard to specify exactly what I thought was important. So many areas of stakeholder engagement (or ‘management’ in Old Terminology) overlap. Here are the 5 things that I settled on. This is what I would include if someone asked me for my input to a book about how projects should interact with stakeholders.
Nobody has, by the way.
1. Stakeholders should have a say in decisions that affect them
The first thing to understand with stakeholders is that they get a say. Regardless of what the business case says the solution is. Regardless of whether they’re above your pay grade or not. If a stakeholder is affected by a decision, it’s your job to talk to them and let them comment on how that decision is going to affect them.
They get a say. This is not the same as shaping the final decision. You can, of course, ignore everything that stakeholders say and do exactly the opposite, assuming the project sponsor and the rest of the decision-making group supports that (or makes the decision – technically as a project manager most of the significant decisions sit with other people anyway).
It’s polite to capture their input and to take it into consideration when the decision is made. And it’s important to provide feedback to the stakeholders who took the time to give you’re their input, even if what you effectively say is, “Thanks, but we couldn’t do what you suggested, and here’s why.”
2. Stakeholders can influence outcomes
Second, even outside of the decision-making arena stakeholders can influence the outcomes.
I’m not going to get into a debate here about the fact that projects deliver outputs, not outcomes. I’m talking about benefits, results, value and all of that, whether you feel that the project team has a part to in that or not.
Unhappy stakeholders influence outcomes. They could say that the project is not a success, even if you delivered on time, on budget and with the required quality ticks in the right boxes. They will moan to their colleagues that they didn’t get what they wanted from the project. They’ll complain that the business case was flawed. Whatever happens, they certainly influence the outcome: from the supportive stakeholder arguing persuasively for a Phase 2 to deliver more of the same or a disgruntled stakeholder whose negative words impact on the panel discussing your promotion later in the year.
Never overlook the fact that what stakeholders think, feel and say has an influence wider than you first imagine.
3. Affected is not the same as involved
The stakeholders who turn up to meetings and who receive your weekly reports are the ones who are involved. The people who are end users, customers, team managers, part-timers, are the ones who are affected.
For the avoidance of doubt, the ones who are involved are generally affected too, but involved and affected aren’t the same thing.
Your stakeholder engagement plan and the activities you schedule around communications, training, change management and so on should definitely involve the affected community as well as the people you email regularly.
4. You should actively seek input
You hold meetings and email out a report, don’t you? That’s not enough.
It’s not enough to pop an article in the staff magazine or do a presentation at a Town Hall meeting.
Without a way for stakeholders of all kinds to get in touch with you, all you are doing is broadcasting – and that’s the kind of thing Twitter is for. What’s effective for your community changes over time. For me, Twitter started out as a good way to engage with subject matter experts and practitioners. Now my Tweet stream is full of links to articles I’m never going to read. The shift over time has been noticeable – from an active way to discuss and seek feedback to an almost one-way broadcast tool, and you don’t want your project communications to go the same way.
Whether it’s a presentation, an article or a regular project newsletter, make sure you include a way for stakeholders to get in touch with you to comment and provide feedback.
If they don’t, go out and seek it. Ask for it. Turn up at meetings with the ‘hidden’ agenda of getting feedback. Drop in on the user testing and ask the gang there. Go out of your way to seek the input of the people who matter.
It sounds time-consuming, but if you glean one or two useful pieces of feedback that could drastically shape the way you develop the project, it will have been worth it.
5. Engagement first, scheduling second
Finally, plan your project after you’ve done at least some engaging.
Engagement rarely happens on the schedule you expect. Someone will be off sick when you are expecting their feedback. You’ll have to push the focus group back a week for an unforeseen reason. Or you’ll go ahead as planned and then realise that something came out of the engagement activities that mean you really should speak to that extra person or add more tasks to the schedule.
Where at all possible, build your project schedule around what falls out of how you engage with stakeholders. This has helped me multiple times: one notable example was delaying a software installation at one office where the building was being refurbished a few weeks later. If we’d gone ahead as scheduled it would have resulted in all our new PCs, shelves and equipment being ripped out. We wouldn’t have known that if we hadn’t spoken in detail with the office manager before the deployment began. As it was, we could easily switch out that office for another and the project team came back to that site later in the year once the refurbishment was complete.
I very much doubt that these points will be explicit in any new standard or guidance, but these things are good practice and not difficult to do. What is difficult is explaining to your project sponsor and the other Project Board members why you want to do so much engagement and why stakeholder management on your project has to go beyond a stakeholder register and a communications plan.
Hopefully you’ll be able to explain it in a way that makes them see the value if they don’t already.