« No sod for you! | Main | Rich Client or Browser Interface »

September 21, 2004

Transition Time

As I have gradually expanded my consulting business, I have had to move much of the "in the trenches" development down the chain of command to my team of consultants (very good ones, if I may say so). Now, one of the hardest things to do with a client is transition them from one developer to another; Finding the right time can be a big challenge. If a deadline is looming, or you are in the middle of a customer deployment, you can't exactly put on the brakes to train an somebody new on the intricacies of the project. If you do manage to find an appropriate time slot, there is the problem of finding the right path to project knowledge (instead of confusion). You might think that project documentation would be a good place to begin, although you'd be amazed at how many companies have barely enough money to develop their product, much less document it.

As an example, SourceGear makes a great source control application, Vault (which my company as well as all of my clients use), but their documentation is limited to a knowledgebase forum. They also have a neat Client API, but it is clearly marked as unsupported and has only rough documentation.

So, if companies are skimping on documentation for their customers, then that gives you some idea as to the priority of developer documentation funding. Most of the time, all you've got to give the incoming developer on the project is a database schema, some process and interface documents, and well commented code. The transition process definitely takes some serious face time to fill in the gaps, not very much of which is billable. The important thing, though, is to make the process as seamless as possible for the client. To help ease client concerns, I also knock 25% off of the incoming developer's billing rate for the first 100 hours that they are on the project to account for ramp-up time.

Ahh, the joys of running a business.

12:06 PM | Permalink


Documentation is a serious expense. I made an "executive" decision to have really good and comprehensive docs for my components. Of course, doing the docs for the first one took *twice* as long as the coding - eek!

I'm not sure what to do about this - maybe hire a technical writer?

As for ramping up newcomers - scares me silly, but you seem to be coping so it must be possible :) My plan is to have a robust project infrastructure in place - a "this is how we do things in detail" approach. Still, it seems like you just have to "suck it up" for the most part...

Posted by: Richard Rodger | Sep 22, 2004 8:50:04 AM

The comments to this entry are closed.