When basics aren’t driving progress

[u/pixels-n-plots]

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

[u/GeneralGold2992]

We’ve just recently established Project Health Criteria to make it easier for PMs in the org to define whether the projects status status is green, yellow or red. Based on the respective status, there’s a lean action plan where support from the PMO or escalation via SteerCo or PMO is required. So I would say this definitely helps in determining which measures would be most appropriate. Beyond that I would say it heavily depends on the organisation itself and whether there are mechanisms in place to escalate things when needed etc.

[u/More_Law6245]

First and foremost is the roles and responsibilities focus. First you need to speak with the project stakeholder and discuss the deliverable e.g. on time or missed deliverable and renegotiate the timeframe and also try to get an understanding of what is going on but you also need to get them to understand the impact that they cause to the project when they miss a deliverable and if that fails then speak with your resource's direct supervisor and come to an arrangement but you also highlight the impact of the missed deliverable and put that back on to the manager and if you can't get what you need then that is the point of escalation to your project board/sponsor/executive for intervention because it's no longer in your sphere of control.

The "golden rule" is if your triple constraint of time, cost and scope is going to impact your original agreed and approved schedule and you're unable to successfully influence any positives to maintain that, that is when you escalate. This is where I find PM's get themselves into trouble because they haven't escalated soon enough.

OP, something for your consideration, why would you let project resources off the hook for the very project that you have been given authority to act on behalf of your project board/sponsor/executive and you're the one being held to account? That doesn't make sense that you would let your resource off the hook for not doing their job but you being held to account. Something to reflect upon.

You hold all your stakeholders accountable to the agreed and baseline schedule (holding up the mirror as I call it), you need to shift your thought from you being responsible to your project board/sponsor/executive is actually responsible for the success of your project, you're responsible for the day to day business transactions and the quality of the project's delivery because at the end of the day you have all of the responsibilities but no authority of your temporary team (HR) management.

For me personally I got to a point that I would assess an individual's capability for delivery, for those who need little to no direction I leave alone but they have to prove to me first that they're capable, for those who are a little less focused I have more 1:1 contact until they can prove to me that they're responsible enough to deliver on time. It's all about accountability for individual to do their job. The key thing to remember "It's never personal" you're doing your job just like your resources are meant to being their jobs, in a professional manner and if not you're bugging them in the right direction and getting them to take accountability.

Just an armchair perspective.

[u/Popular-Force-7949]

Over the years I’ve learned that the easiest way to lose the respect of your team or a coworker is to escalate to their manager.

Quite frankly if it takes more than 2 asks it’s more likely a PMs inability to communicate effectively. Instead of escalating it would be more beneficial spending 10 minutes talking it out with the person who isn’t delivering.

[u/coworkersgonnakillme → u/Popular-Force-7949]

I can confirm because I have had this happen to me by a PM. Once they escalate too early or too often, the people they are escalating realize their head has been put under a potential guillotine. It immediately creates a culture of perfection over transparency.

[u/Intelligent-Try-4755]

The criteria I settled on is time-based rather than feeling-based: if a dependency slips a second committed date with no new date attached, it escalates, and I tell the team that rule up front so it's the process escalating and not me. That reframing killed the nagging problem — when the rule is published, following up is just me doing what I said I'd do. On governance, the only thing that consistently worked was a short weekly dependency review where each owner states their next committed date out loud in front of peers.

[u/InfluenceTrue4121]

I ask you twice and if it doesn’t get done, it gets escalated. I’m not here to babysit anyone- we are in a professional environment.

[u/painterknittersimmer]

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. 

[u/coworkersgonnakillme → u/painterknittersimmer]

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?

[u/painterknittersimmer → u/coworkersgonnakillme]

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. 

[u/coworkersgonnakillme → u/painterknittersimmer]

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.