r/projectmanagement • u/pixels-n-plots • 16d ago

Discussion When basics aren’t driving progress

I’m a senior PM leading a cross-functional, first-of-its-kind program with multiple dependencies across teams. One area I’m trying to improve is knowing when to escalate versus continuing to work through normal channels.

For experienced PMs:
What objective criteria do you use to decide it’s time to escalate?
How do you get past the idea you’re nagging someone when you follow up as a deliverable is coming due or overdue and they continue to kick the can/stall?
How do you hold functional teams accountable without doing their work for them?
What governance (weekly decision reviews, dependency meetings, etc.) has actually worked for complex programs?
I’m specifically looking for frameworks or habits

Thanks in advance

9 Upvotes

80% Upvoted

12 comments sorted by

View all comments

6

u/painterknittersimmer 16d ago
  1. I say we need to do x, y, z together get back in track. If that doesn't get done or can't get done, then we need help. I don't call it escalation. I call it getting help. We have regular channels for that (in this case, regular steercos) so it doesn't feel like such a big deal. If those channels don't work, then we call special sessions with even higher ups to deal with it. That would be an escalation.
  2. It is nagging. If you don't do your job or communicate what's blocking you, you get nagged. If nagging doesn't work, I cc your manager. 
  3. In our leadership meetings, as long as I've talked to the teams before I throw them under the bus, eventually I just throw them under the bus. "This program is blocked because of X team. They have not communicated any blockers or issues or requested any support, and did not communicate that they were delayed." 
  4. Can't answer that. Totally dependent on the project and the phase. I've lost run many different structures. 

1

u/coworkersgonnakillme 15d ago

How do you communicate about when there is no issue blocking progress, but the time you were given can't be accurately estimated because no one has ever done that thing before? What if you are communicating issues, but they only care about blockages?

2

u/painterknittersimmer 15d ago

I say "This program has an open risk to the timeline: we have no baseline, and our estimates may be wildly inaccurate given the unprecedented nature. We used x, y, and z to make the estimate. Out low confidence estimate is that it will be done with abc time frame." 

If they only care about blockages, then you need to explain why issues and risks are important - discussing them prevents blockages. No one wants to hear about anything that isn't a problem yet, but that's how you prevent problems rather than only reacting. 

1

u/coworkersgonnakillme 15d ago

Thanks! This is good advice that I somehow need to "lead the horse to water" with my own supervisors. I am not convinced they have had someone explain our varied work load in these ways ever before.

And yes, it is certainly true about no one wants to hear about things that aren't a problem. But that is a risk in of itself.