Most consultants dread this part of the process as it often requires mounds of documentation and tons of meetings with seemingly little accomplished.  Even after the process is completed, many consultants will still get a follow up call from the client six months later when the developer who was supposed to take over their project has left for greener pastures.

There are many reasons why consultant-developed software often follows this pattern.  Firstly, most clients are plagued with the inability to identify a suitable maintenance resource in a timely manner.  Often this important task is put off until the last minute thus reducing the quality of resources that can be found to take over the project.  Also if the client’s resource is tasked with learning the code base in a very short time, they often don’t get enough information and are overwhelmed when they are expected to deliver a round of enhancements soon after the consultant leaves.

To increase the chances of a successful hand off, the client resource should be identified soon after the project enters its testing phase to ensure that they have sufficient time to get up to speed.  Also it can help to let the hand-off resource take a crack at some of the lower priority bugs that inevitably creep up so that they get familiar with the code.  Having them get their hands dirty when the consultant is still around to support them can be extremely valuable to the client.

Consultants should also make every effort to develop a maintainable solution that can easily be transitioned.  A complex custom application framework, a cutting edge technology, or an unfamiliar platform can all reduce the client’s chances of successfully maintaining their shiny new application.  While it can be appealing to try a new technology or build a new skill set, such decisions often create unnecessary risks for the client and their resources.

So does this mean that consultants should simplify their architectures to Typed DataSets and drag-and-drop GridViews?  Not necessarily. 

Even with the most non-technical clients, a consultant should take the time to explain the important architectural decisions in ways where the risks and rewards are absolutely clear to the client. If a technical decision is made that reduces development time but requires a specialized resource, then the risks and reward of such a decision should be clearly communicated to the client before it’s too late to turn back.  Projects often fail because of technical decisions that were made up front later on became extremely costly to support and were ultimately irreversible without re-writing large parts of the application.

Finally, consultants should beware of clients that expect to just pay an invoice and get some working software with very little personal involvement in the project.  No matter how much they may profess that they “just want something that works” they will have always opinions on how it should work. So a consultant is better off setting their expectations of the client’s involvement as early as possible. This will ensure both a healthy development cycle for the project and help transition it to a capable maintenance resource that can support any future needs.