Authority and Responsibility, How They're Related and How They Affect Project Management

 

Veteran project managers know that they accept responsibility for the project when they accept the role of project manager. They also know that the lack of authority can seriously impede their ability to deliver the goals and objectives set for the project. Responsibility is directly proportional to consequences. Responsibility for project results doesn't mean that they get placed on the bench until the next project if the one they're leading fails, it has a monetary consequence. They will suffer with the project through elimination or reduction of bonus, a re-assignment to a less responsible role (with an YourLeadPartners attendant reduction in salary), or dismissal in the case of consultants. The connection between responsibility and consequences is entrenched in business. Larger more costly projects will tend to engage more senior project managers and the consequence of failure will be proportional. The connection between project results and consequences will also be heightened.

What is lacking in my experience (20 plus years as a programme and project manager) is a correspondence between authority and responsibility. Project managers can do much of the project planning without having access to authority. Project managers will need some help from subject matter experts for some of the planning work, even if it's just to validate effort or cost estimates. Larger, more complex projects tend to have more need of subject matter experts to the point that some of the work is planned by these experts. The authority needed to acquire and manage the resources needed for this work will usually come with the territory. It's when the project reaches the build or implementation phase that the project manager needs authority. They can plan the work, organize the work, and monitor performance but without authority they have a very limited ability to ensure the work is done on time and with the necessary quality.

The largest, most costly, most complex projects are led by project managers who hold senior positions in their organizations and bring that level of authority to their projects. The Manhattan project, which delivered the Atomic bomb during World War II, is a good example of this type of project and project manager. Leslie Groves, who managed the project, was a 3 star (lieutenant) General. The vast majority of projects which don't fall into the Manhattan project category in terms of size are where the connection between authority and responsibility falls apart.

Most projects nowadays are executed in a "matrix" environment where the organization uses project managers to run projects and functional managers to manage people. The matrix environment is a good fit for most organizations because they have a mix of operational and project work. The problem with the matrix environment is that seldom do they come with a blueprint for the division of authority between the functional and project manager which means that the project manager has none of the authority and the functional manager has it all from the resource's perspective. Organizations with more mature matrix environments may have taken some steps to resolve the issues that this division causes, but rarely do the definitions of the 2 roles include a precise description of authority. This is probably also due to the fact that the HR group plays a big role in defining authority through their policies and they tend to be behind the curve in accommodating their policies to the management of projects.

Problems start with the acquisition of the project team. Project managers are prone to the same greed and the rest of the human race and would like to have a free reign to acquire the best resources the organization has to offer. Functional managers, on the other hand, have their operational responsibilities to consider. They will be compensated for the resources they relinquish to the project but aren't usually incented to make sure their best and brightest are made available to the project manager. That's because their performance is measured based on the success of their operational responsibilities. If they make their best resources available to the project, they may fail to deliver on their operational goals and objectives and that may have a negative impact on their compensation. The best approach I've seen to balancing operational and project needs is to have functional managers whose sole responsibility is the "care and feeding" of resources. Since they don't have any other operational responsibilities, they are free to assess the competing needs of projects and operations and make assignment decisions based on their perception of what's best for the organization.

Problems encountered with team acquisition will propagate throughout the rest of the project. Presuming effort and duration estimates were based on some level of performance that is greater than some of the acquired team are capable of meeting, project performance will suffer. Pointing out to the project sponsor that performance issues are being caused by under-performing team members may or may not bring relief. The sponsor is likely to view your complaint with scepticism if you didn't raise the issue before. An inability to perform the work is not the only cause of poor performance. By far the most common cause of inadequate performance is the bleeding of resource time from the project by operational demands. The demands may be quite legitimate and the operational work demanded of the resource may be the best possible use of that resource for the good of the organization. That doesn't help the project manager when he or she has to explain poor project performance to the stakeholders. This situation is bad enough when the project manager is given notice of the demand but is much worse when they learn of the change after the fact. The level of authority the project manager has been given, or at least the functional manager's perception of that authority, will often determine whether they find out about the operational work before or after the fact.

The other side of the resources coin is the recognition and rewards that are used to build team morale. A lack of authority in this area usually has to do with the project manager's ability to spend money to give awards or purchase any other kind of team building activity. Recognition and rewards are usually governed by HR policy which is the reason the project manager is not given authority to bestow these on deserving team members. The lack of any kind of budget to buy awards is the other reason.

Lastly, the project manager may be called upon to deal with team members whose head just isn't in the game. They have the ability, experience, and training to perform the work at the level of competency envisioned in the project plans but don't. There may be a variety of reasons for this but they usually stem from the resource's commitment to the project, or lack thereof. Let's look at the example of a process improvement project to illustrate what I mean. The benefit of the process improvement is the elimination of effort which will translate into job loss (at least in that department). Some of the team members who work on this project may be the ones whose jobs will be eliminated; after all they're the subject matter experts in the old process. Is it reasonable to expect these folks to show enthusiasm for the project? Of course not. Unless the project manager can show these team members how the project will benefit them, or at least not harm them they're going to be less than committed to the objectives of the project.

The lack of enthusiasm may have nothing to do with security; there are any number of reasons for a lack of commitment from team members: jealousy, the perception that their best interests are served if the project fails, a commitment to a project they perceive as competing, dissatisfaction that a friend is not assigned to the team are just some of the "political" reasons that a team member may not give the project their best effort. Resolving any of these issues will require that the project manager have some degree of authority over the resource. This doesn't necessarily mean they have hiring and firing authority, the ability to influence their compensation may be sufficient.

Now that I've made the case for an authority commensurate with the degree of responsibility, let's look at some ways and means of acquiring that authority. I'll start by addressing the folks who sponsor projects. You should hold your project managers responsible for project results; that's their job, but it doesn't make sense to hold them accountable without giving them the ability to meet the project's goals and objectives and authority is a key component of that ability. You can help here by coming to an agreement with your project manager over the degree of authority you're giving them. Working within the policies dictated by your HR group, you should assign them the authority level you both agree they need. Don't speak in generalities, be specific. The project manager should know what their remedies are in the case where they have performance issues with team members. The process used for determining the composition of the project team should also be clearly articulated. How will disagreements over individual resources be resolved? Of course to do this in a way that makes sense for your organization, you'll need to prioritize your project against the other projects and operational work of the organization. If the project goals and objectives are high priority, the project can't be a low priority when it comes to competing for scarce resources.

Their level of authority over the team members, once the team has been defined needs to be clearly articulated as well. How will the project manager deal with a team member whose performance is sub-standard because they don't have the necessary skills or experience? How will they handle the team member who has the necessary skills and experience but isn't performing for some other reason? The project manager's authority needs to be articulated in sufficient detail so that these questions are answered. Delegating authority to the project manager doesn't have to contravene any HR policy. For example, it may be against policy to allow the project manager to hire or fire resources but where stakeholders, customers and others, contribute to performance reviews make sure the project manager is a contributor and make sure their review is weighted in accordance with the amount of time the resource spends on the project and the project priority. On the other hand sometimes projects are important enough and HR policies behind enough to warrant changing them. Don't be afraid to gather political allies and make the case for change to HR. You may be successful in effecting the change for the next big project even if you aren't successful making the change for the current one.

The project area that the project manager will need authority for is recognition and rewards. The project manager should be able to articulate a recognition and rewards programme for the project, or how they will utilize existing recognition and rewards programmes. Ensure they have sufficient authority to administer the programme. This will mean a budget, in most cases. Work out how you'll make the money available when needed in cases where it's impossible to give the project manager any signing authority. Lastly, make yourself available to take part in awards ceremonies or team building activities. I haven't dealt with any sponsors who didn't enjoy these occasions once they had been exposed to them.

Project managers who have sponsors that have failed to read the above, or who are not comfortable taking the initiative with you, will need to initiate the conversation themselves. Once you've defined the level of authority you need in detail make certain it's documented. If your authority isn't written down anywhere, you don't have it. People's memories being what they are, the perception that you have of the authority you have will differ from your sponsor's and that gap will only widen as time goes on and memories deteriorate. Remember that the authority you're given isn't plucked from thin air, it is authority that your sponsor has (or any other senior stakeholder) that they delegate to you.

Your authority should be captured in the Project Charter. The level of detail need not be any greater than the rest of the charter; you can leave that to specific tasks or purposes. It should be spelled out in generalities such as "the Project Manager has the authority to participate in the selection of the project team", "the Project Manager will evaluate members of the team and these evaluations will be used in performance reviews", or "the Project Manager has the authority to address performance issues". Specifics can be left until the project advances to the stage where authority is needed. For example, you can ask for an e-mail from the sponsor in advance of team acquisition specifying how decisions will be made on individual team members and how disputes will be handled.

Authority is like a muscle: it will atrophy if it isn't used and won't be available when it is most needed. Your sponsor has given you authority so that you can use it to achieve your project's goals and objectives so you should never fail to achieve them because of a lack of authority unless you were specifically denied it. This means that when team members refuse to recognize your authority to direct their work you must use it to impose your will on them. Don't confuse the imposition of your direction with abuse. You abuse your authority when you use it for purposes other than the accomplishment of the project's goals and objectives or when you show favouritism imposing consequences or rewards. Avoid abusing your authority at all costs, but not at the cost of failing to exercise it. To ensure you avoid abusing your authority it's a good idea to have your HR organization's policies and guidelines handy and ensure you're familiar with them.

Project managers who initiate the conversation about authority will have the advantage of being able to define the level of authority they believe they need. This can either be done by spelling your authority out in the draft version of the Project Charter or in some other document that precedes it. Don't be faint-hearted here. It's better to have authority that you don't need and don't use than to fail to have it and need it. Don't be shy to exercise an authority you don't have because neither you nor the sponsor foresaw a need for it. Your sponsor is much more likely to forgive you exercising an authority that leads to the accomplishment of a project goal than they are to forgive you for failing to meet the goal.

Most of what I've said here will apply to project managers who are permanent employees of the organizations they manage projects for, but what about consultants? These folks perpetually find themselves in "matrix" environments because even in organizations that are projectized or that have a mature, proven matrix arrangement, they don't apply to the consultant. Consultants need to be especially diligent in outlining their level of authority and in using it. Their authority will never include the ability to fire or to pick and choose resources when acquiring the team. At most they will have the authority to hire contractors and participate in acquisition negotiations for employees so they need to ensure that they have a remedy that will address an insoluble problem with a team member. Don't forget that when you first arrive on the job you're an unknown quantity to the stakeholders. They may have had exposure to you when you interviewed for the role but you're still an unknown quantity. After you've been in the role for a while you should have gained a level of trust that will allow you more leeway in exercising authority but until then don't make assumptions that could embarrass your sponsor.

Finally, if you fail to have your sponsor delegate the authority to you that you need to succeed, make sure you document that fact. How do you do that without insulting your sponsor? Simple, not having the authority needed to achieve project goals and objectives is a risk to those goals and objectives and should be captured in the project's risk register. Don't describe these risks in personal terms; describe them in terms of what the risk event looks like and the likely impact on the project if they happen. A conversation about mitigation strategies to address the risk may lead to granting you the authority. At the least they should lead to a mitigation strategy that will reduce the level of risk. If all else fails and there is no granting of authority or identification of acceptable mitigation strategies, the project must accept the risk. You still have the option of reviewing this risk and its acceptance whenever the risk register is reviewed with the stakeholders. A word of caution here: the risk identifies a disagreement between you and your sponsor; don't use this as an opportunity to embarrass your sponsor in front of their peers or managers.

One final word of advice for all project managers: it's usually easier to ask for forgiveness than permission. When in doubt assume the authority and exercise it. If you've overstepped your bounds but achieved your objective your sponsor may point the mistake out to you, but won't be as unhappy with the result as they would be if you failed to exercise the authority and failed to achieve the objective.