top of page
  • Writer's pictureJosh

Templates | The Handoffs Have Eyes

Updated: May 25

Note: The template being shared was created while one of us was an employee of an organization for that organization. As a result, that company has the copyright to this document. We are presenting this document for educational purposes only, under Fair-Use. All questions that are included in the examples have been removed and rewritten in order to prevent individuals from identifying the organization that holds the copyright.


base template
.docx
Download DOCX • 32KB

Recently, I had a lovely morning at Top Golf with a friend who is a technical handoff specialist for a major software supplier. His role is to lead classes on how to use these new systems and head up one on one training. I asked him what the one thing he hated the most about his position was, and he said the feedback… oh my god the feedback.


In his position, after the training and feedback are done, he meets with the client’s managers, the project manager, and usually someone from the development team to discuss how the handoff process went. It takes hours. Originally, they decided to streamline the system by sending daily emails. The problem was, the emails would take an hour or more in the afternoon to ensure that everything was covered, and even then the wrap-up meeting still took several hours.


My solution to him was to implement something similar to what I did when I too was a hand-off specialist for a major snack food company. Templates.


When you are training individuals, classroom, or one on one, there are always things that you are going to need to cover and need to document in some way. While working for this company, we would frequently spend 12+ hours training people, then drive back to the hotel and spend hours writing up our feedback for the day. It was crazy. So I created a template with the pertinent questions, took that template, and created an editable PDF, where a handoff specialist could just take their tablet, check the correct boxes, provide a summary and feedback, and email it off.


How is this different than just an email? Well, you can fill it out as the day progresses, rather than waiting until the end of the day. Secondly, it’s so much easier to read than a huge block of text. Even the most dedicated of PMs/managers are going to read every word of your painfully verbose email, so having a checklist that they can quickly review becomes a quick way to communicate without causing any hiccups. Thirdly, it allows you to cater to what feedback you include. In our example, we have a summary section so that you can get all verbose if you really want to, plus a section for successes with the handoff, and one for future opportunities. One of the problems with the handoff review session is discussing what could be done better, adding this allows you to have a running, day-by-day document of things you saw that were successful and what was a failure.

So, let’s get into it.


Creating Your First Handoff Template

“Fuck man, where do we even start off? Getting everything down in one document that we need is a daunting task.”


Yeah, believe me, I know. Creating the initial feedback forms was a weeks-long process, where I would spend hours in the evening getting everything put together, designed, organized, and converted to a PDF that had fields that could be checked off and updated. By the end of my time as a handoff specialist, I had created 14 templates in total and handled anywhere from two to six different versions of each template.


I’m somewhat of a masochist, apparently.


Looking back, it did not have to be as difficult as I made it. The problem I had was I was trying to handle this all myself. The first step is:


Engage Everyone

One of the keys to developing a successful handoff document is to make sure that everything that needs to be covered, is.


When determining who should be asked for input, ask yourself “who would benefit from this information.” One thing that I hadn’t thought about when initially creating my documents, was feedback regarding the user experience. If I had first thought about who could benefit from my feedback from the handoff, I would have potentially identified that the UX team needs that firsthand feedback so they can enhance their product.


Frequently, this tends to be harder than I am letting on if I’m being honest. A lot of times everyone is going to have input, and not all input is that vital. Further complicating things is the issue of multiple people wanting basically the same information, only presenting it in a slightly different way, which gives the illusion of the question being different. How do you deal with this?


Categorize, Tag, Identify, Compare

Take all of the questions that you’ve written down somewhere and categorize them. Some examples of categorization include steps in the process, time of day, system specific, etc. Next, tag them. Tags should be generic enough that they can apply to multiple questions, but specific enough that they will show how something is different. Next, identify the questions that are superfluous, and can be removed. When you see the questions all next to each other, categorized and tagged, it becomes obvious what questions can be removed. Finally, compare what is left to ensure that there are no repeat questions.


For example:

  • Category: Handheld Processes

    • Question: can the user quickly find the warehouse map in the handheld?

      • Tag: user experience/user interface, efficiency

      • Result: add to form

    • Question: is the map able to be read by the user

      • Tag: user experience/user interface

      • Result: remove/superfluous

    • Question: can the user get to the map in fewer than 5 clicks

      • Tag: user experience/user interface, efficiency

      • Result: repeat question, remove.

Deciding on a Layout and Form Type

There are key features you are going to want to include with your project handoff template. With our example, we have a header that is used to call out the type of handoff we are doing (inventory system one on one). Below that, we have key project information: the project manager’s name, the project name, the project ID, the handoff specialist's name, the trainee, and the date. Depending on the type of feedback form you are handling, the trainee can include different information. If it’s a class setting, you might include what class it was, what wave of training it was, or the time of the meeting.


Next, you are going to want to have a way to check what is being observed, and the result of that observation. We recommend having a dedicated area on the left side of the document to have these checkboxes. Our examples all use a Yes, No, and N/A box. Right of these boxes is the questions you are looking to observe.


In our first example of an inventory system, we decided to split the questions into specific time-of-day observations.

~~~~~~

You will see that our questions are numbered. This is entirely optional but was included to make my life easier. As the master of the documents, having numbered questions allowed me to identify problem questions. As I received feedback from the other handoff specialists, I could quickly make updates as needed.


Next, we included a section for a summary. Do you need a summary section? No, probably not. Can it be helpful? Yeah, probably. Summary sections can be very helpful for times when there is nuance to the feedback. Since things don’t always go smoothly, having a section for a summary of what was observed can mean the difference between someone looking very bad, and someone just having bad luck.


Lastly, my two favorite sections: handoff successes, and future opportunities. From the perspective of the PM, this information can make a world of difference. This information can be pulled from the individual being trained, or it can be something that was observed by the specialist. Either way, including this in your feedback will help the PM, as well as potentially identify things that the client will need to follow up on, and most importantly will save you time during the wrap-up meeting.

Example 2

Before we get into the form type you will be using, allow us to present you a second example. In this example, we are looking at a feedback form from a class training session.

There is one thing that we would like to call out, and that is the use of color. In the one on one training, we used a pallet of reds. In the classroom training, we opted for a blue pallet.


Why?


Well, consistent coloring makes it easier to identify what the topic of feedback is. If classroom training is always blue, then when you open up a feedback form and see that it’s blue, you know that it’s a classroom training form.


Makes sense, yeah?

In the header, you will notice that the only changes that were made were the handoff specialist, and the trainee (changed to class). Calling this out is very important, as we want to stress the fact that consistency is the key to success. Namely, make sure your documents all have the same project name and ID, thereby making it easy to determine what documents belong together.


The Form Type

When I implemented these documents, I chose to make them into an editable PDF. Why? Because it ensured that the other specialists didn’t go and alter the wording of the questions or change the order of any question. It was standardized and needed to stay standardized. It also made for a quick click-and-done process.


On the PDF, we had text boxes for everything except for the checkboxes.

I created the documents in Microsoft Word because it was easier to create them in Word and import them into Adobe Acrobat than doing everything in Acrobat. It allowed me to be a bit more creative with how it was being implemented.


There are other types you can use, however. You might choose to do it all in Word, Google Docs, or any of your favorite word processors. You can use Excel or another spreadsheet software. You can even create a web form, which is what my handoff specialist friend decided to do. Using a simple drag-and-drop website creator, he was able to create a website that would allow everyone to fill in the responses, the same as I did with the PDF. The benefit of using a website was the ability to have a dropdown box for all of the active projects. Once selected it would automatically fill in the project manager and project ID. No worrying about different ways these would be worded, crisis averted.


Strategies and Takeaways

A strategy that we touched on but didn’t really go into detail is how generic you should make your questions. The goal of having a template is to be able to reuse the template over and over again, without having to do a brand new template for every single handoff. I know that we are suggesting making the questions generic and specific at the same time, sorry (we like to be contrary).


One strategy that was suggested to me when I initially created these was to allow users to append questions. What was decided upon was creating a document that had all of the generic questions that needed to be answered every time, and then a separate (significantly shorter) document that would focus on project-specific questions. It was pretty easy to implement and kept everyone happy.


A key takeaway from this that we at Astutely Obtuse really want to stress is that consistency is so incredibly important to the success of a project. Using templates to be able to encourage that consistency can make or break a project. This includes the part of the project that no one really likes, the handoff. Yes, you will still need to have a recap, but a simple template can lay a firm groundwork for that wrap-up, thereby making it significantly more efficient.

0 comments

Recent Posts

See All

Comentarios


bottom of page