The Money Files

Psychological safety, as I think of it, is the way that you show up at work and how much risk you feel yourself in when expressing your opinions or when choosing a course of action.

If it feels ‘safe’ you’ll speak up when things are wrong, suggest new ideas and call out bad behaviour. If it doesn’t feel safe, you’ll keep your head down.

On a project team, psychological safety is important because you want people to challenge poor ideas or speak up when they see a better way of doing things. And also because we are nice leaders and we want people to be happy at work, without second-guessing what their boss is going to think all the time.

In an environment where psychological safety is present, people feel that it is safe to take risks. They might try a new solution or propose a new way of working. They might come up with an idea and implement it, or opt for a new technology over a proven one because it might be better.

They also feel that it is safe to speak up and express ideas. They’ll speak in meetings, bounce ideas around, build on other people’s ideas and say when they don’t think an idea will work.

The benefits are clear.

You will see better team collaboration. People will be more creative and prepared to innovate. You should end up with better problem-solving and decision-making. And it will feel like a nice place to work surrounded by professional adults.

How do you know if you’ve got psychological safety in the team?

It’s probably easier to look at what the environment looks like if you don’t have psychological safety.

You’ll see:

• Lack of participation in meetings.
• Fear of retribution
• Fear of embarrassment.

People might not say out loud: I was too embarrassed to say what I thought, but you might pick up on it either through one-to-one conversations or body language.

If you want to find out more, you could survey the team or use other feedback methods, but if the environment doesn’t feel like one where you can speak freely, frankly I don’t think you’ll get a lot of good out of those methods. It is probably best to build good relationships with some of the people who exhibit more confidence or who contribute the most and talk to them openly about your worries for the team.

The trouble with projects is that they happen inside the culture of the organisation, so while you might want to create an environment where people feel safe, if the rest of the organisation isn’t backing you up, that can be tricky.

How to create a safer environment

In your leadership role, you can model vulnerability and openness. Share what you’re comfortable sharing. Lead by example. Be consistent in your actions and expectations and demonstrate the behaviours you want to see.

Encourage and reward contributions. Let people know you appreciate their ideas even if you don’t end up using them.

Value diverse perspectives. Ask for them, incorporate them and let people know that their voices are being heard. Again, if they share their perspective and you can’t do anything with it or affect any change, at least pass that back to them.

A lot of what you can do centres on establishing norms for respectful communication. For example, regularly ask for feedback, through anonymous suggestion methods if necessary (and people are wary of Microsoft forms not being truly anonymous). Handle conflict early when you spot it, and look out for those people who are showing signs of being resistant to change and support them.

Schedule some team-building activities, but not awkward cringey ones, things that the team actually will be interested in doing.

Over time, hopefully you’ll see that the feeling in the team has changed. I think it’s a hard thing to measure, but you might see results through employee surveys, perhaps in responses to do with belonging, or feeling understood/appreciated etc.

What’s more evident is that you’ll probably feel it. You can observe the team dynamics and notice what is different. However, you don’t want to lose that and slip back into old ways, so keep psychological safety on the agenda. Ask people how they feel about working in the team now, and what else you could do together to encourage good working practices. Then act on their suggestions.

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.

Who do you consult when a project gets going? Or when you want to put forward an idea for a new project but need to run it past some key stakeholders?

One issue I had on a project recently was that we didn’t involve our IT subject matter expert early enough. While that didn’t slow down the project, it did mean we’d made extra work for them, which isn’t kind, and I’m sure they felt like an afterthought, which is not the relationship I want to have with my stakeholders.

So learning from that, here are some of the key stakeholder groups and subject matter expert teams that you should be talking to at the beginning of a new piece of work.

IT

Let’s put them first! Talk to your technical colleagues to find out if they can advise on the best solution.

Operations

Operations are the group that keep the organisation working, so they run the day to day functions of your business. The teams are going to be different depending on what your business does, but they will know whether your project is going to have an impact on frontline staff and the operators.

Finance

Talk to your finance team to find out whether there are any special requirements for this kind of project. For example, what are the funding options, how will financial benefits be tracked, whether contingency or management reserves are available and whether there will be a finance analyst available to support the work.

They might be able to give you and idea of what budget is available in the portfolio which will help you scale the work.

PMO

Talk to the PMO about resourcing, scheduling and estimating and securing project resource. Generally, in my experience if you are the project manager involved at the start of a discovery or concept phase, then you’ll also be the one that carries on leading the work as it moves forward. But not always, so make sure if you need project support that you’ve got a PM and/or analyst assigned to the work and that they understand what is expected.

Finally, don’t forget to include the senior leadership in your consultation. As a key stakeholder, they’ve got the power to say they don’t want the work to go ahead after all because something has changed. Equally, having their support for projects that are moving is invaluable because they’ll be able to support and champion from the top.

Legal, compliance and data protection

I’ve bundled legal, compliance and data protection into one group but you probably have separate teams responsible for each function. Talk to each of the departments to make sure that your project is viable and meets with all the required regulations and policies.

Communications

If you have an internal comms team, talk to them about the project and what support you can expect from them. For example, they might be able to help with drafting project newsletters and briefings, and creating slides to share at leadership meetings.

HR

If your project affects people’s jobs in any way, consult with your Human Resources team. There might need to be consideration given to job descriptions, recruitment, the onboarding and induction process, training and more. HR-related changes can take some time so it’s worth getting them involved early.

Specialist teams

If your project involves manufacturing, talk to them. If you need engineers, get input from them. If you have a big marketing expectation, bring the marketeers onboard at this point and get their thoughts. Work out what specialist subject matter expert teams are relevant to your work and include them.

What other teams would you include by default? I’m sure there are some I’ve forgotten!

Making a recommendation? Whether you’re doing a formal business case or a quick paper for your boss, here are 5 things that you should make sure are covered.

1. Present the options

What are the options you have considered before making your recommendation? Normally you’ll have at least 3:

• Do nothing (what happens if nothing happens – if your project is legal or regulatory you might not have a do nothing option)
• Do something (minimum intervention)
• Do more than the minimum.

Write a few sentences about each, or if you are doing a verbal presentation, spend a moment outlining each.

The option chosen should be practical and deliverable. In fact, all the options should be reasonable – suggesting pointless activity is a waste of time and undermines your credibility. There’s no point putting forward an option to deliver 100% improved customer service if it needs an investment of £2m and you know there is no way your company is going to go for that.

2. Present the choice

Next, say which one of your reasonable options you are putting forward.

Explain why. Be clear and don’t assume they know anything about any of the analysis or thinking. What’s the obvious choice to you might not be clear to them.

Explain why the other choices are not appropriate to pursue at this time. You don’t want to spend loads of time on explaining why you have discounted them, but you might need to justify the financials so link out to (or have to hand if you are presenting) info that stakeholders can use to look at the detail.

Hopefully they won’t need it as they should trust that you’ve consulted the right people and made a sensible choice.

3. Present the benefits

Review the benefits that come with the chosen option and make sure you can justify them. Are they clear, measurable and reasonable? Are there benefits that look good on paper associated with the rejected options that you should explain? Normally, business leaders go for the ‘biggest benefit’ choice so if you aren’t selecting that one, be sure you have clearly justified why not.

Don’t over-estimate the benefits because of all the sections in this presentation or paper, the benefits are the thing most managers will remember. They’ll be looking to you to deliver those, so I would recommend being on the cautious side!

4. Check the language

The decision might go up the chain to people who don’t know the jargon of your department. Check through your proposal or presentation script and make sure you’ve explained any acronyms or project-related terminology that other people might not understand – or that they might interpret incorrectly.

Get someone else to read it through if you are worried that you’re so in the detail that you won’t be able to pick out terms that someone else can’t understand.

5. Read through your recommendation again

If you were presenting this to a family member or non-project manager friend, would they understand your justification for the choice? It should be clear that you have chosen the obvious winner and that you can explain why that is the most appropriate choice at this time for your business. If there is any doubt, go through and strengthen the language.

Finally, check for spelling and grammar errors, and make sure that people’s names and job titles are spelled correctly. Circulate the paper for comment amongst your subject matter experts if it is something you need to get input on, and then send it off to your boss or whoever needs to see it.

The decision maker might not agree with you, but you can be sure they’ve seen the best possible justification and case for the choice.