The Money Files

Last time I wrote about managing the project and the team during the end of year countdown and the holiday period – today I’m thinking about managing stakeholder expectations.

Let’s face it, our stakeholders are also distracted by holidays, year-end processes, and vacations, and we still need to keep them engaged and informed about project work. Here are four practical strategies to keep everything on track at this time of year.

1. Understand their availability

Are they taking time off? You can ask – even senior leaders are likely to be scheduling a break! Their availability (or lack of it) might mean rescheduling project board or steering group meetings, and it’s better to know about that early.

Discuss realistic expectations for responses and turnaround times during December – if you’ve got key members of the project team out of the office, you might need a little longer to get back to them, or they might need to deal with someone else on the team. Pass along any contact details or make introductions beforehand so they know who to talk to – and so that person is aware that senior leaders may be reaching out while they are covering for a colleague.  

2. Prioritise critical deliverables

Make sure you and your stakeholders have a shared view of what deliverables are critical for this period. Define what must be completed before year-end and what can wait. That might already be clear from your project plan, but if you are working in an agile way or in an environment of high uncertainty, it would be worth reiterating what is possible before the end of December.

If you can, think about how you can build flexibility into timelines and make those suggestions. The stakeholders might not understand what goes into completing a task, so they might see something as do-able when in fact it is not. If your office has a mandatory closure or an IT change freeze, that might also eat into the time available to complete work.

A clear list of urgent deliverables and non-urgent tasks can help everyone prioritise, and it’s likely to look different from the last time you created one, because that’s life!

3. Communicate early and often

This is not going to come as a surprise, as communicating early and often is something you’ll be doing all year round. However, at this time of year, there can be a lot of communications, a lot of deadlines and messages can get lost.

Check in to see how they would like to be updated and if that is different from the rest of the year, update your comms plan so you don’t have to ask again next year.

4. Think about stakeholder fatigue

We all need a break, right? Stakeholders are no different. If you’ve been powering on waiting for the holidays, so have they. Think about how you can keep stakeholders engaged during a busy time, maybe cutting the length of meetings, sharing papers earlier so they can read them before a meeting or sending out weekly email updates instead of having status update calls.

Don’t forget to say thank you! We tend to schedule time with the team to celebrate achievements, but our senior leaders were also part of that, so recognise their contribution too. You might be the only one who does…

Good planning and communication can help manage stakeholder expectations even when times are busy – and the run up to year end is definitely busy!

As a project manager, there are two types of self-management I have to do.

Proactive management is looking ahead, making sure I know what is coming up.

Reactive management is addressing the challenges of the day, fire-fighting and being asked to do something on top of my existing workload.

Proactive management

I think proactive management is where most of us should be spending most of our time. We should be looking forward, using risk management, horizon scanning or whatever you want to call it to get a good idea about what’s coming.

For example:

• Future projects that your manager is going to assign to you.
• Upcoming milestones that you need to check in on and make sure are on track.
• Risks that have a close proximity that need active management.
• Engaging stakeholders so they know what is coming (with the goal of reducing ad hoc queries or report requests).
• Big meetings or meetings where you have to prepare documentation or submit proposals/presentations/papers in advance.

These are all things that we should know are happening or about to happen and then we can plan our time appropriately around that.

We find out about these things by staying curious, asking management, putting time aside to review the project schedule alone and with the team, and listening out for things that might be a problem. The more you spot coming, the more you can work around it, or into it so it can be handled at a time that suits you – not at the last minute creating a fire you have to run around and put out.

Reactive management

It’s much harder to manage time when you have to spend it reactively responding to whatever is dumped on your desk that day. It could be a project task that someone else was supposed to do but hasn’t, and just needs to be done, it could be new work to do with your project (like setting up a meeting with 10 attendees that has to be at a particular time but no one has calendar availability at that time… don’t ask me how I know!).

Other examples would be things like:

• A supplier letting you down and not delivering goods on the specified day.
• Someone being off sick and not being available to complete a task that’s on the critical path.
• A senior executive asks for an ad hoc report on project progress for a committee meeting that is tomorrow.

Building resilience in yourself and the team is a good way to manage the short-notice requests and feel more capable of responding in the moment.

In my experience, the better I am at proactively managing upcoming situations on my projects, the less reactive management I have to do – but I know it does not always work that way. Generally, though, the more you can anticipate senior leaders’ needs, complete your risk management actions, identify problems before they become a ‘real’ problem and so on, the less reactive fire-fighting you have to do.

Admittedly, you can’t necessarily foresee that the weather is going to cause problems, or that a supplier might have difficulties fulfilling orders, but if you have identified these are risks, you will at least have (hopefully) spent some time thinking about how they might be mitigated or addressed if they do happen.

Do you spend your time between proactive and reactive management – and is this distinction a helpful way to frame your work? It really works for me, but I don’t know if it’s a common way of thinking for other project managers. Let me know in the comments!

As much as we’d love to have everything working to plan, sometimes we can take some aspects of project management for granted. I wonder how many of these project challenges you have but you haven’t openly recognised within the team?

I don’t want you to have your head in the sand, so below I share 10 things that you might be missing on your project.

(I didn’t want to bury my actual head in the sand, so you got a photo of my feet buried instead! Not quite the same, I know.)

1. Stakeholders are reading your communications

We might believe that stakeholders are reading our project comms, but are they really?

It’s hard to tell, but if you aren’t seeing any action, or people are asking questions you have already answered in your comms, then they probably aren’t.

2. The training you’ve scheduled is enough

I expect it isn’t, even if it feels like it should be. People won’t turn up or won’t use the online training to teach themselves. Plan to have post-launch training support because your users will need it.

3. Your change management plans are adequate

Hopefully they are, but as above, there will always be someone who says they didn’t get the memo, or couldn’t access the materials. Make sure you’ve got post-launch training in the diary as well, and do more change management activity and engagement than you think you should have to.

4. The UAT plans are long enough

UAT is the one thing that gets squeezed in my experience. Add in an extra cycle if you can. It’s easy to take it out – not so easy to squash it back in if you do need more testing time.

This obviously depends on your project – if you are doing something you’ve done a lot before you should have a high degree of confidence in your deliverables, but you might need more if you are working on something new.

5. Risk identification has spotted everything

It hasn’t!

Make sure risks are constantly mentioned in all meetings, and that you are always listening out for what might be a new risk.

6. Team morale is OK

Team morale is something to keep an eye on. The team can get demoralised for the smallest of reasons, from a change not being approved to a reschedule for whatever reason. That negativity can spiral.

Even if things are going well on your project, events outside the project can influence morale, such as a change in leadership, redundancies, an increase in BAU work or pretty much anything else.

7. Benefits are understood

We’d like to think the financial and tangible benefits are understood, but how well have those assumptions been documented? I’ve worked on a couple of projects where we think we understand what we are tracking, only to find that we can’t replicate the exact formula the finance person (who has now left) used, or some other difficulty.

You should be able to answer straightforward benefits-related questions like ‘is this incremental revenue or total revenue’? So make sure you can.

8. There is no conflict in the team

There probably is, but people are too polite to mention it. You should dig for it! Some conflict is healthy so don’t worry about bringing it up.

9. Quality is being managed OK

Are you finding bugs in your deliverables? And more importantly, are you squashing bugs? What are your criteria for exiting testing and how does quality play into that? Ideally, you should have great quality measures, and be performing in line with those, but sometimes project teams get swept up in the desire to deliver and that means some lower-risk bugs are left in for now.

10. There is no technical debt

Are your project deliverables introducing technical debt? Are you breaking things elsewhere or for other teams, or introducing workarounds or degrading the solution for someone else? Sometimes your part of the world might be fine, but a process you’ve implemented ends up in many additional steps or a new report being needed for someone else.

Check that you aren’t creating technical debt by accident – if you know about it, document it and have created it ‘on purpose’ as part of a stepping stone to a different solution, then that’s probably fine.

Which of these might your project be at risk from? Let me know in the comments!

Are you working with a new project team? Here are some tips for getting your team past Storming and Norming and into the zone of Performing.

Use a shared language

Use vocab and process names that are meaningful within the team, and make sure everyone uses the same terminology.

Chances are, if your project team members have been around a while they will know the in-house language of projects. However, you might have some specific project language that everyone needs to be onboard with. For example, is it Phase 2, Stage 2 or Tranche 2?

Build and share experience

Do you know the background of your colleagues? Can you recall the projects they have worked on? Take the time to call out and share the experience you have collectively. Celebrate successes and give everyone the chance to shine.

What you’re trying to do is build respect and understanding for what people bring so you can shortcut some of the ‘I don’t know if she’s ever done that before’ worries that the team might have about each other.

Foster an environment where trust is the norm

I know that trust isn’t always something you should assume, but in the workplace, trust people to do their jobs until they show you otherwise. Don’t make them jump through hoops just to do the roles they are hired to do.

Actively create resilience

Create resilience in the team by promoting wellbeing activities and encouraging the team to collaborate. You can also take practical steps like making sure project team members have a deputy who can step in when they are off, and that there is resilience in the resourcing plan in that you have enough people to do the job.

Build resilience into your solutions too, so you aren’t trying to run a network on a single server.

Share lessons learned

Make it normal to share lessons learned across the team. When you’re still learning how things work in this new environment, it can speed up adopting new (successful) ways of working but it also takes a bit of vulnerability.

If that’s a problem, focus on sharing the ‘this worked well so we’ll do it again’ lessons and keep the ‘what didn’t work’ conversations to your one-on-one chats.

Manage anxiety

Being in a new team is anxiety-provoking. Will they like us, what will they think of the way I do my work? Focus on psychological safety and setting expectations that are reasonable and manageable – for example, not expecting overtime, not emailing them on the weekends and giving people enough time to do tasks before you chase them.

Live the vision

Finally, make sure the team is aware of the common vision for the project. Talk about your hopes for the future and the goals you want to achieve together. OK, it takes more than a quick chat in a team meeting to create a genuine sense of wanting to work together to achieve a goal, but it sets the tone and gives people an understanding of the ‘why’ behind the project.

Tie your decisions back to the vision, reference it often and challenge activities that don’t lead you closer to it.

You can’t magically get to a performing team overnight, but these activities will help you start off on the right path so you reach a good standard of project performance together as quickly as possible.

In my early days as a project manager, my business cases and PIDs were full of non-quantifiable benefits. The kind of improvements that I thought we could get but weren’t set up to track.

In my more recent years, I’ve been heavily focused on quantifiable benefits, most specifically the money-related ones. Anything that presents a trackable, cash improvement is something to focus on. If it improves the bottom line, managers want to know about it.

There are also quantifiable benefits that are harder to track like reducing cycle time for invoicing and reducing energy consumption. These would lead to financial savings, but they are more difficult to pin down and measure realistically with no other influencing factors. Cycle time, for example, may lead to bills being paid faster which would lead to better cash flow and increased bank interest, but how do you separate that out as a benefit of just this project and not something to be attributed to one of the many other projects that are doing their bit for continuous process improvement?

Energy consumption can be tracked, but it’s several steps and calculations – it’s doable but harder. That’s not to say we shouldn’t do it, but it is something that you have to put effort into tracking.

Non-quantifiable benefits seem to have dropped out of favour. For example, staff satisfaction survey results is a good one that I used to mention a lot in project documentation. However, there are lots of things that influence staff satisfaction, and I’m sure my projects only played a very small part in influencing the results one way or another.

Also, new initiatives that once seemed completely life changing and a huge improvement quickly become ‘the way things work around here’ and the benefit tails off to nothing. No one would want to go back to the old process, but equally no one is celebrating the new process 6 months later when it’s just normal BAU.

I learned this on a Six Sigma course I took many years ago where the instructor talked about giving customers a biscuit with their coffee in a coffee shop. At first customers were excited they were getting a biscuit for free, but over time they came to expect that service and were disappointed when they didn’t get it, but not more happy because they did.

Therefore there is a balance to be struck with benefits: you want a mix of both quantifiable (financial and other) and non-quantifiable. But not so many that they all become meaningless. And not so few because you can’t be bothered to put the tracking mechanisms in place for more.

Be realistic about what you can achieve with benefits and how much time people really are going to spend on tracking the more difficult ones. If they believe that it’s worth tracking, they’ll do it, but if they feel energy consumption, for example, is tracked adequately through other types of environmental reporting or projects, they probably won’t be falling over themselves to create project-specific benefits reporting.

Talk to the key stakeholders about what sort of benefits you are putting forward for a project and make sure they are reasonable, measurable (where possible) and realistic.