How much independence should project managers have?

Question

As each software project has its team who work on it, this team is considered somehow a "separate body" within the company. Team members have their assignments, their vision and expectations from the project.

Of course, number of questions arise during the project, both technical and non-technical. Technical questions are usually easier to solve as we have team leads and technical leads.

For non-technical problems, we have project managers. Project managers should address all questions within a team starting from an unplanned vacations to disputes between team members.

Recently, a team member wanted to give her tasks to another person who is not on the team; I did not allow that. A second team member is constantly delaying the start of his work. Another is trying to use a third party-tool to write HTML code more easily. One of the workers wants to use his own tool written in node.js to facilitate his work, although that is not a technology used in our company and no one could support the project afterwards.

Other PMs in the company will certainly address all these questions with the CEO, but I believe a PM should have the appropriate level of independence to make decisions like who should do what and how.

So, to what extent are PMs able to make independent decisions?

Answer 1

tl;dr

"Independence" isn't the issue; the issue is accountability and your integrity.

Dispense with the distractions

Independence is a road to project failure. You are interdependent; your success is tightly coupled with that of your project team, and theirs with yours. Any other viewpoint will lead you to disaster. I would argue that none of the issues you list in your question are problems for the PM.

Concentrate on your accountability

The core issue is to whom you are accountable and for what. Fortunately, that is relatively straightforward. You are accountable to the project stakeholders. The PM (should have) signed the project charter; in doing so, you committed yourself to deliver a specific scope at a specific time for a specific budget.

In an ideal world, you'd do that. In the real world, if project management were that simple, it wouldn't be a paid profession.

The real world

In the real world, your signature on the project charter commits you to deliver the scope on the schedule for the budget and to manage any changes.

@Saakyan asks me to clarify "for what"; a reasonable question.

1. I'm accountable to my stakeholders for a realistic estimate of whether the project will meet the target. Ideally I phrase my estimate in a risk context "I believe it is 90% likely that we'll deliver on schedule, and that the customer will accept the ultimate deliverable. I'm less confident about budget; it is only 75% probable that we'll come in within 10% of our estimate."

2. I'm accountable to my stakeholders that if there are problems that threaten scope, schedule, quality or budget, that I'll work with the internal stakeholders to find solutions. Note that I'm accountable to both my internal stakeholders/team members and to my external stakeholders (customers, management, families, etc.) I owe it to my team to work with them to find the best solution (most effective, least painful).

3. I am accountable to all that if the scope/schedule/budget changes, that I present a solution for that change, and a real cost for that change.

Interdependence

Success involves analyzing those factors, and working with the project team to develop alternatives to mitigate the effects of the unknown. Where relevant you're also obliged to inform the stakeholders.

Answer 2

TL;DR

Projects exist within the context of an existing organizational structure, are managed through delegated authority, and should not be run like independent fiefdoms. All of your sub-questions boil down to an organizational failure to properly charter the project and define the project manager's scope of authority (if any).

In addition to the process failures, you appear to lack influence with both your management team and with your project members. Regardless of the reasons for this, you must either fix the problems (if you can) or leave the project. Your project is unlikely to succeed under the status quo.

Project Charters

Regardless of framework, all projects require some sort of inception document. This is usually called the project charter. A good project charter should also define the roles for the project, including:

• project sponsors,
• stakeholders,
• technical decision makers, and
• lines of authority.

The project manager is often not a manager or authority figure in the traditional sense, and on some projects may have responsibilities without delegated personnel or budgetary authority. This is an organizational decision, and one which your current organization has either not made, or has made in a way that you don't agree with.

Authority Must Be Delegated

Authority must always be delegated from the top of an organization. This delegation is often a chain where the project manager derives whatever authority he has (if any) from the project charter or project sponsor.

If you have not been granted any authority, then you must use influence rather than a command-and-control style to manage your projects. Based on your description, it seems as though you currently lack both authority and influence. You may want to discuss these issues with the person you report to.

Who Works for Whom

You work for the company, and any authority you have is delegated from senior management. Therefore, when you ask:

[W]hat if CEO intervenes and countermands your decisions?

it seems likely that one or more of the following statements are true:

• You are making decisions outside the scope of your delegated authority.
• You are making decisions that are out of step with your organizational norms or the management team's expectations.
• You do not have the appropriate levels of trust and two-way communication between you and your management team.
• You are at odds with your management team.
• You do not understand the organizational chart or the source of your delegated authority (if any).

While it's often preferable for the senior management team to work through a project's appointed leadership to manage a project, it is certainly not required. Regardless of how you feel about their decisions, it is always up to senior management to determine how they want a project or team to be run.

If you find that your style of project management is a poor fit for your organization, or that you lack the influence or finesse to manage the political aspects of the project, then you may want to consider looking for a different role within your company—or even trying to find another company where your project management style would be a better fit for the company culture.

The only real power you have that is not delegated to you is the right to "vote with your feet." Fix the process if you can, fix your attitude if you can't...or just move on. Good luck!

Answer 3

Refer to senior management only if it is a policy issue

As @CodeGnome pointed out you should not try to run your project as an independent fiefdom.

On the other hand, you should not refer every decision up the chain either.

"In broad terms, delegating up means pushing responsibility and decision-making up one level, with the intent of the employee to avoid accountability for his or her actions. It typically occurs when the direct report lacks the confidence to exercise judgment or does not have the required skills or expertise to execute effectively."

Ideally as a Project Manager (or for that matter any Manager) you should take all decisions needed to execute your project successfully, within the broad policy framework set by the leadership. However, sometimes issues comes up that might have broader impact, beyond your project. If there is no set policy or direction on how to handle it, you may want to refer it to senior leadership. Even in such a case, if I were you, I will consult my peers and make a specific recommendation to the CEO.