Every stakeholder on your project is going to come to the work with a different level of engagement. That level of engagement is going to depend on lots of things, like:
Often stakeholders don’t exhibit the levels of engagement that we might feel we need from them to get the best results for the project. Here are some thoughts and simple ideas for how to move people into a place where they are prepared to engage a bit more with the project.
Blocker to indifferent
Projects struggle when the wrong stakeholders are blocking the change. In fact, when any stakeholder is resistant to change, that can cause problems.
Blockers are possibly people who don’t see the problem that the project is trying to fix. They might be keen to defend the status quo, whatever that is.
Talk to them about why they appear to be resistant, or what they are worried might happen as part of this project. Try to share the reasons for the project and the ‘why’ behind the change, even if it doesn’t directly affect their team. They might be more open to engaging with the project if they know the reasons driving the change.
There are various things to try here, but it starts with trying to understand their position and probably ends with escalating to their line manager or your project sponsor.
Indifferent to keen
These are stakeholders who are a bit ‘meh’ about the project and you’d like them to be supportive.
Indifferent stakeholders may think the project isn’t relevant to them. Perhaps they don’t see the point of it. The project just doesn’t seem important. You can see this in their reaction to the work, their slow response in getting back to your messages and calls, and their general attitude to the project.
There is also a chance that you’ve asked them to be involved and haven’t been clear enough with the ask. Talk to them about their priorities and those of their team. Share the successes and if necessary, try to get some of their time ringfenced to complete their project work.
Keen to champion
Supportive stakeholders are keen about the project, but they wouldn’t necessarily be a champion – those super proactive stakeholders who really understand and make progress on the work. Some of your stakeholders probably need to be in the ‘champion’ category.
Think about how you best use their time so they don’t sit in meetings and hear updates that they already know about. Ask for some small commitments and see how they get on completing those before you ask for larger tasks.
Not everyone needs to be a champion
You don’t need everyone to be a champion. Some stakeholders are probably OK to simply be indifferent: as long as they aren’t resisting the change that could be good enough.
The idea of looking at stakeholders in this way and seeing where they are on a scale is to understand better about the kinds of engagement – and specifically the time commitment – required for each stakeholder or group. Those that have the furthest to go on the scale are going to need more time and more focused action to move them into the zone where you want them to be.
Does anyone have an example of a stakeholder who has moved into the ‘more engaged’ category that they’d be prepared to share in the comments? I’d love to hear your stories of successful stakeholder engagement 😊
I was inspired to do the Generative AI for Project Managers course (which is currently free, and definitely worth looking at on the PMI website) and from there, to sign up for a ChatGPT account. In parallel to that, I was asked to deliver a webinar on AI-proofing your career (spoiler alert: AI takes away the parts of the job that I didn’t like so much anyway, and frees up more time for you to shine in human relationships), so I seem to have embedded myself in the world of AI recently!
I thought I would put ChatGPT to the test by asking it a question I get asked frequently:
What are the top 5 challenges affecting project managers in the world today?
This is an edited version of what it said. It gave me 246 words, and I’ve added my own thoughts after each point to add a human-in-loop spin on the feedback. The GenAI course explains human-in-loop if you have not come across this term before.
(Sidenote: I feel weird calling it ‘it’ when you can have a conversation with it. I think I would like to give my ChatGPT bot a name, I just don’t know what!)
As of my last knowledge update in September 2021, the following were some of the top challenges affecting project managers worldwide:
Elizabeth says: So far so good. This seems to be a perennial problem across the ages. It’s not particularly new, but I’m sure it is true. Every project manager I speak to seems to have issues with resourcing and capacity planning.
Elizabeth says: Again, this is not new news. It’s not the modern, fresh take I was hoping for. Perhaps there isn’t one: we’re stuck with the challenge we’ve always had, which is reassuring and disappointing at the same time!
Elizabeth says: I’m sensing a theme here. These are all true, but as project managers, we’ve been overcoming the challenge of remote and distributed teams for years, even before the pandemic.
Elizabeth says: I agree that risk management and working in uncertainty is a challenge, but we have whole project approaches designed to minimise the impact of that and maximise user engagement through short deliverable sprints. Yes, the world is an uncertain place, but again, project managers have been looking out for the things that will bite us in the backside for years. That’s the job!
Elizabeth says: I would not have put stakeholder management as one of the challenges for project managers. In fact, it’s one of the fun parts! I do understand that it is challenging to manage competing priorities, but again, our processes are set up to identify those and work through them.
Then ChatGPT goes on to add:
Please note that the landscape of project management may have evolved since my last knowledge update. Factors like emerging technologies, evolving business models, and global events (such as the ongoing COVID-19 pandemic) can introduce new challenges or shift the emphasis on existing ones. It's recommended to stay updated with current industry reports, trends, and insights to understand the most pressing challenges faced by project managers in 2023.
Elizabeth says: I agree that it is important to stay up to date with the pressing challenges, and the best way to do that is to stay connected to the industry. Conferences like the PMI Summit and publications like project management magazines provide timely insights into what is important. For example, sustainability isn’t on the ChatGPT list and I would have thought that would have been a concern back in 2021.
I haven’t yet paid for an upgraded account, so perhaps a paid account would have better outcomes and give me a different take on what the current challenges are, so there’s that to consider.
Meanwhile, I’m curious! Do you agree with these challenges? Do you think there are others more pressing for us as project managers? And what do you think of the output of ChatGPT if you’ve used it? Let me know in the comments below!
Earlier this month, I wrote about our summer trip to a holiday park. Two of the shows we saw while we were there were magic shows. One was a comedy-style show with some fun magic thrown in. The other was a ‘proper’ serious magic show with all the atmospheric lighting and big illusions.
It got me thinking – I know, this is not how most people spend their holidays, but perhaps project managers are this way inclined – about the parallels between the shows and my job back at base. Here’s what I learned.
1. The wait is part of the journey
We learned on other holidays that if you want a good seat, you have to get to the show early and sit and wait for a loooong period of time for it to start. This is because there is no allocated seating.
While we were waiting for the show to start, having arrived 40 minutes early, the family at the table next to us got out a game to play. They used the downtime as family time, getting everyone involved. It was part of the experience for them: being around a table to play a game.
We had brought books and electronic devices, and we were all occupied but not together. We weren’t using the time as family time. We were just waiting.
The wait is part of the experience. Plan for downtime on your project. How can you use that time productively? For example, can you bring forward tasks, fit in a peer review or a risk review, run an audit, or something? Where there are slower periods on projects, what are you going to do with them?
2. Same prop, different delivery
Both magicians used an identical prop, and they both performed Houdini’s Metamorphosis trick (where one person is locked in a box and the other stands on top with a curtain – they drop the curtain and they’ve switched places).
But the delivery was different. One was fun and light; the other was dark and dramatic. But the box looked the same, and the trick was the same.
Tailor what you’ve got to make it yours. The lesson for me here was how one item could be used so differently. Tailor what you use to make it relevant to your project and the way you want to deliver your work.
3. If you’ve not seen it before, it’s magical
The second magic show contained big set piece illusions: a box pierced with swords, but amazingly the magician inside was still safe, making snow from a piece of paper, levitation, escaping from a strait jacket before a flame burns through a rope and the magician is squashed. I am a huge magic fan, and I’ve seen all these before, in live shows and on TV.
But for my kids, they are new.
And they were truly amazed.
Don’t take for granted what you know. For some of your stakeholders, the magic of project management will be new for them. Train people in the process. Let them know what to expect and help them understand things about the process that feel new and different.
You’ve seen it all before; you’d read about it, done it, written the documents, and got the T-shirt. But they haven’t. Give them the support they need to come along the journey with you.
Project management isn’t really magic, but some days it feels like the team comes together, and we’ve pulled off something amazing. Don’t you think?
We talk about the cost of change often on projects. If you’ve been in a delivery role for a while, you’ll no doubt be familiar with the idea that if you find something you want to change later on in the project, it costs more to make that change than if you identified it at the beginning.
That’s typically because there are fewer things to unpick and less rework required because you haven’t got as far yet. You can change the buttons on the widget if you haven’t manufactured any buttons yet. Just change the drawings or spec and you’re done. But if you have a factory stacked with boxes of buttons, then there’s a bigger cost involved – all the pre-made buttons need to be scrapped and you have to manufacturer a bunch of new ones.
Understanding how much wiggle room there is for change is important in understanding how easy it will be to make change later, and how agile (with a small A) you can be during the project when it comes to addressing defects or changing your mind.
Bridge building, button making, house construction: all these are hard to change later. But business process change, website design, or software writing probably have a different result. You can tweak a process later on, and while a group of different stakeholders will be affected, it is certainly possible (and cheaper) to do in a way that changing the foundations of a building once half the building is built is not – it’s a different kind of conversation, and a different kind of cost involved.
How easy it is to make the change, and the cost of change, play alongside each other throughout the project.
The PMBOK® Guide 7th Edition talks about Boehm’s cost of change curve. It sounds like common sense, but it is also important to challenge our assumptions and what we think we know. There is also a difference between bugs and changes that arise through active decision making. Is the cost of change the same for each on your project?
It might be possible to add a financial amount to each change and each defect so as to work out the potential cost of defects or changes addressed later in the lifecycle, but that’s probably overkill for most small and medium-sized companies, and organisations that are not software houses with plenty of data to analyse for this. Unless you’ve been through many product recalls or can model what it would look like to address a component failure, you might not have the data or time to create any meaningful cost models.
Instead, bear in mind the general principle: what is it going to mean to make a change on your project, for your decision makers, in your environment, for the development and delivery methodologies that you are using? Are there cutoff points? Points of no return?
Generally, as project managers we can make anything happen with enough money, time and resources – whether it’s the right decision to do ‘anything’ though is a completely different conversation.
It is sensible to think about the cost of change before you need to make any changes, and to consider how you’re going to avoid too many potentially costly changes. For example:
How do you think about the cost of change in your projects? Is it a discussion you have with the team? I’d love to know how you work to minimise it – or if you embrace it and go with the changes! Let us know in the comments below.
Every project needs a go live project checklist – at least, projects where there is a substantial ‘go live’ moment, like a software launch.
The checklist is helpful because it confirms what is needed to go live: the steps and actions that should have been completed. It’s a reminder of what work is required in the run up to the big launch – or the small launch if you’re doing things in a phased or incremental way.
I’m a big fan of go live checklists because they help take the emotion out of the decision about whether or not we are ready. If we have ticked all the boxes, we’re ready. It makes the go/no go call very straightforward.
Here are some typical things to include on a checklist, although bear in mind that every project is different and you’ll need to make sure the items on your list match what it is you are doing.
We would also book a go live meeting. I remember one call we had for a big software pilot and going round the (virtual) table and asking each workstream leader to say ‘yes’ or ‘no’ depending on whether they felt the go live criteria had been met. It was a challenging call, because while we had on paper met the criteria, things were still a bit wobbly.
These conversations give you a chance to get all stakeholders on the same page about whether to go or not, and that’s helpful for creating a shared sense of responsibility as soon as you make the decision to get started!
I’ve noticed a trend towards incremental delivery and smaller launches, even on projects using a predictive methodology. There is still a place for a go live checklist, because getting everyone together to make a joint decision about next steps is still valuable. It’s the opportunity to get sign off on the approach and next steps from the business representatives, IT representatives, vendor, sponsor and anyone else who has an interest in what happens next.
When to use a checklist
Timing your go live is really important for maximum impact and availability of support staff. For example, we would never put an IT system live on a Friday as there would not be enough project team members around over the weekend in case of issues. We would put software changes in overnight, and have enough staff around in the morning to monitor the system and deal with any unforeseen issues.
Think about when you are going to have your go/no go call and when your go live is going to happen. The call itself needs to be close to the go live but probably not the same day, for example it would work well to have a call on a Friday for a Monday go live, or a Tuesday for a Thursday go live. But look at your schedule, consider the impact on users and make a decision as a team.