A dangerous thing; do you damage your prospects of future business by selling your knowledge?
Contractors in knowledge industries trade on their skills and experience; these are simultaneously your stock, your toolkit and your technique. And, while a successful transaction is expected to result in some product changing hands, it's bad business to leave behind your tools. How should knowledge transfer be managed to ensure that the needs of the contract are met without handing over your marketable skills on a plate?
On the one hand there are arguments in favour of passing on project knowledge to the client. The work is theirs, bought and paid for, and comprehensive documentation is likely to be a requirement without which the project cannot be signed off. Also, the ongoing maintenance and enhancement of the solution is for the client to organise, which can only be done in possession of full information on its current status and the details of its construction.
Perhaps more importantly, the benefit to the contractor of providing a complete and well documented solution can be very great; it improves trust and client goodwill, reduces the likelihood that the client will agitate for unpaid support once the contract is over, and gives the contractor an opportunity to 'brand' their work, increasing their market visibility – all hard to quantify benefits, but very real nonetheless.
However, the realities of the cutthroat contracting world would seem to argue in favour of keeping your cards close to your chest.
Above and beyond their pure functionality, solutions embody a contractor's intellectual property and represent the accumulation of experience and skills, all too easily poached from a well-documented system.
There's an incentive to safeguard the possibility of return business; while no self-respecting contractor would deliberately leave a project or solution in such a state that the client has no alternative but to call them back in, it's undeniable that it's helpful to be the natural first choice for offers of future work as a result of your privileged understanding of the setup.
There can also be outside pressures that prevent knowledge transfer: time constraints often mean that corners must be cut in order to meet deadlines, and areas such as documentation that don't have a direct impact on the functionality of the solution are natural candidates for trimming.
The situation is particularly acute for contractors in information systems, where several factors work against you. IS, in particular web-based or Inter/intranet developments, remain largely open-box; either the source and design documentation will be a deliverable of the contract, or – as in the case of browser-based systems – the source is the delivered product. In addition, clients are often keen to minimise project costs by sidelining the contractor in favour of permanent staff at the first opportunity, as is evidenced by the continued rude health of the training market and demand for flexible, customisable solutions using public domain tools.
However, the middle way – giving enough information to make your solutions workable without making yourself redundant – can be found, and as always, balance is key.
Give ample detail when describing the system as it stands; there's a gulf of experience between the ability to grasp an existing system and the skills necessary to modify or expand it.
The client who has confidence in their current system and in their ability to maintain it will be the quickest back to the table when the issue of enhancements arises, while organisations struggling to make sense of what they have are unlikely to be thinking of adding more.
The best guarantee of future business will always be satisfaction with the current project, including its documentation; the very pace of business change provides a constant stream of work without the need for artificial stimulus. In all, quality documentation and knowledge transfer are strong cards up your sleeve when you come to play for that next contract.