Knowledge transfer

*ring* *ring* goes the phone.

“What do you know about the ‘letsrebootthepcandreallyannoythecustomer.exe utility?”

First written in 2005, by Mahatma Coat. We tried getting some modifications to it. We were partly successful.

“Who looks after it?”

Try Mahatma, his boss and the generic “Desktop Engineering Team” mail box. You might have some luck with those.

Letsrebootthepcandreallyannoythecustomer.exe was created to manage the “can we reboot your PC Mr. Customer?” issue we were having. Our customers wanted to see:

our company logo on the prompt
the option to delay the reboot
the option to not even install the update.

So one of our programming remote desktop engineering folks created it. It suffers from a couple of issues IMHO, and they are:

developed by a novice desktop engineer, which brings in all the mistakes novices make in programming code.
Used Visual Basic 6, a product long out of support, and which no other desktop engineer uses on a regular basis SO we can’t easily modify it.
If we have the source code. We don’t. The Remote Desktop Engineering Team keep their source code to themselves.

If I ruled the world, I would either a) buy a Commercial Off The Shelf product and ask the vendor to customise for our requirements, OR b) re-write it in something “better” than Visual Basic 6.

Knowledge transfer, or getting to the point of this post.

Back when I was a spotty computer operator, working shift work, the importance of “shift handovers” was drilled into me. “Shift handovers” was a semi-formal process where we told the next shift team and the issues we had on shift, and the ones they needed to manage on their shift. Other professions do it. Nurses for example.

On a grander scale, what is your organisation doing to manage the loss of knowledge which occurs when one of your employees leaves the company?

Related posts: