Ttdfjt

There is a person on my team who is leaving in few weeks. He is flat-out refusing to provide a knowledge transfer to another team member.

I've raised this with my manager who has spoken to HR. However, apart from releasing him early, it seems we've no other recourse.

He has always been incredibly difficult to deal with and I am delighted he is leaving. However, I would like for him to complete this handover.

He had acted unprofessionally but it seems like there are no consequences for him. Is there anything I can do to get him to do his job and provide the handover?

TL;DR

The loss or malfeasance of key personnel is always a project risk. You can often mitigate such risks through technical or administrative controls, separation of duties, and cross-training, but the risk level will never be zero.

Once a risk is actualized, preventative controls are rarely practical. Instead, you will need to trigger (or create) detective, compensating, or administrative controls to handle the current situation, and then inspect-and-adapt your process to control for similar risks in the future.

Acknowledge and Address Project Risk

Is there anything I can do to get him to do his job and provide the handover?

You can't make someone do anything. Even if you are in a position of authority (project managers often lack direct authority), you must still rely on your business processes and interpersonal influence to get the results you need. If the company has already burned its political capital with this employee (or vice versa), and you can't rely on either the employee's professionalism or on existing business continuity processes, then you probably need to accept the situation for what it is, and then move on to system recovery or exploratory testing to address the project risk.

However, apart from releasing him early, it seems we've no other recourse.

You might get other answers over at The Workplace, but from a project management perspective it is often too late to avoid or mitigate this type of business risk post-facto. In the future, you should:

1. Ensure your project team is cross-functional. Everyone on the team should have at least basic knowledge of how the system works, where key elements are documented or stored, and have a role in business continuity planning.


2. Guard against low bus factors in your project. No individual should ever be the single point of failure for your system or your process!


3. Have a documented business continuity plan (BCP) that includes knowledge/password/key escrow and clearly-defined recovery processes.


4. Proactively test business continuity and disaster recovery plans. Don't wait until someone quits or is fired to discover whether your plans work effectively!


5. Have a clearly defined process for onboarding and offboarding people from the project, including the granting and revocation of access to your project resources.

In short, if you have no influence with this person, and no meaningful incentives to offer that might encourage constructive collaboration during this transition period, then the business should cut its losses, accept that foreseeable personnel risk has come to pass, and begin implementing sensible next steps (whatever that means for the current project and the organization).

You can't close the barn door after the horse has bolted. This risk can no longer be avoided, so focus on what the project needs to move forward rather than on spinning your wheels about how the project got to this point. Just make sure the organization learns the right lessons from this experience, and doesn't end up here again in the future.

There are consequences to his behavior. For one thing, (assuming he as an at-will employee and your live in an at-will area) there is nothing stopping your company from cutting string with this person immediately. From the sound of things, he is in sabotage mode so it would be in your company's best interest to mitigate that and send him on his way. That also means he does not earn or collect the last few weeks of his pay. Second, he is burning a bridge. And that will come to haunt him at some time in his near future.

That being said, you are also exposing a serious issue with managing tacit knowledge of your employees. Having a transfer of knowledge from an exiting employee to a new one is a normal activity; however, if your management processes are so immature that losing the opportunity for that transfer causes severe performance issues, then you have another problem to cure.

So ask him politely to participate in the transfer, let him know what those expectations are, and if he fails to do it, then have your HR department cut him loose. And then do what you have to do to recover from the knowledge loss and make sure you are not in that position ever again.

You ask: Is there anything I can do to get him to do his job and provide the handover?

One approach would be to ask him for a personal favor - either you or somebody he's somewhat friendly with.

(This echos back to something I've written about multiple times. A Project Manager should be getting along with everybody. Just because he has always been incredibly difficult to deal with and I am delighted he is leaving does not mean you shouldn't have gotten to know him well enough that he would do you a favor.)

You could start the conversation by asking if he wants you to write him a letter of recommendation. This may get him to realize that burning bridges isn't such a good idea.

Another idea: Maybe define knowledge transfer. Some people hear that - or similar - terms and assume they have to write a long document. Or that they have to add hundreds of comments to code they've written over the years. They'd rather get a bad name than go through that torture.

If you change it to a 15 minutes code review done verbally, you may get a different answer.

Maybe try this: Plan a small farewell party for him - and (with careful secretive planning) it can morph into a high-level code-review/handover. "We're really curious to know how you solved x, y, or z" could be a starter.

Of course you'll need quick and easy access to relevant code, and possibly have it recorded, as you won't have time to take elaborate notes. Forget about trying to boot up laptops, connect them to projectors and networks and go digging for the files. You want everything ready (probably off-line) on a reliable machine (or printed out) so that you can run through them before the fellow realizes he's doing a handover.

Why will this work? Because most people like showing off their code and showing how clever they are, or how hard they had to work.

And as everybody else has already said: Make sure all systems are backed-up in case of malicious sabotage - and get him off the premises ASAP. Make sure IT is aware of the danger; they can probably monitor his activity once they know about it.

Interesting question! And some interesting answers already.

Just to add another option (which goes in the direction of "ask him for a personal favor"): Assign the task to continue development of his code to someone else (let's call him/her "developer B") of your team and define some new features/bugfixes/changes to be implemented by developer B.

Now hopefully the code is not so messed up that developer B cannot do anything about the tasks, so he will dig into the code and try to wrap his head around it. For sure questions will come up, which developer B will ask the person leaving your company.

I would expect that concrete questions about "how does this code work?", "why does my changed code not work as expected?" or "why have you done it like that instead of like this?" from a fellow colleague are much harder to reject than the question "Please transfer all your knowledge" from a manager.

The only possible leverage you have is if HR asks him to leave immediately for refusing to co-operate in the handover and he loses his few weeks of pay - assuming HR and Legal say this is kosher to do.

However, if he is not really bothered and just wants to leave early (probably due to having another role already lined up), he could even be trying this stunt so that he gets to go earlier. In this case, you just have to take it on the chin as a Mgt. lesson learned.

You mentioned it to be a frustration and inconvenience, not a disaster, so you are lucky in a way.

Then, if you don't want to face a similar situation in the future, best to set up regular knowledge sharing meetings within the team and also ensure documentation is created and updated regularly.