The Authority Problem in Project Leadership: Why A PM or Scrum Master Can’t Get Things Done

Ask any room full of project managers if they have too much authority, and no one will raise their hand. Whether you’re a PM, a Scrum Master, or something in between, a lack of clear authority is one of the primary issues that hampers the project leader. Here are ways to overcome this obstacle:

• Understand that authority isn’t the same as responsibility. Sponsors often hand off responsibility for delivering a project without giving the person any actual power to make it happen. This occurs often, and it usually shows up as frustration on the project team’s side and confusion on the leadership side because results don’t materialize. Having appropriate authority is fundamental to delivering a project. That means being able to develop relationships with key stakeholders, address issues, and possess some degree of control over resourcing decisions. Without it, you’re a messenger, not a manager. Discuss the obstacles the lack of authority reveals and how to overcome them. Work with the sponsor to obtain authority. You don’t have to go after all the authority you want at once. Try one slice at a time; this helps build trust and confidence, enabling additional authority to be requested downstream.
• Leverage the power that the project charter provides. In traditional project management, the charter is the document that formally defines a PM’s authority. The irony is that project managers often write their own charters — and then don’t push for the authority they actually need. If you find yourself constrained by a charter you drafted yourself, that’s worth revisiting. Use it as an opportunity to have a direct conversation with your project sponsor about what decisions you’ll need to make and what access you’ll need to make them. It’s a better conversation to have at the start of the project lifecycle rather than midway during a crisis.
• Two role titles without clear ownership can create decision gridlock. Many projects are being managed via hybrid methods. In this case, you have both a Scrum Master and a Project Manager on the same project. Without properly documented and agreed-upon definitions of these two roles, issue resolution can get stuck in a loop. The Scrum Master spots a problem, escalates to the PM, the PM doesn’t have enough context, and sends it back to the SM. Meanwhile, the team is waiting. The solution is straightforward, even if the conversation isn’t: sit everyone down early, agree on who owns which class of decisions, and document it in plain language.
• Scrum gives you a framework for authority — if you use it. The Scrum guide is clear on accountability. The Product Owner owns decisions about value. The Scrum Master owns decisions about how the team works. The team determines the approach they will take to do the work. Where it breaks down is when organizations layer traditional structures on top of this without addressing any overlaps. In any project situation where Agile methods are deployed, use the Scrum Framework as a starting point for the conversations about who owns what, rather than treating it as a rigid rulebook that ignores organizational reality.

Relationship-building with sponsors is non-negotiable. Authority on paper means very little if the relationship behind it doesn’t exist. The most effective project leads — whether they carry a PM or SM title — invest heavily in their relationship with the project sponsor early on. This includes agreeing on how decisions get made, how disagreements get handled, and what communication looks like when things go sideways. Having those conversations before there’s an actual problem is what makes it possible to resolve the inevitable issues when they show up.