How to hand off a project without infuriating the next engineer

Handing off a project to another engineer can be daunting. Aside from the personal attachment (the project is your baby), it can be difficult to articulate where the project has been and where it needs to go. My background is in design engineering for the retail fixture industry, so I have worked for companies that are project based, not product based.

129308073149

Challenges

During that time, I have had to hand over many of my projects to other engineers. To me, the big challenge with handing off a project to another engineer is not the amount of information you need to provide them, it’s how disorganized the information you already have most likely is. Depending on how far along you have taken the project, it may have been changed several times before the “new” engineer even begins to look at it.

Several meeting notes, emails, and other fragmented bits of information are already in your possession (in different formats), and it is important that you get all of that information transferred to the replacing engineer. For efficiency’s sake, you will need to organize this information in a way that makes it easy to understand.

Pre-Meeting Email

When transferring a project, the first thing I do is organize the information about the project into an email and deliver it to the new engineer. The purpose of this initial “kickoff email” is to get the “new” engineer more familiar with the project before we sit down and discuss the finer details. I try to keep this initial email somewhat brief and focused on the facts, not what you inferred from design discussions up to that point.

This is a great time to send them the location of any of the engineering files that you currently have. They should all be on Workbench anyway, so that’s easy. Additionally, you should send everything to them at least 30-60 minutes before discussing the project in-person. You want to give them time to poke around the project before you meet up with them.

The kickoff email does two things. First, it provides the new engineer with a first look at the project before you meet up, allowing them to begin to process the project before you sit down. Second, the email will serve as a place to go back to look over after you meet, which helps them remember some of the details down the road. It’s not exactly a single source of truth, but it’s close. When you sit down to discuss the project, hopefully the new engineer will have read the email, processed it, and are coming in with their questions ready.

During the meeting

During the meeting, try to focus your discussion on the design intent of the project, not the design itself. If you’re truly handing this project over to another engineer, the intent is what they really need. If you try to tell them how to design the project, it will hobble them. Empower them instead. Explain how you got where you are, and let the replacing engineer ask questions about the design. The more information you can provide to the engineer about the goals of the project, without telling him or her how it needs to be made, the better he or she can do their job.

After the meeting

After the meeting, email an actionable summary to the engineer afterward. List key points that were discussed during the meeting, as well as what action steps need to be taken to move forward. This may sound like overkill, but it is important because it helps keep everyone on the same page after the meeting. In-person discussions are non-linear in nature, (which is why they are sometimes better than emailing), but it is best to organize the thoughts into an email for future reference.

Why all the emails? Two reasons. First, organizing this information into a neat and clean closing email will allow them to focus more on the design, and less on remembering details. Second, this closing email can be used to build a task list from.

Think of yourself as a wrangler

When you’re handing off a project to someone else, think of yourself as a wrangler. Your purpose at that moment is to wrangle up the fragmented bits of information, parse through them, package it all up and hand it off to the new engineer in the most organized way possible. If you hand the project off correctly, you won’t have to answer as many questions down the road. That will save both you and your fellow engineer a lot of time, and reduce the interruptions you have throughout the day.


 

  • Anton Tsyopa

    Alex, thanks.

  • Good thinking Alex. You could think of the first Email as an ‘Agenda’ and the second Email as ‘minutes’.

    It’s a good idea to keep a note of the headings that you use in your handover Emails. Over time you may come to see a pattern and you can set up a template file that covers the main points to help you jog your memory.

    Have you ever worked with an online task list system? We’ve been working with one called ‘Asana’. In this case, you put all your tasks into Asana as you go. If you need to hand over the project, you can assign all your related tasks to the person you are handing over too.

    It still needs you to explain what’s on the list to give it some context, but it saves having to trawl through old emails to formulate a task list. It’s all there and all current…

    Interesting stuff!

    • Hey Paul!

      All good points. I have never worked with Asana before, but it sounds interesting. I like that it is focused on putting tasks in as you go instead of trying to follow a strict set of steps to get through a process.