Knowledge Transfer

**Ravello** · 25 March 2009, 17:09

Personally I'd say the answer is no, you don't. My assumption for this statement is that you didn't pick up the product skills onsite, and therefore this is not 'client knowledge', but rather your skills.

As a PM I don't expect to transition Prince2 skills to anyone I'm handing over a Project to!

**MPwannadecentincome** · 25 March 2009, 17:19

if they need to know SAP they should go on a SAP course. Alternatively offer to run a customised SAP course for your client at double your normal rate.

**Not So Wise** · 25 March 2009, 17:30

It's not really controversial in any shape or form

Look at it this way, say you were a .NET developer and worked at a client for 2 years and they asked you to do Knowledge transfer.

This would consist of doing and handing over documentation of all system's applications under your remit (and after two years you should have a lot)
Making sure recipient knew who to talk to in situation X
Some training in those systems undocumented quirks (always some)

It would NOT consist in training them in .NET

If they have appointed recipient of the transfer that did not know .NET (and thus all the other stuff being useless to them) you would just inform the client of such, hand over the documentation and leave it at that, their problem not yours

Knowledge transfer is transfer of knowledge of clients process's and systems it does not consist of skill training, that costs extra…a lot extra

**BlasterBates** · 25 March 2009, 18:20

You can do what ever you like. You can sit on a stool and hoot like an owl all day, if you want to. You just need to ensure that you're doing something of sufficient use so that the company don't throw you out.

**AnthonyQuinn** · 25 March 2009, 18:40

Thanks a Lot

Thanks a ton for your useful comments. They are very helpful.

**MrMark** · 25 March 2009, 20:07

Originally posted by BlasterBates View Post

You can do what ever you like. You can sit on a stool and hoot like an owl all day, if you want to. You just need to ensure that you're doing something of sufficient use so that the company don't throw you out.

Damn, I knew there was a reason why I'm stuck on the bench...

**Sockpuppet** · 26 March 2009, 00:04

I had to do some handover when I left last client co.

I taught them to do what I had set up. Run what I had produced and adapt it for the coming year.

I didn't train them in solutions design or mathematical network modelling as although they are needed to do the job not what I was paid to do.

I handed over what I had done. if they want more doing they know where to find me.

If they had asked me to make one of their permie staff me I would have but at a sensible rate.

**darmstadt** · 26 March 2009, 09:06

I had to do a transfer in my last gig for one product which consisted of handing over everything I had done in the last 2 years (documentation, test plans, programs and scripts, etc.) to someone who had never used the product. I didn't feel it was my remit to show him how the product worked although I did give him a basic introduction in it. Luckily I had set up the systems so that when a new release came out all he had to do was follow the documentation and the rest was pretty much automated. He would only hit problems in debugging as he wouldn't know where to look or what to look for. For another product I did no skills transfer but made sure that everything was documented and available.

Everytime I've left a contract there has been some form of skills transfer and I tend to spend my last week setting up a system where people can easily find the information and then on the last day tell the customer that he is free to contact me at any time. This has worked to my advantage with them contacting me for quick, short and dirty projects to help them out.

Knowledge Transfer