Early Handover and Knowledge Transfer

If you’re a third-party software developer, handing over software to be operationalised and maintained by your client can be challenging; even if you build a piece of technology that’s functionally ideal for the intended problem, there is no value if it cannot run and thrive after you’ve handed it over. Ultimately, the business will be the one to support and maintain the product and it’s crucial that they understand the system at least as well as the team that built it, if not better. Projects in which a full handover occurs at the end of the project can cause a large strain on the receiving team, who must not only ensure they have the requisite skills to operate the software but must also have a deep understanding of the problems the software solves and the context which led to decisions being made about how it was shaped over time. This is especially important in innovative projects, where a large amount of discovery happens throughout the lifecycle of the project.

To combat this, handovers should start early in the project and happen in small increments as the project progresses—ideally with collaboration between technical team members from both sides on building the system in question. This gives the development team more feedback to iterate on, surfaces deployment issues during the project, reduces the steepness of the client’s learning curve, and helps turn the client into an expert on the piece of software they’ve just bought.

Start Early

The more feedback available to a team of engineers early in a project’s life cycle the faster they can narrow in on what the client is really after. Requirements elicitation is essential to the success of the project and the reduction of doubling up on work but can be quite difficult in a sit-down meeting which is often the only catalyst for these conversations. While this format cannot be forgone completely, meetings of this kind should start to be replaced with product demonstrations as early in the project as possible. Having some version of the software in their hands, even an incomplete one, greatly increases the chance that clients will interact with it and engage proactively with the developers.

Build Interactive Prototypes

Building these early prototypes can at times seem to be at odds with the most efficient path to completing the project, but it is important to keep in mind that not all engineering effort should be put towards building the product. Much of a development team’s time needs to be focused on figuring out what product they actually need to build. Early in the project, it is of greater benefit to build something as fast as possible rather than necessarily coming up with the most elegant or robust solution. These prototypes should be designed to illustrate ideas rather than be complete and most importantly, the demonstration of these early prototypes should value interactivity and engagement with the client over usual metrics like robustness or code quality.

Seek Out Feedback

It pays to be open with the purpose of these demonstrations. The temptation when showing work to a client can be to try to mask the current shortcomings of the system, but honesty about what still needs to be done will start to build trust between the development team and the client. While it’s important to convey the fact that progress is being made, it’s more important to ensure that the client is forthcoming with feedback. Letting a client know that they are being shown an early prototype while it still has a few limitations, because their input has value to the developers, will put them in a position to provide more beneficial feedback.

Move Deployment

There are almost always issues found when it comes time for the client to deploy software on their own infrastructure. These can range from limitations of the final production environment which require some rework, to transferring the nuances of the deployment process to the client.  If these issues are found after the project has ended because the choice was made to end with a single handover event then extra work is created for the development team. The team is still obligated to help their client solve these problems. If the client is asked to deploy the system to their own infrastructure early in the project, these problems become part the normal phase of work and there’s less rush to find a solution. Both parties are also afforded with more time to exchange tacit knowledge which can’t always be articulated in a document.

Build Incrementally

It’s going to take the client a while to fully understand the piece of software they just bought and trying to learn it all at once is going to be intimidating. If the process of explaining the system starts early this learning can be broken into smaller more manageable chunks. Another consideration to make here is why the engineering team is making particular design choices, particularly around deployment. If the team decides to pick a deployment framework they have experience with to make their lives easier, but the client now has to deal with a steeper learning curve, then have they really made the best choice? Sometimes a sub-optimal solution can be a better one if it helps the client learn to support their system faster.

Embed the Client into Your Team

Straight after a new piece of software is written the best people to support that software are always going to be the team that built it. Unfortunately, they’re not the ones who’ll end up with the job. If an engineering team embeds members of the client’s team into their own by giving them small development tasks, the client can build that level of expertise the same way the engineers do. This is another great opportunity to pass on the tacit project knowledge that can only really be learnt by interacting directly with the code and to help the client team build their skillset to the point where they can make small changes to the software after the product has been released. Working on a project day to day also forces them to practice its deployment much more regularly.

Conclusion

Software developers shouldn’t want to just build a piece of software which solves a given use case. They need to develop a solution which can also be supported, maintained, and even extended, by their client. Handing over early, incrementally, and often means more feedback, more time to solve deployment issues, a less intimidating learning curve for the client, and helps the client achieve the same level of expertise about their product as the engineers who built it.