Big projects mean we can’t do all the work ourselves, and no one wants us to because we aren’t that good at everything. So assigning or delegating project tasks to others who possess the requisite skill sets is crucial to getting the project done. Within an organisation, project management (PM) itself is an example of delegation of authority, typically from the CEO to the project sponsor to the PM.
Delegation means realising results, by empowering and motivating others to achieve their assigned targets. But before we explore this important soft skill further, we need to have an understanding of three terms – accountability, responsibility and authority. The main difference between them is that the last two can be shared, while the first cannot, and responsibility moves upwards, whereas authority flows downwards.
- Accountability. Accountability is the answerability for performance of assigned tasks. Each of our team members is accountable for the jobs we assign them. When authority is delegated to a team member that person is accountable to us for the performance of that assigned task. But if our team member does a poor job, we’re held responsible, which is why some PMs may hesitate to delegate. Accountability, in short, means being answerable for the end result.
- Responsibility. When we assign a task to a team member it’s their responsibility or obligation to do the task. It’s hard to conceive responsibility without commensurate authority. Responsibility can be shared. The degree of responsibility assigned a team member is determined by us PMs who have the “accountability.”
- Authority. Authority is the power or limits given us PMs to give orders and command the co-operation necessary to achieve the project goal. Authority indicates our right to make decisions and give instructions to our team members. Authority is delegated from above but must be accepted from below. Sources of authority include formal authority or de jure (legal) authority, usually conferred on us by our project charter, and de facto or earned authority usually due to personal appeal, mana or expert knowledge.
Responsibility + Authority = Accountability
As the above formula shows, in the process of delegation, we PMs transfer our responsibilities to team members and also give them the necessary authority to perform these assigned responsibilities. At the same time, we PMs remain accountable for the performance of our team members. Every team member is responsible for their assigned tasks, but only us PMs are accountable for the results or progress of those tasks. If we have more than one person who is accountable then each person will assume that the other is keeping count and in most cases this will lead to nobody keeping count. Clearly defining what each team member is responsible and accountable for, and has authority over, is essential. To accept responsibility with insufficient authority is certainly a leadership challenge, often a recipe for stress, and sometimes the cause of project failure. Specifically, matrix organisations are vulnerable to this phenomenon, where individuals are managed through more than one reporting line.
Responsibility Assignment Matrix
In the PM business a responsibility assignment matrix (RAM), also known as RACI matrix or linear responsibility chart (LRC), is a useful tool to clarify team members’ roles and responsibilities for project tasks, and may be a prelude to the development of detailed job specifications. RACI is an acronym for Responsible, Accountable, Consulted and Informed, where:
- Responsible(R) shows those who are in charge of making sure the task is done. They may personally do the work. One person is assigned responsibility for each project task.
- Accountable (A)shows who is ultimately answerable for the correct completion of the deliverable or task and who delegates the work to those responsible.
- Consulted(C) shows those whose opinions are sought, and with whom there is two-way communication.
- Informed (I) shows who is to be kept up-to-date on progress, and with whom there is usually only one-way communication.
Why we should delegate
There are plenty of reasons why we should delegate and plenty of excuses we might give ourselves for not doing so. Key reasons for delegating include:
- It extends results from what we PMs can do ourselves to what we can control.
- It places responsibility for decisions with the appropriate team members who possess the relevant information and competency.
- It is important to use our available team members and keep people productively involved. Cost-effectiveness is a factor.
- As busy PMs we haven’t time to do it all ourselves, and if we attempt to, our performance will soon deteriorate.
- Delegation helps ensure concurrent activity and thus enables challenging project deadlines to be achieved.
- Other people have the knowledge and skills to do it better than we can. Also, they’ll introduce new ideas and methods. We allow for better planning, problem solving and decision-making by involving others.
- It helps with team members’ learning and development. It’s an effective coaching medium. A team member is then better able to deputise in our absence. Succession management might also be a factor.
- It frees us up to tackle our more challenging and appropriate PM responsibilities such as planning, which also helps with our own development and motivation.
- The pursuit and completion of delegated work can be motivating and rewarding. Project team members normally wish to contribute usefully.
Why we don’t delegate
Despite these sound reasons for delegating, we may hesitate to do so for number of reasons, none of which stand close scrutiny:
- No one can do it as well as I can.
- I cannot trust anyone.
- No one has the skills.
- It’s my responsibility.
- It takes too long to explain.
- It is quicker doing it myself.
- I have been let down too often.
- I like doing it.
- People expect me to do everything.
- I have more flexibility if I do things myself.
- I work better on my own.
- No one has any spare time.
- No one will accept the work.
- I prefer to make the decisions.
- I like to keep in control.
- I have no time to keep chasing people.
- It is more bother than it’s worth.
- I cannot afford a mistake.
- I can’t let it go.
- I’ll be blamed for any mistakes.
- I like to keep my hand in.
- Don’t know how to delegate.
- I want to be liked.
- I want to impress the boss.
- Knowledge is power.
- They don’t like my directives.
- They won’t perceive it my way.
- I’m helping them.
- I want to demonstrate my ability.
- I’ve always done this job.
- I’ll be criticised for passing the buck.
- Or even – they might do it better than me.
But do we delegate enough?
There’s no way to determine how much of our work we should delegate to our project team members, since the amount will vary with the job and people’s capabilities. But we can get a rough idea of whether we are delegating enough – and properly – by asking ourselves the following questions:
- Do we feel it’s a sign of weakness to need another’s assistance?
- Do we often have unfinished work piling up?
- Do we have to take work home almost every night?
- Do we believe that to really earn our salary we have to be overworked?
- Do team members often interrupt us for help and advice?
- Do they bring problems to us rather than decide for themselves?
- Is as much of our time spent on details as on managing?
- Do we reserve those details for ourselves that we particularly enjoy?
- Do we feel we must keep a close tab on details to have a job done right?
- Do we lack confidence in our team members?
- Are we perfectionists about minor details?
- In delegating a job do we often withhold full job information?
- After delegating do we hover over (“snoopervise”) the person?
- Do our people lack the required skills or self-confidence?
How do we do it?
One reason why we may not delegate is that we aren’t sure how to go about. Delegation is a seven-step process that starts with matching the team member to the job.
- Select Person. Recognise that some planning and training may need to precede delegation. Matching the person to the task is important. If a team member has little experience or skill in a particular area, we might need to arrange training and give them authority in increments.
- Brief Them. Don’t be vague – be specific. Give our team member the big picture first. Agree the task purpose, objective, standards, realistic start dates and deadlines, estimated work effort, cost estimates, resources, dependencies (ie, the precedence or relationships among project tasks), and limits on their authority. Steer clear of phrases such as “Get it done when you can” as some people may take that literally.
- Confirm Understanding. One of the first things we learn in PM is that it is the responsibility of the message sender to ensure that a communication is not only received but is understood by its recipients. Ensure through discussion that our team member understands the task. But it would be naïve to simply ask “Do you understand the task?” to which team members invariable say they do, but without checking at this point, later we may find that their understanding was rather different than what we intended. While we might suggest approaches, we usually allow the person doing the job the freedom to decide how to do the job in recognition of their expertise or the learning opportunity involved.
- Check Strategy. If this is a unfamiliar or risky task or the team member is inexperienced, it’s important to allow them to consider how they might tackle the job, but then check with them the suitability of their approach and discuss how any risks associated with the task might be mitigated before work is implemented.
- Agree Control Arrangements. Discuss together how schedule progress, expenditure and quality will be monitored, the frequency and composition of any status reports, and how variations (ie, changes) will be managed should these arise. This way our well-intentioned monitoring will not be mistaken as a lack of confidence in their ability.
- Monitor Progress. Hold them accountable. Once work is underway we check for variance – actual progress versus planned progress. We don’t interfere unnecessarily, resist reverse delegation, but are available to help, advise, encourage, and answer questions as clearly as possible. In addition to status reports, it’s important that we periodically inspect progress, as sometimes status reports don’t reveal the whole picture. Also, meetings, sampling and testing may be appropriate. Where variance is outside acceptable tolerances, corrective action will be needed. The mantra is – “to solve it easily, detect it early.”
- Evaluate If mistakes were made we discuss why and ensure all involved learn from the experience. We also give praise, recognition and credit when deserved. Team members need our positive feedback when they are doing things right. Not only do they deserve it, but positive feedback also keeps them focused, keeps them motivated, and confirms what they should be doing. We invite the team member to identify what’s to be done differently next time to ensure improvement. It’s about continuous improvement towards zero defects.
The following matrix is also a useful tool to determine our approach depending on our project team member’s ability and the difficulty of the delegated task, where our options are:
- Hands Off. For those tasks that are relatively easy, where the team member’s ability is sound, no supervision is needed.
- On Hand. For those tasks that are comparatively difficult, where the team member’s ability is sound, we remain available to give help if needed.
- Hold Hand. For those tasks that are relatively easy, where the team member’s ability is low, we would provide guidance throughout the task.
- Hands On. For those tasks that are comparatively difficult, where the team member’s ability is low, we need to be intimately involved and perhaps use the occasion as a coaching opportunity.
Levels of Delegation
Delegation isn’t just a matter of telling someone else what to do. There is a wide range of varying freedoms that we can confer on our team member. The more experienced and reliable they are, then the more freedom we can give them, although the more important the task the more cautious we need to be about extending a lot of freedom. Having considered our team member’s aptitude and attitude (ie, can they do the task, and will they do the task), our five basic delegation options are:
- “I’ll decide.” (autocratic) No delegated freedom.
- “We’ll discuss; I’ll decide.”
- “We’ll discuss; we’ll decide.” A consensus decision.
- “We’ll discuss; you decide.”
- “You decide.” Empowerment. Maximum delegated freedom.
As with PM generally, it is usually safer to err towards more control at first if we are unsure. It’s also important to remember that:
- The more authority given the team member, the higher level of commitment or buy-in they are likely to have towards the decision. However, we shouldn’t provide a team member with more authority simply to gain their buy-in.
- The higher their commitment or buy-in, the more likely they are to properly address and resolve teething problems when their decision is implemented.
One further point about delegation levels is the time typically needed for each decision mode. An autocratic decision is usually quick since we don’t consult with others. However, Option 3 may represent serious meeting time as we strive to achieve consensus. Thus, on a time-driven project or in an emergency situation we may prefer Options 1 or Option 5 that usually take minimum time to decide. Also, delegation levels need to be applied with discretion, taking particular account of the team member’s aptitude and attitude towards the specific task. We should check with our team member that they are comfortable with our chosen decision-making option and if necessary explain why.
Delegation in the Matrix Organisation
Delegation is a complex process in most organisations, but this complexity reaches its height in the matrix organisation that requires a unique relationship between the PM and functional managers.
The matrix structure is used in organisations to share resources across functions where the authority of a functional manager flows vertically downwards, and the authority of the project manager flows sideways as depicted in the above diagram. Since these authorities flow downward and sideways, this structure is called a matrix structure in which an employee has a functional boss and also works for one or more PMs in a temporary cross-functional team. This arrangement is an attempt to take advantage of the benefits of a project organisation while maintaining the advantages of the functional organisation.
In the matrix organisation employees have at least two bosses – their line manager and a PM for every cross-functional project they are a member of. To avoid confusion and conflict and work efficiently in a matrix organisation, we PMs and functional managers must be clear about our respective roles, responsibilities and work priorities. We PMs are primarily responsible for determining the project tasks, schedules and financial plan, while functional managers are responsible for determining the degree of technical expertise required and available, the skills and individuals who will work on our project. If we PMs don’t have good relationships with the functional managers, conflicts may arise over who has authority over employees’ work and work priorities.
At the start of our project the areas of responsibility and authority for both us and the functional managers who contribute resources to our project should be established through mutual agreement. After which individual employee workloads need to be closely monitored, and if excessive, should our project work take priority, functional managers may need to redistribute, postpone or outsource some of their routine operational work. However, if operational work takes priority, our project may need to be postponed, outsourced or cancelled. If priorities and workloads are not agreed, it’s possible that an over-taxed employee may ignore either their functional responsibilities or project responsibilities.
In summary, the problem with the matrix organisation is that employees report to at least two managers, which adds ambiguity, confusion and may cause conflict over workloads or loyalties. This is more likely to happen in a balanced matrix organisation where both project and functional bosses have equal authority. However, this problem can be overcome if all levels of management recognise one simple rule: matrix management responsibilities for functional managers and PMs need to be well-defined, agreed to, and communicated to the employees affected.
I recommend that we build effective working relationships with the functional managers of our project team members, as well as with the team members themselves. That way, there is a better chance that their functional managers will support us whenever possible, rather than pulling resources from our project when a resourcing issue erupts elsewhere. Ultimately, if we cannot agree directly with functional managers over our project resource requirements, we may need to escalate the issue to our project sponsor for resolution.
How effective are we at delegating? Not all of us PMs are good delegators, but the following checklist might help:
- Does our team member have a clear understanding of the results expected?
- What things are part of the job and what things aren’t part of the job?
- How will they know when they’re finished, what will be produced?
- How will quality be measured?
- Does our team member have all the resources needed?
- Do we have an agreed system to monitor progress?
- Does the team member understand how and when to seek our advice?
- Can our team member speak freely to us about problems?
- Does our team member feel they have the freedom to perform?
- Do we arrange mentoring or coaching as needed?
- Do we encourage and are we supportive of their suggestions?
- Do we encourage our team member to make decisions within the level of authority we delegate to them?