Knowledge Transfer Tips – From The Departing Employee’s Side

A couple months ago, I decided it was time make a change in my career and look for another job (thus the lack of fresh articles lately – sorry!). I had been with my previous employer for 3.5 years and it was great! But I was ready for a new challenge. Something to re-excite me, offer me new challenges, and push me to grow. Since I had been working on basically the same project for the last few years, it presented me with the challenge of being able to offer my replacement as much knowledge as I could in the time we had together. I had the luxury of giving 3 weeks notice – I was invested in the project and really wanted to see it continue to be successful – and I didn’t want a single day to go to waste. So I thought I’d share some tips for transferring knowledge when you are the departing employee.

Create a Transition Plan

If you’ve read some of my past articles, this will come as no surprise. I’m a strong proponent of spending time in planning. But transitioning your responsibilities is a mini-project all on its own and deserves its own planning time as well. No matter how much time you have (a couple days or a few weeks), you need to figure out what you need to transition so you can determine the best and most efficient way to do that.

I recommend you start by making a list of:

  1. Every task currently assigned to you
  2. Every document you own or contribute to
  3. Every system you are a knowledge source for
  4. Every on-going responsibility you have
  5. Every stakeholder that you work with

From that list, start to identify how you can effectively transfer the knowledge.

Wrap Up What You Can

You’re going to be scrambling to transition knowledge probably to a variety of people, but if there are things you can actually wrap up and complete before you leave, that will actually make everyone’s lives a little easier. On-going items you’re obviously going to need to work into your transition plan to someone else. But are there items you can wrap up and finish? Have you been working on a few change requests? Or have a spec or requirements doc to finalize? Try and knock those out! Transitioning a completed document is easier than transitioning one in process – and having to get someone else up to speed in order to continue facilitating those discussions can be challenging for both of you.

Make Sure Your Documentation is Up To Date

If you’ve been doing your job, this is actually something you’re doing all the time and not just when you’re transitioning out of a project or position. (But as I’ll talk about next week, this isn’t always the case so please do your part!) Throughout my projects, I always make time to update documentation to reflect decisions and changes. This is partly selfish – usually I am working on large system implementations and there is just no way that I can remember every decision and detail over time. But honestly, how are my developers and testers supposed to build and validate that we delivered what the client wanted if the source documents (BRDs and FSDs) are not accurate?

There is a balance to “just enough” documentation though – continue to keep that in mind. But a couple things that I did make extra time to update include:

  • System Integration Overview Diagrams – Since I had been working on a highly integrated system, and I was the last person from the integration project still around, I made the time to put together some high level diagrams showing the interfaces between systems. We actually had a diagram from the project itself, but it was time to add some additional details to help further explain some of the lower-level details.
  • Troubleshooting Steps – To help support the production support team, I started documenting specific troubleshooting steps for the most common types of issues we’d seen over the past couple years. Thankfully, we were at a place where we had a very stable environment. But there were a couple scenarios where users were making a similar mistake which caused a specific problem, and I was able to document the troubleshooting steps to help resolve the issue. (Even providing SQL queries for finding the right data to prove that was the problem.)

I actually saved a TON of time trying to transition system knowledge to the production support team because the project functional specification documents had been continuously updated, and I met with them with every release to review new changes. They felt comfortable that they had solid documentation to refer to and needed very minimal additional time from me (except for documenting some of the additional troubleshooting steps).

Identify Additional System Resources

In addition to putting together a System Integration diagram, I wanted to be sure that people had other resources to turn to with system knowledge. Honestly, this one was a challenge – I was the last person still with the company who was intimately involved with defining and building the integrated solution. But, there were new developers that had their own knowledge transfer sessions with departing developers and solution architects, and I needed to count on those knowledge transfer sessions being effective too. The key was identifying who the new resources were and making sure people knew who they could go to – even if that meant it was now 4 different people with partial knowledge since there wasn’t anyone left with a holistic view of it all.

When Your On-Going Responsibilities Will No Longer Be On-Going

As you look at your list of on-going responsibilities, you may just realize that some things will stop. This could be due to lack of available resources, or lack of interest. One of the items I took such personal pleasure in was starting and running the beginnings of a Business Analyst Center of Excellence. This was driven by a personal desire to see the BA role unified across the organization, and over the past couple years it’s really been due to a personal interest in this that it even kept going. With reductions in staff, and the resulting over-allocation of work, however, this was one item that was going by the way-side.

As organizations experience change (and departing employees cause change), it’s time to reevaluate and reprioritize tasks and responsibilities. Don’t be offended if things you were really passionate about don’t make the cut. (Although I do hope they see the value in continuing some knowledge sharing across the organization, but that is up to them now.)

Don’t Forget About the People

Kupe wrote a great article about focusing on transitioning stakeholder knowledge a while back. He goes so far as to say that it is MORE important than transitioning system knowledge. I would say that it is AS important – so make time for both. 🙂  You’ve been working with many stakeholders and hopefully they’ve come to trust you. Now, you’re going to ask them to trust someone else. You’ll be spending time with your stakeholders to make the transition smooth, but be sure to give your replacement as much background info as you can. Kupe gives great suggestions for how to do this. But if I can share one tip with you, it is to personally introduce your replacement to your stakeholders, and then let your replacement take the lead while you’re still there to support them. This gives your replacement a chance to build the relationship while you still have an opportunity to gives them insight and feedback.

Bonus tip: Record Your Sessions

I happened to work remotely for my previous employer, which often has its pros and cons. While flying out in person would have been great, we actually made it work for us by recording our web/phone sessions. For each of our knowledge transfer sessions (with the primary BA taking over most of my responsibilities), we recorded each session and she now has it to be able to play back whenever she needs a refresher. Gotta’ love technology! (Even if you’re not doing web sessions, I’ve known other people to tape record information they wanted to share. This is great because you often give tidbits of info when you talk that you might not think worth writing down.)

What else would you suggest?

There is so much to consider when trying to give your replacement(s) as much information as you can in such a short amount of time. What am I missing? What else would you do to transition your responsibilities? Please share your comments below!

Next week, I’ll take the opposite approach and share some knowledge transfer tips as the new employee who needed to quickly ramp up. Don’t miss it!

© 2010-2011 Real World BA, LLC. All rights reserved.
One Response to Knowledge Transfer Tips – From The Departing Employee’s Side
  1. Sudhindra
    June 2, 2011 | 8:57 am

    Very aptly put across.

Leave a Reply

Wanting to leave an <em>phasis on your comment?

CommentLuv badge
Trackback URL