Transition Plans

Being as I am changing jobs this week, from a pretty large startup to a multi-national, its been on my mind that the "knowledge transfer" needs to be done.  I've done it a few times before, and I am well known to be a document hound; if something has to be done its documented.  No questions asked.  We'll probably end up doing it again in 6 months or more, so I like to review how we did it previously.

Ever since I worked at a company I will call NaviPath, which was its name and since it no longer exists I figure its safe, we had an initiative to get ISO certified.  My job at NaviPath was in Release Engineering, but I also did Smoke testing of the builds to make sure everything worked properly, I've done Release and QA in my many years.  I have no idea why ISO, but we needed to do it.  There was the documentation reviewer who made sure everything going into source control, in the appropriate document form, was correct and numbered properly.  The pyramid went around to test people on the procedures (you can be sure the pyramid got lots of movement by others as well) and to make sure they understood what we were doing.  True the company folded before the initiative finished but from it all I took the document format with me, because it seemed a good QA fit.

So what does this have to do with Knowledge Transfer?  All will become clear.

When I started my next company, I again wrote down procedures and processes.  Using the ISO format, and using my own numbering, I kept track of tasks I was doing.  Generating a Test Plan, short and simple document on creating Test Cases.  Installing parts of the software, a document with small screen shots that showed all the steps and things to watch for, gotchas that happen and everything else we could think of; these increased over time.  All in all, though not all contained excessive detail, we had about 30 documents by the end of my employment as the QA and Release Manager; as I brought new people in and they wanted to know how to do something like rebuild the QA servers in the lab - I pointed them to the documents.  Dev wanted to know how something was done in QA, there was a doc that explained it.  Or I talked it out with them, then wrote something to be used the next time.  These documents became our official departmental records, and even after I left I heard from people who stayed behind that they appreciated them because they had forgotten to ask about one of the tasks we only did once or twice a year, but the document was there with all the steps.

So in looking at transitioning now, I can think of all the work I do and have done in time, but there might be something I miss.  Or maybe I am not thinking of it in the last few days, because I am transitioning all the work I am doing now, and anything that is on my mind for planning in the next month.  Not the two hour task I did 6 months ago, which won't need to be done until next year; if its written down and documented properly then I don't need to.  Or I can review all the documented items and remind myself of anything that is needed.  I've also found that going over all the documents with someone brings up other tasks that were slight, or may need to be added somewhere.  Sure there is a maintenance cost, but after 3 years I found that 10 minutes a week to review the documents was enough to keep them updated, and ones that needed drastic changes either were deprecated for new ones or we added a new section or document for the new way; if we had legacy items that still required the old way.  Even though I spent 4 days going over everything I knew about the systems, how we tested and the best ways to test the next generation, I also spent time reviewing all the departmental documents that I had written over time.

The Knowledge you leave behind as an artifact, is just as important as handing off the project you are on now, and often that work you leave documented somewhere will help everyone out more in the long run.  That is how I would rather be remembered.