“First, just let me say that I’m touched that you enjoyed my services so much that you want to continue our relationship long after the engagement has closed. Flattered, even. Still, for a freelance contractor, time is money, and you’re not paying me for mine any more, so at some point this has to stop. It’s not you, it’s me, I’m sure you understand.”
The above is a conversation I’ve had to have with clients time and time again, although not in those exact words, of course. Often, I later realized, it actually was my fault. In the early days of my career, I wasn’t providing clients with enough of an end-to-end solution. I short-sightedly forgot that when you’re transferring IP, it’s important to make sure that the client (and all of the client’s staff who will be involved) will be able to use whatever it is I’ve produced for them, for as long as the tool is in active use.
What that shouldn’t mean is that I end up acting as tech support for the rest of my days. What it should mean is that I provide them with enough resources up front that they don’t have to call me every five seconds to ask how to change or update something. Here are some tools you should provide to help make the handover as one-way as possible.
Preferably generated through actual use cases and interactions with client staff. For example, if you’re providing a client with a web site, these might be questions that they themselves will receive from clients, like “What is the optimal browser for viewing the site?”, or they might be questions that client staff have about the update/modification process, like “What size images work best for the site’s homepage?”
You’ve seen them, you’ve used them, now it’s time to make one. A user guide is an invaluable tool for any kind of deliverable you may be producing for a client. Usually, user guides are living documents and will continue to grow and be added to by client staff.
My advice for producing these is to start with a best-in-class survey, so dust off those that you’ve received packed with software, hardware, etc. and get a feel for the genre. Also, try to strike a balance, if possible, between visual and textual learners, by providing both ample descriptions and screenshots where appropriate. Also, use Clear Writing principles to maximize readability.
Quick Reference Card
Chances are, the people you’re turning over your deliverable to are no more inclined to read through an exhaustive manual or guide to find out what they want then you are. Hence the beauty of the Quick Reference Card. There are plenty of these documents available online, so it isn’t hard to find reference documents to work from.
The danger here is to go overboard and try to provide too much information. Remember, it isn’t supposed to be a manual.
You can also provide different versions of these documents for different stakeholders. Someone producing content might need a flow chart outlining the content approval process, for example, while someone responsible for changing code might need a basic HTML reference.
It can be hard to anticipate every possible question that a client will have after the project is handed over, but after a while you’ll get used to guessing the kinds of things they’ll expect answers to, and all of the above documents will be the better for it. Even if you’re not a pro, though, start using these documents and I promise your phone will ring less, or at least less for the wrong reasons and more for the right ones.
What strategies do you use for minimizing support after handing over your projects? Is some support inevitable?