How to Ensure Continuity of the Project If Consultant Quit

Once again, I’ve seen search terms that found my blog that have inspired me to write a post to address the issue. Today, the terms are “how to ensure continuity of the project if consultant quit.” As it turns out, it’s not uncommon for customers to hire me to step-in for someone who is no longer available.

Steps to Take
When the person leaves your laboratory informatics projects, whether it’s a LIMS an ELN or something else, it’s probably too late to do anything. The next person will just have to struggle through whatever you have, even if it’s a big mess (and I’ve seen plenty of those, just trust me on that). They’re gone and even if they were sent by a larger company, such as the software vendor or a larger software services firm, they’re gone and you’re unlikely to get anything from them that you don’t already have. Remember this: Good habits start at the beginning and go through the entire project. With that said, here are some good habits to enforce:

1. Documentation. The people working on your project need to document their work. It should be done along the way. People can be quite clever when they don’t want to do this. Clever people put this off until the end and then escape without doing it because they don’t want to do it. Clever people also create a document so crummy and useless that you give up on getting anything from them. So, you might need to come up with an example of what you want for them. And it’s the responsibility of the person writing the program to create a technical document to support it. Period. End of statement. NO-ONE is that special that they should be able to con you into pushing this onto someone else (and that someone else doesn’t know what the person did, so they’re not a good resource to push it onto, anyway). And don’t accept the excuse that the next person will just look through the system to figure it out, either. In large systems, that can be difficult.
2. Communication. If you have team members that can understand some of what the person is doing, and especially if they will take it over from the person, eventually, make sure that person is keeping your other team members up-to-date with what they’re doing. This is true whether they will take over for the next project phase or for long-term system maintenance. The person should give them a demo of the entire thing working, should explain where the configuration/customization has been done, and should go through the supporting technical document they wrote with the team, too.
3. No Dead Code/Managing industry templates. A number of the projects I work on have a “no dead code” rule, which means that if you read someone’s programming, you shouldn’t see a lot of things that aren’t used in there and there shouldn’t be blocks of code commented-out when the system is finalized. Also, a number of software vendors have created industry templates where they have quite a lot of features available to the user on a separate basis from the core system. Items that are not used should not be left in. Extra items fall into the “no dead code” category. On a couple projects I worked on that managed this quite successfully, they had a separate system to hold the “template” items where a few team members could try out items to see if they should be used. Then, those items would be moved into the development version of the system. If we didn’t use them, we took them out of the development system. By doing this, it’s easier for the next person coming along to figure out what’s going on and what’s being used in there. And, after all, part of the issue is maintenance, too. People who come into a system to maintain it should see the minimum. Even when not using a “template,” you must clean out your development system, every once in awhile.

These Good Habits Are Useful For Other Reasons, Too
These work not just when someone quits, but when customers want to replace someone, either because they want to get a different rate on the consulting or because the person wasn’t performing to their expectations for the price they’re paying.

Finally
Some of you have perfectly responsible people who are doing whatever they can to create the best system for your project. Some of you don’t and you don’t realize that you don’t. It’s never too late to check on this. For those of you who claim it’s not your responsibility – that you’re paying so much money that you expect this will just be handled for you – you’re the ones usually in for the biggest surprise on this when you lose someone. Just keep in-mind that no-one minds your money and your system like you do.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/