6 Steps to A Successful Handover
Praekelt.org has developed two large scale maternal health platforms in two distinct countries: HelloMama in Nigeria and FamilyConnect in Uganda. Recently, we have begun handing over these platforms to local partners. Handovers can be quite exciting for us, especially since it’s a sign of a successful technology launch: the idea that the platform becomes locally sustainable.
We spoke to some of the people involved and wanted to share some of the lessons we learned.
1)Processes over individual pieces
While it is easy for us to document individual pieces, the processes involved to link up these pieces is not always obvious. For example, for our engineers, explaining our tools like Junebug and RapidPro is more straightforward than explaining how they work together. But these kinds of processes are what partners are really most interested in learning about.
Our Head of SRE, Bearnard Hibbins, explained, “At first we just documented some of the technologies we use and what applications run. We didn’t really give them a step-by-step. We realised then that they may not understand what all these “about documents” were so we ended up going into deeper documentation about “how to” such as how to deploy an application or how to deploy the infrastructure from scratch.”
Processes can also be tricky to document as it’s important to achieve the correct level of detail. Our Head of Strategy & Experience Design (SxD), Pippa Yeats, compared “how-to” documents to recipes. “Recipes can come out differently, so how do you ensure consistency?” Testing process documentation is important to ensuring its usefulness.
2) Demos as documentation
While written documents are the most common form of documentation, other media can work well too, especially for less technical users. Consider using video or animated GIF tutorials to explain common tasks. Videos and animations can be more engaging and can help familiarise users with a software interface.
One of the third-party tools we use, Redash, does a very good job of this. Throughout their documentation they use animated GIFs to show how to perform common tasks.
The easier the user interface, the easier it is to demo. Certain processes in our system are difficult to explain on paper necessitating a demonstration. An example is adding a new channel to Junebug. The process involves interaction with Junebug’s API, and while accessing the API using common command-line tools is not complex, it would have been easier to demonstrate using a web interface. Creating a video recording of some command-line interaction is possible, but the video is likely to be less engaging than that of a graphical interface.
On the other hand, our container management system, Mission Control, has a friendly user interface and was very straightforward to demonstrate:
3) Design for admins, not just end-users
One of the issues we ran into when workshopping the management of our maternal health platform is that we had designed a very general purpose platform for managing these services. This meant that a lot of the language we used in the admin interfaces for the platform were very general, abstract phrases (e.g. “identity”, “profile”, “subscription”) that were difficult for users to relate to their practical applications.
Another issue was that the admin user interface exposed too much information and too many options that many users were not interested in, making it harder for them to find the things they were interested in. This lead to users struggling to figure out how to achieve tasks they wanted to, even though the tools were available.
Our SxD team uses Human-Centered Design (HCD) to develop the services that our end users interact with and this involves significant user testing which would avoid these kinds of issues before the service reaches production.
“The things that are relevant to ‘tech people’ are different to ‘programme people’”, said Pippa. “For example tech people care about things like failed calls because we want to know if there is a technical problem or a spam caller or something. But programme people just want to know things like how many users are registered.”
After our experiences in the first workshop, we redesigned parts of the admin front-end to only expose information and options relevant to specific users on each page and updated some of the language to be more precise. An earlier, user-centered design phase when developing this interface would have been beneficial.
4) Question assumptions and document limitations
One of our developers, Erik Harding, described his approach to writing documentation as “you need to look at it like you’re looking at it for the first time.”
While our engineers may understand how to operate the system just by inspecting its various components and configurations, this is not practical for the partner. Translating this existing knowledge into shareable documentation was critical to the handover process.
Pippa emphasised the importance of documenting the processes we used to get where we were and the assumptions that were in place. She also spoke about being upfront about both the capabilities and limitations of a tool. “I think a lot of documentation talks about what the tool can do but not enough about what it can’t. For example, Redash has a six column layout and we can’t do more than that.”
5) Build the partner’s confidence
Handovers are not only about communicating knowledge, but about giving partners confidence. In each meeting for the handover, we would explain some parts of the system and after each meeting the partner would have further questions. We created and lead our meetings and documentation based on their questions. Through a series of discussions and demos, we were able to iterate on the knowledge we shared and the partner was able to build confidence with the system.
We learnt another important lesson when training a partner on how to use Redash. Redash is able to produce dashboards and visualisations from a database using SQL queries. At first, we tried to explain the SQL queries we used in Redash but these large chunks of SQL code were quite intimidating to many of the people involved.
We reassessed and changed the order of our lessons so that we started out with the dashboards and visualisations this code produced. In doing so, we showed the partner the potential of what they could achieve with the tool, which made them excited to learn about how to use it. By the end of the training the partner was excited to use Redash — even for problems they had outside of the project we were handing over.
6) Set expectations before the handover
Handing over such a large system leaves partners with a lot to learn within the timespan of the handover process. Bearnard emphasised the importance of the partner having some processes and technical skills in place before beginning the handover. “It’s better to have as part of a contractual handover — to say that you need to become proficient in these things — which would make the handover smoother.”.
In this case, the partner wasn’t experienced with the modern “DevOps” practices that the SRE team uses. While the partner had researched some technologies used in the system — such as Docker — beforehand, there were still some fundamental technologies we needed to bring them up to speed with.
Obviously, it would be impossible to expect a partner to have perfect knowledge of all of our technology beforehand, but reaching an agreement about how much they should know can save both parties time. “In the handover process there should be an official procedure that takes into account the experience of the people we are handing over to.”
Pippa discussed the importance of planning for the necessary skills to manage a platform ahead of time. “Each year there was a planning session for HelloMama. The year of the handover it should have been possible to determine which skills the partner should build capacity for, in order to better support the platform.”
Having deliberate processes which take into account and plan for the partner’s expertise are key to a successful handover. Handovers can help an organisation learn how to teach others about its products and in doing so improve documentation techniques and design processes. Over the next few weeks, we’ll hear more about our handovers from several other perspectives as well. Check them out on our Mobile For Good publication.
Authored by the Praekelt.org team
