Trust Issues, Problem Solving, and Stakeholder Expectations

Ever wondered what I’d say about your real-world issue?

It’s that time again - reader Q&A.

Readers send in questions every week, and I’m always happy to share my thoughts on your issue. Sometimes, a question is such a common theme that I’d rather share my answer in public - sharing is caring, right?

Here are the two best questions from last month’s mailbag:

Trust issues in your team

A couple of weeks ago, a reader sent in a question that we’ve all seen:

This is a common issue, and one that all teams deal with. From the team at your local coffee shop to special forces and elite sports. The issue is complex, but ultimately boils down to a lack of trust and perceived safety.

Here are the two things I’d try first in his situation:

But before we dive in, I have an announcement to make!

The new course, Project Management Unraveled launches next week. It’s a short and practical course for busy people like you, who want to lead successful projects with confidence.

You’ll learn the first principles behind great project management and how to apply them with ease in your own projects. You’ll understand how to troubleshoot any project issue (before it becomes a real problem!) - no matter the PM tool or method you use.

The first 100 participants get exclusive access to a live Q&A after the launch.

Sign up for the waitlist here and be the first to know when we’re live!

Create a culture of psychological safety

Psychological safety is the feeling of being able to take risks and be vulnerable in front of your team members. It’s essential for effective communication and collaboration. When people feel safe, they’re more likely to admit mistakes, share ideas, and give feedback.

Easier said than done, though. It’s one thing to tell people that “this is a safe space” or that “we blame problems, not people”. It’s an entirely different thing to make them feel that way. Here are a few ideas:

1. Lead by example. Show your team that it’s OK to make mistakes and to learn from them. Own your mistakes in public, and ask for feedback often. If you don’t do it, you can’t expect it from your team either.

2. Celebrate failure. This sounds crazy, but hear me out. Failure is part of the learning process. When something goes wrong, that means you can learn from the experience and move forward. Never cover it up.

3. Reward risk-taking. When team members take risks and try new things, be sure to recognize and reward their effort - even if it didn’t work out.

4. Provide perspective. If you’ve been reading this newsletter for a hot minute, you know I’m always hammering on knowing your project’s purpose. If you do, it’s easy to provide perspective. Yes, this went wrong, but in the grand scheme of things…

This is just a starting point. Creating a culture where it’s normal to share mistakes and learn from them takes time and effort, but it’s well worth it.

Introduce a structured process for solving issues

When you find an issue, what do you do? Most of us switch straight into firefighting mode. This might solve the issue, but it overwhelms people in the process and creates collateral damage.

If you introduce a structured process for problem-solving with your team, you do a few things:

• People know what’s about to happen, which puts them at ease

• It ensures that you look at the issue calmly, fair, and objective

• Every team member has a chance to be heard

Sounds like an overkill? Trust me, structured problem-solving is one of the most underrated skills for a project manager. And once you get good at it, it becomes a game for the team.

Imagine how that would shift the conversation in case of an issue!

I’ve tried loads of different problem-solving approaches. My favorite one by far is one I learned while running a big strategy transformation program with McKinsey. Curious? Here’s their 7-step problem-solving framework explained!

Project aims and stakeholder expectations

Last week, a reader shared a conflict with her stakeholders when defining her projects:

This is a tricky one without knowing exactly what they think the definition of an aim is, but I’ll make a few assumptions.

First off, you don’t do a project to create a deliverable. You do it to solve a problem or capture an opportunity. Your plan describes this as part of your project’s purpose. Having a conversation about the deeper purpose of the project may shift the conversation with your stakeholders.

Secondly, your research will probably shift the project’s direction along the way. This is not failure, this is scope discovery (like we discussed last week).

Make sure that you start with a clear (mutual) understanding of where the limits of your project are, and then explore the contents within. You discover details on the map as you go, not entire new continents.

Third, we might be dealing with a case of executive scoping here. A good project sponsor spends time on what & why should be solved and then leaves the what over to a capable team.

The more a sponsor knows about the content, the harder it is to let go. If this is the case, it might be worth having a conversation about roles within the project before you dive into the content.

Finally, your aim could be an early project deliverable. If this is “not done” in your industry, you can turn it into a separate project too. This is done in many different scenarios: use 10% of the resources to define how to best use the other 90%.

That’ll do for this week! Have a question you’d like my take on? Hit reply and ask me anything. You always get an answer from me personally, this is a one-man band.

Cheers,
Jasper