Project Manager’s Dilemma: Get People to Commit When They Don’t Report to You?

The real leadership challenge in project management is not getting people to attend the meeting. It is getting them to own what needs to happen after the meeting.

One of the easiest things to do as a manager is to get something done when the person doing it reports directly to you. You assign the work. You set the expectation. You establish the deadline. If there is a problem, you intervene through the normal management chain.

The dynamics change completely when you are managing a project, programme or cross-functional initiative.

The person you need something from may report to the CFO, while you report to the COO. The technology lead may have a completely different set of priorities. The functional head may support your project but have ten other business priorities competing for the same people. Your vendor may have contractual obligations, but the individual you need to work with has no direct relationship with you at all.

Yet the project still expects you to deliver.

This is one of the fundamental realities of project management:

You can be accountable for the outcome without having authority over the people who have to create it.

And that creates a peculiar leadership problem.

People rarely tell you “no.”

Instead, they say:

“Yes, we should be able to do that.”

“Let me check internally.”

“We’ll try to get it done.”

“I’ll come back to you.”

“We are aligned.”

Everyone leaves the meeting feeling positive.

Then the deadline arrives.

The deliverable is not ready.

The person you were depending on is dealing with something else.

The priority has changed.

Someone assumed somebody else was doing it.

Or, perhaps most frustratingly, nobody actually disagreed with you. They simply never committed.

This is where influence without authority becomes real.

It isn’t about persuading people to like your project. It isn’t about becoming exceptionally charismatic. And it certainly isn’t about finding increasingly clever ways to chase people.

It is about creating the conditions in which people understand the objective, see why their contribution matters, participate in shaping the commitment, and take genuine ownership of delivering it.

That is a very different form of leadership.


There is an important difference between compliance and commitment.

Compliance sounds like:

“My manager asked me to do it, so I’ll do it.”

Commitment sounds like:

“I understand why this matters, I know what I am responsible for, and I am prepared to make it happen.”

The distinction is easy to miss when everything is going well.

If someone reports directly to you, compliance may be enough for many routine tasks. There is an established relationship between authority, accountability and consequences.

Projects don’t always have that luxury.

Imagine that your project needs a critical data extract from the Finance team by Friday.

You can ask the Finance manager.

They can agree.

But the analyst actually doing the work may have been given an urgent month-end assignment by their functional manager.

Your project is important.

Their month-end responsibility is also important.

Nobody is necessarily being difficult.

You simply have two competing systems of priority.

This is why escalating every missed commitment eventually becomes counterproductive.

You can escalate once.

You can escalate twice.

Eventually, people learn that the project manager’s primary mechanism for getting things done is escalation.

That creates a very transactional relationship.

The better approach is to build commitment before the work becomes a problem.

And that begins with understanding what matters to the other person.

One of the most common mistakes project managers make is explaining the importance of the project without explaining why this particular person should care about it.

We talk about the project objective, deadline, steering committee, sponsor’s expectations.

But the person sitting across the table is thinking: “Why is this my priority?”

That question doesn’t make them selfish. They are managing their own responsibilities. The project may be one of ten things competing for their attention.

This is where the simple idea of WIIFM — What’s In It For Me? becomes useful. But “what’s in it for me?” doesn’t necessarily mean personal benefit. It can mean:

  • Which business problem does this solve for my team?
  • Which of my targets does this support?
  • Which pain point does this remove?
  • What risk does this help me avoid?
  • What capacity does this create?
  • What customer problem does this address?
  • What will become easier for my team once this is done?

Suppose you are implementing a new customer-service platform.

The project team sees the objective as:

Implement the platform by September.

The Operations team may see it differently:

Reduce manual intervention and improve service productivity.

IT may care about:

Replacing an ageing platform and reducing technical support overhead.

Customer Service may care about:

Giving agents better information when dealing with customers.

Finance may care about:

Reducing the cost-to-serve.

These aren’t competing stories.

They are different connections to the same project.

If you only communicate the project objective, you are asking people to work for your project.

If you connect the project to something they already care about, you are helping them see why the project matters to their work.

That changes the conversation.

Instead of:

“I need your team to complete this by Friday.”

Try:

“If we can get this data structure agreed this week, Operations can start testing the new workflow next month. That should remove the manual reconciliation your team is currently doing every week. What would your team need from us to make Friday realistic?”

You aren’t simply requesting effort. You are connecting effort to value.

Before asking someone for a significant commitment, answer these three questions:

What matters to them?

How does this project affect it?

Can I explain that connection in one or two sentences?

If you can’t, you may be asking for commitment before creating relevance.


Another common pattern in projects is the handoff.

The project manager develops the plan and then takes it to the functional team. Then says:

“Here is what we need from you.”

This feels efficient but is also one of the easiest ways to create weak commitment.

People are much more likely to own something they have had a role in shaping. That doesn’t mean every decision needs to become a committee discussion. It means involving the people who will carry the commitment before the commitment is finalized.

Suppose you believe a particular deliverable can be completed in two weeks.

You could announce:

“We need this by the 15th.”

Or you could ask:

“We need this completed around the 15th because it feeds the next stage of testing. Looking at your current workload, what would need to be true for us to make that date?”

The second question allows the person closest to the work to challenge the assumption.

Maybe two weeks is realistic. Maybe it isn’t. Maybe three weeks is needed. Maybe an additional resource would make two weeks possible. Maybe another activity needs to move.

Now you are negotiating reality rather than negotiating compliance.

This is where co-creation becomes powerful.

Instead of:

“Here is the plan. Please execute it.”

you move towards:

“Here is what we need to achieve. How do we make the commitment workable?”

That creates psychological ownership. It also exposes constraints much earlier. When people participate in building the plan, they have fewer opportunities later to say:

“That was never realistic.”

They had a voice in defining what realistic meant.


Influence without authority does not mean asking everyone for their opinion about everything. Co-creation should be selective. Involve people deeply when:

  • they own a critical dependency
  • they have specialist knowledge
  • the commitment materially affects their team
  • they control a resource you need
  • their support is essential to implementation

For routine matters, make the decision and communicate it clearly. Good influence requires knowing where collaboration adds value and where clarity matters more than consensus.

Influence is built over time.

A project manager who only contacts a functional leader when something is late will eventually become associated with problems and escalation. A project manager who regularly understands that leader’s priorities, helps remove obstacles and keeps commitments reliable builds something much more valuable: Social Capital.

You have credibility because people know how you operate.

  • They know you don’t create artificial urgency.
  • They know that when you say something is important, there is a reason.
  • They know you will support them when they need something from the project.
  • They know you won’t publicly embarrass them when something goes wrong.
  • They also know that you will not quietly allow commitments to disappear.

Trust isn’t the absence of accountability. In fact, strong working relationships make accountability easier.

When a commitment is important, make it visible as a mechanism for creating a shared view of the project. Instead of sending five private reminders:

“Just checking on this.”

“Any update?”

“Can you please confirm?”

“Following up again.”

Use a shared milestone or action tracker where the commitment is clear:

Article content

The project isn’t saying: “Why haven’t you done your task?”

It is saying: “This dependency is becoming a constraint for the next stage. What do we need to do?”

Transparency should create shared accountability, not public punishment.


This sounds simple, but it is one of the most practical skills a project manager can develop.

Compare these two requests.

“Can you help us with the data?”

And:

“Can we confirm that Priya will own the data validation and have the validated file ready by 15 October? It is needed to start the configuration work on 17 October. If that date isn’t workable, let’s identify the constraint now and agree an alternative.”

The second request is dramatically better because it establishes:

What: Data validation

Who: Priya

When: 15 October

Why: Configuration starts on 17 October

What if not: Surface the constraint and agree an alternative

This is what I call a commitment-quality ask. A good ask should answer five questions:

  • What needs to be done?
  • Who owns it?
  • By when?
  • Why does it matter?
  • What could prevent it?

Invite the constraint into the conversation before it becomes a missed commitment.


Of course, none of this means everyone will agree. Sometimes someone will simply say:

“We can’t do it.”

This is where many project managers make one of two mistakes.

They either immediately escalate.

Or they start negotiating against themselves.

“Okay, what about Monday?”

“Could you at least give me half of it?”

“What if we get someone else to help?”

The conversation becomes a negotiation before you understand the reason for the resistance.

Instead, slow down.

Ask:

“Help me understand what’s preventing you from committing.”

Don’t challenge the answer immediately.

You need to know whether the problem is:

  • capacity
  • capability
  • priority
  • dependency
  • unclear requirement
  • lack of authority
  • timing
  • risk
  • disagreement with the approach

These are different problems. They need different solutions.

Suppose someone says:

“My team doesn’t have capacity.”

Don’t respond with:

“But this is a critical project.”

You haven’t solved anything.

Instead:

“Understood. If capacity is the constraint, what would need to move for this to become possible?”

Now you have turned a rejection into a prioritisation discussion.

Perhaps there are three:

  • move the date
  • add capacity
  • reduce scope

Now you have something to manage.

This is particularly important with senior stakeholders.

“We can keep the 15 October date, but we will need two additional resources.”

Or:

“We can stay within the existing capacity, but the date moves to 25 October.”

The project manager isn’t forcing the answer. The project manager is making the trade-off visible.

Don’t leave the conversation with:

“We’ll figure it out.”

Close with something concrete:

“So we’re agreeing that the date moves to 25 October, and I’ll update the downstream plan accordingly.”

Or:

“We’re keeping 15 October, and Finance will reallocate two analysts.”

That is commitment.


This is arguably more difficult than a direct “no.”

You ask:

“Can you have this by Friday?”

And the answer is:

“Yes, we’ll try.”

Be careful.

“We’ll try” is not a commitment.

Neither is:

“We should be able to.”

“I’ll see what I can do.”

“Let me check.”

These statements may be perfectly reasonable during an early conversation. But before you put them into the project plan as commitments, close the gap.

Try:

“I appreciate that. What would you need to confirm before you can commit to Friday?”

Or:

“Would you be comfortable with us putting Friday down as the working commitment, subject to X?”

Or:

“What confidence would you put on Friday — and what is the biggest thing that could move it?”

You are not trying to force a “yes”. Rather, You are trying to distinguish agreement in principle from a genuine commitment. And this can save a project a lot of pain.


This is probably the most common reason commitments fail. The functional leader says:

“This project is important.”

But then gives their best people three other priorities. From the project manager’s perspective, this can feel like resistance. Sometimes it isn’t. Sometimes the organisation simply hasn’t made the priority trade-off explicit. This is where project managers need to stop asking individuals to solve an organisational prioritisation problem.

Suppose a key resource has two commitments:

Business-as-usual work: 60%

Project: 40%

The project manager wants 70%.

The functional manager wants 80% for BAU.

There is no amount of persuasion that will make the mathematics work.

So instead of saying:

“I need more of their time.”

frame the decision:

“We need 60% of Priya’s capacity for the project between 1 and 15 October to protect the testing milestone. Her current allocation is 30%. If we keep the current allocation, the milestone is likely to move by approximately two weeks. Can we agree which priority takes precedence?”

That is a management conversation. You are not escalating a person. You are escalating a trade-off. One of the most important shifts a project manager can make – Don’t escalate people. Escalate decisions.


There is a reason some project managers seem to get extraordinary cooperation from people while others spend their lives chasing actions. It isn’t simply personality.

Over time, project managers build a reputation. People learn:

  • Does this person understand the business?
  • Do they understand my constraints?
  • Do they keep their word?
  • Do they come prepared?
  • Do they waste my time?
  • Do they make reasonable requests?
  • Do they help solve problems?
  • Do they give credit?
  • Do they deal fairly with difficult situations?
  • Do they escalate responsibly?
  • Do they create clarity or bureaucracy?

I believe this reputation becomes a form of influence and thus the real currency is not authority, it is credibility.

Credibility creates trust. Trust makes difficult conversations possible. Difficult conversations create clarity. Clarity creates commitment. And, commitment creates movement.

There is no shortcut around that sequence.


Another misconception that is worth addressing is that some people interpret “influence without authority” as: “I need to be diplomatic all the time.”

Not really.

Influence requires the ability to have difficult conversations without making them personal.

Sometimes you have to say:

“You committed to this date, and we are now three days away. What has changed?”

Or:

“We have agreed this dependency three times, but it hasn’t moved. What is actually preventing it?”

Or:

“If this is no longer a priority, that’s okay, but we need to make that decision explicit because the downstream work is affected.”

Or even:

“I don’t think we have a genuine commitment yet. What would need to change for you to make one?”

You are not accusing anyone. You are refusing to confuse polite agreement with ownership.


Before walking into an important cross-functional meeting, I would suggest asking yourself five questions.

Not “support.”

Not “alignment.”

Not “help.”

What specifically needs to happen?

What does this solve for their team, their customer, their KPI or their business priority?

If not, am I asking them to execute a plan they never had a role in creating?

Capacity? Priority? Capability? Decision? Dependency? Risk?

Do I know for sure or am I assuming?

A person. A deliverable. A date. A condition. A decision.

If those five things are clear, the conversation becomes much easier.


  • Do connect the project to their priorities.
  • Do involve people before finalising commitments that materially affect them.
  • Do ask for specific commitments.
  • Do surface constraints early.
  • Do make dependencies visible.
  • Do escalate trade-offs and decisions, not people.
  • Do protect relationships while maintaining accountability.
  • Don’t confuse agreement with commitment.
  • Don’t rely on repeated reminders as your primary management mechanism.
  • Don’t assume that because the sponsor says something is a priority, everyone else has the same priority.
  • Don’t publicly embarrass people to create accountability.
  • Don’t escalate before understanding the constraint.
  • Don’t make every conversation about the project.
  • Don’t be afraid to ask for a real commitment.

The project manager’s job is often described as coordinating people. I think that undersells what is actually happening. In a complex project, people are making dozens of choices every day about where to spend their time, which problem to solve first, which meeting to attend, which request to respond to and which commitment to prioritise.

The project manager cannot control all of those choices.

But they can influence the environment in which those choices are made.

  1. They can create clarity.
  2. They can connect the work to something meaningful.
  3. They can involve people in shaping the plan.
  4. They can build trust.
  5. They can make commitments visible.
  6. They can surface constraints.
  7. They can force trade-offs into the open.
  8. They can create the conditions for people to take ownership.
  9. And, when something genuinely cannot be done, they can make sure the organisation makes an explicit choice rather than allowing the project to quietly absorb the consequence.

That is what leading without authority really means.It isn’t about finding a clever technique to make people do what you want. It is about building enough clarity, credibility, trust and accountability that people are willing to move with you.

The best project managers eventually realise that their influence doesn’t come from being the loudest person in the room, having the most senior title or sending the most reminders. It comes from becoming the person people trust to help the project move forward. And perhaps that is the real leadership lesson of project management:

You don’t need authority to lead a project. But you do need to create enough clarity, trust and commitment for other people to choose to move with you.

Leave a Reply

Discover more from Nishant Pathak

Subscribe now to keep reading and get access to the full archive.

Continue reading