{"id":13764,"date":"2017-09-14T00:00:00","date_gmt":"2017-09-14T05:00:00","guid":{"rendered":"https:\/\/centricconsulting.com\/post\/project-staff-change\/"},"modified":"2021-12-15T00:14:20","modified_gmt":"2021-12-15T05:14:20","slug":"project-staff-change","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/project-staff-change\/","title":{"rendered":"How to Know When to Change Your Project Lineup"},"content":{"rendered":"
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?<\/p>\n
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.<\/p>\n
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?<\/p>\n
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.<\/p>\n
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?<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
So, when – if ever – does it make sense to make a change? How can you tell if a change is needed?<\/p>\n
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.<\/p>\n
A few likely scenarios come to mind:<\/p>\n
Note that you<\/i> 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.<\/p>\n
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.<\/p>\n
So how can you tell whether to make a change?<\/p>\n
In making a decision about a resource change, here are some key questions to answer:<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n