You may have to deal with a team member leaving your project at any time. It’s never easy and it’s never pleasant. Although, it can sometimes be a bit of a relief!
There is a lot that can go wrong whenever a team member leaves you. It can easily become a crisis point for our project. But even if it doesn’t, it is often a point of risk. The consequences of a poor handover can be delays, mistakes, and a lot of extra work.
That’s what we are looking at in this feature article.
There are, simply, four primary reasons why a team member may be leaving your project. And I apologise to anyone with a dislike of four-box models. But this situation cries out for one!
The four cases are:
Your team member is leaving for wholly positive reasons, and you are taking charge of this. This is common towards the end of projects, or at the end of project stages. Either the team member’s role is finished, or there is little opportunity for them to develop further with your project. Sometimes, you reluctantly facilitate a transfer to another project, because you know this is best for their career development Or maybe, it is best for the organization: another project needs them more than yours does.
This is your team member taking charge of their career. They are leaving your project for positive reasons, to pursue a new opportunity, or as as a move to further their career. This may also be for positive personal reasons, like supporting their partner, or working nearer home. You can expect them to consult you on this, but you’d be a fool to stand in their way. No project manager wants a hostage on their team.
For whatever reasons, you need to move this team member off your team. It won’t be pleasant, but you need to act. Common reasons include poor performance or an unhelpful attitude. This may also result from inappropriate actions. Clearly, there is the possibility that there will be additional personnel actions running in parallel. We shan’t deal with these in this article, because procedures vary in different organizations, and can differ widely around the globe.
This is when you have a team member leaving your project for negative reasons of their own. Most often, it is a personality clash or they don’t like the work. Sometimes it is a perceived injustice or a grievance against you. It could also be against another team member. If the grievance or injustice is real, I would hope you have done, and will do, everything you can, to redress the situation. But you may not succeed. Again, we won’t deal with that aspect of the departure.
Finally, it is rare, but team members do leave because they have a fundamental objection to the nature or approach of your project. This is most likely in certain industries, or in consulting projects where the team member has an issue with what their client is doing. Everyone is entitled to make choices that support their values. So try to be respectful of your team member’s moral decision, and convert a grievance departure into an amicable one.
For much of this article, the reasons won’t be material. We’ll focus on practical actions and concerns, which will be common across all cases. Howver, from time to time, we shall look at how the reason for departure affects your choices.
So, in the next four sections, we’ll deal with:
You’d expect to think of these first, so let’s dive straight in.
First of all: Don’t panic…
Keep calm and carry on. To a first approximation, this is a better managed equivalent of someone going off sick. So whatever cover arrangements you would make, can keep you going for the first week or so. This will allow you to manage the transition in a tidy and considered way.
Your first priority is an orderly transition. After that, you can think about the longer term. This means being sure that nothing falls between the cracks, as your colleague leaves your project. Your two principle concerns are knowledge and delivery.
There are two components to this.:
To ensure that project delivery remains on schedule, you will need to manage the transition of work packages and task lists to others. This is a great opportunity to review your whole team. Ask yourself questions like:
Based on your review, develop new role assignments.
If you have time, the ideal will be to review your plan, before deciding on task transfers, above. But realistically, you may need to make some transfers quickly. This will depend on the reason for the departure, and how much notice you have.
New task allocations can drive different approaches and new schedules and budgets. I’d consider it essential to at least get fresh commitment from work package managers to your plan, if they or any of their teams change as a result of the departures. Better still, they should be the ones to lead on review their components of the plan.
With a team member leaving, you also need to review the risks that creates. But not only that; how does their leaving change the likelihood, impact or proximity of existing threats? Whether or not the team member leaving posed a key person risk, it is likely that the reallocation of their responsibilities will change the risk landscape to a degree.
How does the departure affect your long-term project resourcing plan? You may need to fill gaps in your skills matrix. You have three broad options to consider;
Do not neglect the impact of the departure on your team. Leavers and joiners will usually upset the smooth running of your team. We explore this in more detail in or article about the Tuckman Group Development model. There is also a short video summary of the Tuckman model.
You may also need to remotivate the team. What you need to do and how you can best do it depends on the reason for your team member leaving. If the reason was positive, then you should include a public celebration of their contribution, before they leave. For negative cases, you’ll want a more cautious acknowledgement of their role and the impact of their leaving, and a future focus to the meeting.
As always, communication is a huge part of your role when a team member leaves your project. Let’s consider your three principal constituencies.
This may be a purely procedural matter, about which they may be, rightly, unconcerned. However, if the reasons are negative, there may be reputational risks, about which they need to be aware. And let’s not forget; a properly engaged sponsor will know your team and take an interest in the as individuals. They will want you to inform them.
You should announce the forthcoming change to your team, as soon as appropriate, but not sooner. Rumors get out, so show yourself to be in control. Again, circumstances will dictate what you can share, but ideally let your team know the reasons for the departure.
If the team changes will affect them, be sure to update your stakeholders and any delivery partners. There is nothing so unsettling for a stakeholder as calling your regular contact to find… they’ve gone.
Your third consideration is the person who is leaving. You have personnel, managerial and personal responsibilities to them. Let’s see what you should be dealing with.
If they are leaving amicably, and you don’t want to lose them, try one last negotiation to keep them. Do this as early as possible, and d it gently. Ask them about their reasons and work together to explore how they can get what they feel they need, and stay in the project. This will often need some creative thinking form you both, and flexibility from you. But if you can find a win-win that allows them to stay – and feel good about it. Then it has to be worth the effort. We have an article about negotiation.
Feedback works two ways, and you have a responsibility to facilitate both.
As a project manager, you are in a leadership role. Part of that role is to give people feedback from which they can derive confidence, learn, and develop. We’ll take a close look at giving feedback in a future article.
Sometimes called an exit interview, it is good practice to meet someone who is leaving to hear their frank opinions and leaving thoughts. It is a chance for you to hear the truth. And no matter how uncomfortable, listen carefully, make notes, acknowledge what you’ve learned, and thank them. Do not get yourself into defensive mode. There is nothing in it for them to be part of an argument. And there’s nothing in it for you, either. It will just get in the way of you learning from their honest perceptions. The fundamental question to ask is:
What can you tell me now that you were reluctant to say when you were on the team?’
Make sure you say goodbye properly. As well as the personal component of your goodbye, there are three things to cover:
The ideal outcome is to part on positive note, with a value professional relationship intact. If the reasons for the team member leaving are positive, this should be easy. But, if they are not, it can be tempting to indulge your emotional desire for some form of payback. Don’t.
Don’t make it worse: make it better.
As a minimum, stay completely professional and avoid exacerbating the problem. But, if you can, use respect and generosity to try to improve the relationship. This is often possible, because the source of any friction (working together on your project) has been lifted.
Okay. Now we’ve reached the bit everyone loves: admin.
Let’s get it over with, because the truth is:
So, here is my Team Member Leaving your Project Admin Checklist (catchy, huh?)…
Have you ever had to manage a team member leaving your project? If so, what advice would you add?
If you haven’t, what questions do you have?
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.