Do you know when it is time to change your project's lineup? There is no one answer. John Kackley discusses best practices and what goes into a decision to change things up.

Some years ago I joined a project as the project manager. It was already past its planned go-live date, and most of the resources on the team were people that the company had chosen not to relocate in a departmental consolidation. They would be employed only until the project ended, the organization clearly did not consider them too important to lose. However, I still had a project to manage and a decision to make. Should I keep them, making use of their institutional knowledge, or should I try to rebuild the team with new resources?

Project Team Inertia

There's an old adage about buying and selling stocks: anyone can tell you when to buy, but no one can tell you when to sell. The point of the adage is that there are formulas which predict that a stock is undervalued: that's when you buy. But once you've bought in, now you have an emotional stake. The decision to stay with a stock depends on your appetite for risk, this is where the stock market looks a lot more like gambling. Do you believe in yourself enough to stick with your bet? Or have you gotten everything you're going to get out of this, and it's time to realize it and move on? Managing a project team is quite similar. You know when you have to hire: you're building a team or filling an opening. And it's also easy enough to see that a project is ramping down, and it's time to start rolling people off. But how do you know when to replace someone on a project? When do you remove someone from your project and bring in someone else? When has someone contributed all they're going to contribute to the team? It's a tough call. So tough, in fact, that it's virtually never discussed formally or made part of any kind of training. The assumption is that a project manager is handed a team and rides it to victory. There will be personnel changes, of course, but those will be mostly driven by career decisions made by the team members. Things are done this way because there's a core assumption that any disruption to an in-flight team is a greater cost to the project than any improvement a new team member could bring. Existing team members have project knowledge and are already in the flow of work, whereas someone new has to get up to speed on everything, and will take up someone else's time while they do it. There are other reasons besides that. It takes an effort to roll someone off a project, and a lot more effort to find someone to replace them with. Replacing a team member in mid-stream can also hurt the morale of the team, hinting that perhaps there are bigger issues. Also, there's a simple fact of blame avoidance: when you recommend a change in the team, you're taking responsibility for the success or failure of the change. Lastly, American business culture stresses coaching and development as a solution to a problem like this, rather than a replacement. This is fine, but the time may come when those avenues have been followed as far as is reasonable, and replacement is the only logical option.

When to Make a Change

So, when - if ever - does it make sense to make a change? How can you tell if a change is needed? Generally, for all the reasons we just talked about, personnel changes are rarely made on a project when everything is humming along. You should never be afraid to raise the question, however. A few likely scenarios come to mind:

1. It's a clear case of addition by subtraction. When someone is disruptive enough or unproductive enough, it's worth getting rid of them even if there's no one ready to take on their workload, and almost any replacement will be a net positive to the team.
2. A larger change is already underway. Project scope, team organization, or goals are being revisited. In these cases, you should make a thorough review of the team resources based on project needs, and not force resources into slots just for a perception of continuity. It's a perfect opportunity to make a change, and the change may be critical for putting new energy into the team.
3. A significant personnel change is already happening. Maybe a team lead is moving on, your system architect is getting promoted, or a contracting organization's contract is coming to an end. Responsibilities have to get reassigned, and you may define roles that didn't exist before. Maybe now's the time to acknowledge that a person isn't really stepping up for a role, forcing others to compensate.

Note that you joining the project mid-stream constitutes a significant personnel change. As a new project manager, part of your early activities on a project should be making your own assessment of the team, after which you may have a perspective on changes to be made. Regardless of the situation, an underperforming resource is all the reason you need. You should never keep someone on the team simply because it's too much effort to make a change. So how can you tell whether to make a change?

What Factors Come into Play?

In making a decision about a resource change, here are some key questions to answer:

1. How many resources does the project need, based on what roles? Can the person in question fill any of the roles to the benefit of the project?
2. How well does the person fit the requirements, in skill, personality, and cultural fit?
3. How is the person performing against expectations, especially quantitative ones?
4. How critical is the person to the project?
5. How critical is the role to the project?
6. How much longer is the project expected to go? Further away from the project conclusion, it will be even more important to get the right resources on board. Also, the impact of ramp-up time will be mitigated.
7. How long will it take to find a replacement? This should take into account staffing or hiring procedures, along with the scarcity of the skills needed.
8. How long will it take to bring a new resource up to speed?
9. What performance expectations do you have for the replacement resource?

It's not easy to turn these answers into something quantitative, but they can certainly help determine whether the person is a net asset for the project. If you like, you can develop a cost benefit analysis of the change. For this, I would start with the current resource's cost, with the benefit being equal to that cost fewer discounts for poor fit or underperformance. The discounts might be multiplied by a factor reflecting the criticality of the role. These costs and benefits can be compared with the cost to acquire a replacement and the reduced benefit as the resource gets up to speed. In my example at the beginning of the article, after six weeks with the project, I had concluded that the project needed a reboot. It needed to be reorganized and effectively started from scratch. Based on that, I evaluated the resources and decided that some of them were not critical to the project and were no longer a good fit. When I joined the project, they had been performing poorly, but with the project being close to completion, it did not seem to make sense to make a change at that time. By rebooting the project, their knowledge was less valuable, and the change now made sense.

Making It Happen

Project team changes are never made lightly and are rarely easy. Whether your team consists of internal or external resources, there are challenges to plan for when making a change.

1. First, identify all your options. Even after you've done your assessment of the situation, you still have to have a transition plan: a poorly executed transition can cost your project productivity dearly. What's more, although you may have decided that removing someone from the project may be the best solution, you should keep in mind alternatives such as moving the person to another role, modifying their responsibilities, or investing in training.
2. Get buy-in from sponsors and resource managers. As a project manager, you will rarely have hire/fire responsibility for a project, so you'll have to make the case to those who do. Your stakeholders may see the situation in a much different way. Also, there may be relevant contracts or HR policies which they can advise you on.
3. Determine the right transition approach. Can you have the person in place while you bring on their replacement, or is it necessary to have them roll off immediately once a decision has been made? How will the project operate in the meantime if there's a gap? In a perfect situation, the person you're replacing will understand that they aren't the best fit for the role and graciously assist in a transition; situations are rarely ideal, however.
4. Plan the communication to the team. However the challenge has appeared, your team is likely to have questions and concerns when a team member is replaced in the middle of a project. You'll need honest answers to their questions while keeping in mind that the details of personnel issues aren't shareable. You can focus instead on communicating the organization's values, a commitment to the completion of the project, and how the transition will be conducted.
5. Do your best in finding a replacement. You may have to make the decision on rolling someone off without any idea of who their replacement will be. That's not always the case, however. You can work with outside consultants or contractors to identify candidates even as you are finalizing a decision, or if you are drawing from a resource pool inside your company, you can work with resource managers for help. Ultimately, rolling off a team resource without an identified replacement should be a last resort.

The Takeaway

Making team changes mid-stream is never desirable. It can be the best thing for a project, however, if done deliberately, resulting in a stronger, more focused team.

Originally Posted on LinkedIn