I had a conversation the other day with Tom Opgenorth about the trends you see when you’re ending a contract with a client. Our experiences both show that during the life of a project the client will usually (painting with broad strokes here) talk like they want to learn, understand and be competent with the project. Most claim that they want to grow that knowledge during the life of the project so that, at the time of your departure, they will have the ability to smoothly transition the work. Rarely does this seem to happen. Instead, the end of your tenure on the project comes and the client scrambles to ensure that some knowledge is transferred so that they have the minimum level necessary to start getting up to speed. It’s always a mad scramble and the client is left with a huge disruption in the project as a result.

This is where bricks and sponges comes in. It seems that the client (or the employer if you’re an employee on a team…it happens their too in our experiences) is a brick while they’re on the project. They’re porous and quite capable of absorbing, but for some reason they also repel the knowledge they need to absorb. When it comes time to transition off of the project, the client all of a sudden transforms in to a sponge and tries to saturate themselves as quickly as possible. While the metaphor doesn’t work a hundred percent, it does fit fairly well.

I’ve not seen one project successfully transition with minimal knowledge disruption when a team member departs. I think it’s one of the major problems that we have, especially if we’re working as consultants. We have to find better ways to make our clients sponges through the entire life of the project so that we can pour the water to them gently instead of from a fire hose. Some of that responsibility does rest with the client though, and there’s not a lot that we can do to mitigate active unwillingness to constantly transfer knowledge on their parts. If they don’t have the desire or the correct motivations to learn during the project’s live, all we can do is keep pouring the knowledge to them and let them do with it what they choose.

I know some of you are thinking that knowledge transfer problems can be mitigated by creating a lot of documentation or transition papers. I say that it doesn’t work. Every time I’ve arrived onto a project that has claimed to have these documents, they have been woefully inadequate. Worse yet, many were flat out incorrect. Writing transition knowledge into a persistent state means that you have to continually update it to ensure that it’s current state is correct. Development teams are not prone to doing such tasks if they don’t see any immediate, or very near, benefit from it. That would indicate that writing transition documents at the last possible moment would be something that a developer would be willing to do, and that’s true. But leaving the creation of this type of document until the last moment is like trying to write a book about your project during the two week period between when you’ve given your notice and you depart. There just isn’t the time to do justice to all of the information that will need to be collected, organized and transcribed.

The only answer that I have for this is pushing the client to actively participate along the way. Don’t just say “We’re using nAnt to do our build scripts.” Say that plus put the responsibility for changing, maintaining and enhancing the build scripts into their hands very early on. This allows you to mentor them through the process of learning and absorbing the information that they will need to succeed in your absence. If they consistently push back at you that you should be doing it all since you know it best, you have to push back. If they can’t see why you’re forcing the learning experience on them, then you have to leave them to their own devices when the time comes. You can’t bear much responsibility for the success, or failure, of a project after you have left it. All you can do is work hard to set it up to succeed when that time comes.