How hand overs become hand offs

Being a consultant, I find that the start up and shut down of projects are usually the most stressful times. Start up is all about “hitting the ground running”, learning lots of stuff really fast and making a good impression. Shut down is all about hand over. Shut down is the hardest because you need the cooperation of the people you’re handing over to. Whilst you can pretty much deal with any issues during the start up phase just by digging deeper or working harder a hand over with no cooperation just becomes a hand off.

Without a planned hand over phase the value of the project you’ve been working on can be put at risk. It’s all very well working hard to create just what the client needs and wants but if you can’t leave the artefacts with them in such a way that the client can maintain them and obtain value from them then you may as well not have bothered. Unfortunately, it’s often hard to make the hand over.

Knowledge transfer is a tricky problem and extracting yourself cleanly from a client is all about knowledge transfer. I’m becoming more convinced that project shut down should be done in phases; determine the departure date, plan for hand over, begin hand over, leave them to get on with it on their own, come back and do some more hand over, answer the questions that they didn’t know to ask last time, leave them to it again, loop whilst time < departure time, depart, come back a couple more times if necessary to deal with the other questions that they didn’t know to ask, etc… The nature of the client and the people you’re handing over to determines the length of the looping phase.

Complex systems are complex, they take time to understand. In less mature clients, hand overs are often left until the last minute; nobody is interested until the week before you’re about to leave and then it all slips until it’s the last afternoon and you have a group of techies sitting around scribbling notes. The problem there is that you can often see it in their eyes as they flip the bit in their brain that means ‘I don’t understand, I don’t want to understand, it’s Friday, I’ll make some excuses to management, trash the guys and rewrite it my way once they’re gone’.

Unfortunately you can’t force people to allocate more time, but you can try and structure the project in such a way that hand overs aren’t necessary. XP practices, such as pair programming and communal code ownership go a long way to ensure that even though you may be driving the project it’s not just your code. Often you have to do this from the trenches; it seems that as one ‘rises’ into management one forgets how hard it is to gain a complete understanding of code. You can produce all the documentation in the world and it can be of the highest quality but if nobody reads it, or if they read it but don’t understand it then it’s of little value. Documents are hard to write, when you know the subject well enough to write the document you often assume too much from your reader; it’s not until someone who knows nothing of your system reads the doc that you discover that it doesn’t make sense unless you already understand it. This is one of the reasons for the ‘go away and leave them’ phases in the above sketch of the ideal hand over. Do the hand over, then leave them to it, when you come back in a week or so people will be much more aware of what they didn’t understand and much keener to ask questions… At this point you can work together to improve the documentation and, if the client has played it right, the people being handed over to will be much keener to get as much information from you as they can.

How does a hand over become a hand off? One day at a time…