Onboarding of Project Team Members

Have you ever found yourself in a situation where you didn’t have the information you needed to make informed decisions? You didn’t even know who could help you or answer your questions? This has happened to me in the past when I have been asked to lead a project through to completion and it’s already underway. I walked in the door and everyone was expecting me to pick up the ball and drive this play into the endzone on my first day. That message was pretty clear to me. Unfortunately, what wasn’t clear was the project.

No one took the time to review the project with me. What is the scope of the project, what are the deliverables, what are the high-level risks that have been identified, who is on the project team, how are we working together as a team – local, co-located, virtual? Where are the project documents – is there a network drive or a Sharepoint site that I should have access to? Can someone walk me through the key communication deliverables that I will now be responsible for? Is there a schedule? Who are the end users and how will they be impacted by the change?

Nope. Nothing. Zip.

I remember this one particular project very vividly because I captured my first lesson learned for this effort by the end of my first day: Never allow this to happen to anyone else.

It was the next day that I started pulling together my notes on developing a process for onboarding new team members. I was able to use my experience, for this particular project, and write down everything that I did in ramping up on the project activities – what questions I asked, what technology was being used, what systems I needed to gain access to, who the contact people were for answers to my questions. I worked tirelessly trying to ramp up on all of the project details so that I could have an informed discussion with the project team. Sadly, there were a number of project team members that were getting frustrated with me at the same time. I was juggling fast but, apparently, not fast enough. Another lesson learned: Part of the project team onboarding process should include engagement from the other project team members to help bring the new team member up to speed with activities, issues and anything that may not have been documented but would be good information to have. As you can imagine there were a lot of lessons learned with this project effort.

The organization that I worked for did not have a process in place for onboarding new project team members so it was left to the individual Project Managers to develop their own processes for their teams. Developing an onboarding program for your project effort may not be as critical if you have a short-term project. However, when you are leading a project with an anticipated 2-3 year lifecycle (or more!) you should have an onboarding program in place. You never know, it could be used for the next Project Manager!

I remember this one particular project very vividly because I captured my first lesson learned for this effort by the end of my first day: Never allow this to happen to anyone else.

Here are some of the high-level process steps that I included into the onboarding of new project team members. There are some variations in the process steps depending on the role of the team member, whether they are a consultant or a staff member or if they are an existing staff member vs. just joining the company. I have noted those variations in this checklist:

• New Project Manager
  • Meet with Project Sponsor to review the project efforts, scope, best practices and internal project protocols with respect to communication, reporting and monitoring.
  • Meet with the Project Team, to review the project deliverables, roles and responsibilities, progress, any urgent issues or challenges and communication needs.
  • Meet with the IT team to review systems and access needed, network drives and any other project related technology needs. (consultant, new staff)
  • Upon review of the meetings above create an action item list that will include the following elements:
    • Address any urgent issues as soon as possible.
    • Project management documents – are they all present and accounted for? Are they accurate? Have they been effectively communicated to the organization?
    • Project management processes – are there best practices that are being used and adhered to with respect to the project approach or methods? (consultant, new staff)
• Project Sponsor (usually existing staff)
  • The Project Manager will meet with the new Project Sponsor once identified. Review the project scope, risks assessments, budget, schedule, project team, control elements, urgent or challenging issues and communication needs.
• Project Team Member (consultant, existing staff or new staff)
  • Meet with the Project Manager to review the project, the roles and responsibilities, best practices, project lifecycle, reporting needs, skill development needs, any special needs and technology. (consultant, existing staff or new staff)
  • Meet with the Project Team to further define roles and responsibilities, hand-offs and to gain some insights into the workings of the team. (consultant, existing staff or new staff)
  • Meet with the IT team to gain access to the required systems needed for the role. (consultant, existing staff or new staff)

I suggest that you can start with these foundational process steps and add any organizational steps that may be required. At the very least, have a comprehensive outline, that everyone can access, so that incoming Project Team members can be onboarded with consistency. Don’t leave onboarding to the new team members to tackle on their own, help them be successful.

Give them the tools to be successful.