Knowledge Transfer

 When you're starting a new project, you of course identify staffing requirements as part of your estimating. You start to "put bums on seats" as you ramp up the project towards the Execution phase and on-board your project team. You hopefully even have a Team Management Plan that describes how you manage the team; how you on-board, train, mentor and recognise staff. You do all of that and think "phew! That's another job done!" But unfortunately that isn't always the case because there may unfortunately be staff turnover during the Project's lifetime.

Staff may come and go during the Project for a number of reasons: sickness, personal issues, reassignment to other priorities by higher mangers or as is often the case, by leaving the company to pursue opportunities elsewhere. Losing staff partway through a project is always tricky as you lose not only the individuals general expertise, but also their specific insider knowledge of your Project, client or technology. This presents a Risk to the Project that you need to mitigate as much as possible, and the best way to do that is via having a robust Knowledge Transfer Process.

Knowledge Transfer (KT) is where an Outgoing team member passes what they know to an Incoming team members. It should ideally be supported by a standard Knowledge Transfer Plan Template to ensure consistency of KT - and we will be launching such a template soon so keep an eye out! The KT should then follow a consistent repeatable Process; we outline a 5 Phase Knowledge Transfer Process below which you can use on your Projects:

1. Plan Knowledge Transfer
The object of this phase is to produce a comprehensice Knowledge Transfer Plan that will detail precisely what information will be transferred and when, covering all aspects of KT. As we start, there is an assumption that the incoming resource has been identified as is ready to onboard into the organisation - any delay in this reduces the KT window, and increases the risk of the loss of expertise. Using an existing KT Plan Template your organisation should have, the first task is to understand the time constraints that will affect the KT.

By understanding when the Outgoing resource leaves, when the Incoming resource can start, and their relative working hours you can then get an appreciation of the size of the KT window. From here, a time analysis should be completed using a "Working Backwards" method to break the time down into the next 3 phases we outline below (KT Sessions, Shadowing, Reverse Shadowing). The KT window may often range anything from 2 weeks to 3 months, but could be outside of these bounds in extreme circumstances.

​Then, every aspect of the role should be identified and factored into the KT Plan, with  sessions for each across the KT Sessions, Shadowing and Reverse Shadowing phases. Many roles include tasks with a degree of periodicity, usually weekly or monthly, such as a weekly status report or attending a monthly programme board. These should be factored into planning give at least one experience of each in the Shadowing and Reverse Shadowing phases if possible. 

2. Execute KT Sessions
Each discrete area of knowledge identified should have a planned session to review. There should be some sort of documented work instruction, which may potentially be a step-by-step procedure for more transactional work. The session should use this work instruction to define inputs, activity, outputs as well as what tools & assets are used. Here is where more mature organisations win out: if standard processes and tools are defined universally in the organisation then they benefit from this being a lot quicker and easier. But immature organisations, where everything is bespoke and where teams operate in silos, suffer the consequences of this being a lot more time consuming. Be warned!

3. Execute Shadowing
So the new resource now knows the basics of the role, now they need to watch it in action to see how it plays out for real. They should shadow the Outgoing resource when they complete these tasks so they can start to understand how the theory is applied.

4. Execute Reverse Shadowing
It's now time for the new team member to get hands on and try the work in anger. Only by doing can they really get familiar with the role, and others involved in their activities understand who they are and that they are the point of contact going forward. Be it producing the report or chairing the meeting, they now take the lead. The Outgoing resource is still in the background to shepherd the Incoming resource to make sure errors are identified and corrected, but there involvement should steadily reduce throughout this phase.

5. Complete Knowledge Transfer
By the end of the Reverse Shadowing phase, the new staff member should be as well prepared as possible to take on the new role. You should now have a good appreciation on how competent and capable they will be compared to the outgoing resource, but obviously it will still take some time in role before they reach their full potential. Use this final step to identify any specific remaining shortcomings or Risks that you need to be aware of as the new resource moves to independently operate their new role, and Implement risk mitigation actions to try to prevent those shortcomings from impacting the project. Ideally, the outgoing resource will still be available for the occasional query for some time to come just in case, a form of extended Reverse Shadowing-lite; but this can't always be relied on.

What have your experiences of Knowledge Transfer been like in Projects? And don't forget to keep an eye out for out KT Plan Template that will be launching soon!

Stay Healthy! Project Health Check - projecthealthcheck.org