For those of you who have had the pleasure of working with, or for, a third-party supplier, you will more than likely have some experience of knowledge transfer. For those who haven't, in my experience knowledge transfer is something that can make or break an engagement before it begins. It is probably the most important, and most under-appreciated, pillar of any managed service offering.
Let me explain a little further. The task of knowledge transfer is simply ensuring that any new partner has the relevant information they need to allow a continuation of service with the minimum of impact to the end client.
In reality, when there is a handing over of the baton from one party to the next — whether internal to external, or external to external — there will inevitably be a dip in performance whilst everyone gets up to speed. (Beware of anyone who tells you otherwise.) This is only natural and to be expected; however, a good transition plan will take this into account and ensure that dip in service is properly mitigated.
Why knowledge transfer causes so many problems
Put simply, the task is typically underestimated. Organisations don't have a clear understanding of how much knowledge they hold, and there is typically a chronic lack of documentation around processes and applications. If an organisation has a high reliance on contractors, the information often stays with the individual and isn't transferred before that person leaves. Equally, if an individual designed a process or application and has been with the company for years before suddenly leaving, the knowledge leaves with them.
A lack of time is usually the reason given for a lack of documentation — or perhaps the organisation is working in an "Agile way." Whatever the reason, the organisation runs the risk of having gaps in its understanding of its own knowledge.
Scoring the risk
To prepare for knowledge transfer, I recommend clients take the following approach. Start with an internal review of the company's knowledge repository, which typically takes a couple of weeks. Once complete, break the estate down into knowledge areas or categories and assign each a risk index number from 1–3:
- 1 — Well documented. There is sufficient documentation available.
- 2 — At risk. There is little to no documentation, and no subject matter experts available.
- 3 — Recoverable. There is little documentation, but subject matter experts are available who can supply the relevant information.
Each knowledge area is then given a business priority score, also from 1–3:
- 1 — Not business-critical. This is not a business-critical function.
- 2 — Important. This is an important, but not critical, business function.
- 3 — Business-critical. This is a business-critical function.
Please note the above is a guide and can be broken down further as required.
Once complete, combine both scores to get an average, and you'll end up with a risk index number for each knowledge area. In a perfect world, you would then work through each area and, where there is a gap, decide how to mitigate it.
Making the trade-off
In reality, there is a cost associated with filling any gaps in a company's knowledge estate — typically, that cost is time. A company may therefore choose to focus on its business-critical areas first, to ensure it's in a position to share that information with any new service supplier.
Alternatively, after identifying the knowledge-critical areas, the client may ask the third-party supplier to help with knowledge acquisition, and together they can build a joint knowledge repository.
Whichever approach you choose, it's important to identify where the gaps in knowledge sit prior to any major engagement beginning. Ignore this, and you run the risk of a significant dip in service while you and your partner work out how a business-critical application actually works.