Today, my boss assigned me a task: to help a PM bring a troubled project back into order.

The project has been struggling for some time. Engineers have been raising concerns, frustrations have been building, and doubts about the company’s PM capability have gradually started to surface.

Since I used to be this PM’s manager, I was asked to step in and provide support.

I believe many managers or senior PMs have had similar experiences, being asked to help when a project is already in trouble.

In the past, when I received this kind of assignment, my natural reaction was to jump right in, work alongside the team, and sometimes even take over parts of the project myself.

But after I became the manager of a PM team, I started to look back at those situations from a different perspective. I realized that this was not always the right way to help.

That kind of support may unintentionally take away the PM’s opportunity to grow. It can also turn the senior person into a permanent firefighter.

Even worse, the person being helped may not feel supported at all. Instead, they may feel judged or replaced.

And that creates the opposite effect.

Sometimes, when a PM is struggling with a project, it does not necessarily mean they are incapable or irresponsible.

Sometimes, they simply need help.

There is a common saying in the industry:

“PMs are responsible for the success or failure of a project.”

Some even call this the original sin of being a PM.

I believe many PMs hate this saying.

The problem is that this mindset can easily trap PMs in a dead end where they are held accountable for everything, especially when a project starts to go wrong.

I have been there. I know that when this happens, what a PM often needs most is not blame.

They need support.

So when I was given this assignment again this morning, my first thought was:

“From what angle should I step in?”

How can I help this PM find a path through the chaos, regain clarity, and get the project back on track on their own?

Only when the PM finds direction on their own can they regain momentum and confidence.

Otherwise, they are just being rescued once again.

So I thought: maybe the starting point should be to “make the uncertain issues visible”.

Recently, I have written several posts about clarifying requirements and uncovering hidden assumptions. The underlying principle is actually the same.

Whether we use the traditional 5W1H approach or ask AI to help perform a deeper scan, the tool itself is not the point.

The key is the angle of intervention.

I would not begin by asking:

“Why are the specifications still not ready?”

“Why are the engineers already complaining?”

“Why is the project stuck again?”

These questions may be valid, but they can easily put the PM into a defensive position.

Instead, I would probably sit down with the PM and help break the situation into three categories:

First, what is already confirmed and can move forward?

Second, what is still unclear, but can be framed as assumptions, options, and possible impacts?

Third, what issues will clearly affect schedule, cost, or quality if the client does not make a decision soon?

In many projects, the scariest thing is not that problems exist.

The scariest thing is that everyone feels there are problems, but no one has organized them into a form that can be discussed, decided, and tracked.

For me, when a senior person steps into this kind of project, the most important thing is not to prove they can manage it better than the original PM.

The real value is helping the PM bring uncertainty out of the chaos and turn “everything is a mess” into “a few decision points we can manage.”

Because only when uncertainty becomes visible can the team realign.

And only when the PM regains control of the direction by themselves are they not merely rescued again.

They are actually growing through the project.

What would you do if you were in this position? 

#ProjectManagement #PM #MakingUncertaintyVisible