This is how successful project managers onboard new projects

As a freelance project manager, I’ve jumped into projects at almost any phase: from projects a few days away from launching or kickoffs right after proposals are accepted, I’ve been a part of it all.

Jumping into the thick of a project means getting up to speed on lots of things very quickly, and that transition is only improved by lots of transparency. If not, gathering all of that institutional knowledge becomes a burden to the project manager and an obstacle for the whole team.

Most of the time, I realize I need access, knowledge, or context as it becomes relevant during my project ramp-up. It’s fairly typical of project owners and stakeholders to give basic context to a project right away: access to project-specific files, project management system logins, and maybe even SOW or creative brief info.

But that’s only just a starting point—so much knowledge lies under the surface when projects are taken over by a new team member. I’ve realized the context and access I need is pretty consistent throughout projects, regardless of type of project or project phase.

Here are some of the biggest issues I’ve learned to anticipate when onboarding onto new projects:

I have no idea where a file or website lives.

When I’m new to a project, I’m not yet familiar with project URLs, project specific file systems, and asset or repo paths. If you’re talking about a website that was launched last year and is part of a related project, I won’t know a website or project by the client name or acronym—so be specific and provide context when communicating about these things.

Similarly, provide file paths for documents (Google Docs, SOWs or assets that live within any sort of file system), repos (especially server environment specific repos), and subject line/date info for email threads (so that I know if I’ve been CCed or not). You’d be surprised how frequently this is forgotten and how difficult it is to get proper context for simple things like a website URL.

I don’t have access to all of the things I need to make intelligent project decisions.

If I don’t have access to your calendar, the company wiki, information for the preferred conferencing tool or teleconference line, CMS admin access, invoice management account access, or more, I can’t properly schedule meetings, troubleshoot issues before going to the development team, or pull project time reports.

It is totally possible, but so difficult, to PM in a partial vacuum. Sometimes it’s just not realistic to get access to a client contract, financial information, direct client meetings, or certain password info—and that is fine. But push the limitations of what IS shareable and help any new freelance project manager gain access to as much operational, administrative project-specific information as possible.

All of these items provide me with a whole picture of health for a project—especially important for projects mid-phase—so I want as much upfront access as possible.

Jargon and project-specific language is confusing.

It’s impossible for me to de-code jargon when things are moving fast and furious on a project. Explain any frequent acronym or jargon-y terms to me when I start on a project, and continue providing that context in communications for a good amount of time after I’m integrated into a project.

Providing clear, jargon-free communication during onboarding is very important to the overall clarity of project transitions and communication.

Clarify roles and don’t make assumptions about my skills.

It’s often assumed that since I’m a project manager, I operate exactly like the last PM who worked in my position—but that’s rarely true. I clearly communicate my role with my team as soon as I start, and provide an understanding of my limitations (and also my skills), expectations, and availability with everyone as early into a project as I can.

It’s helpful to have this conversation with team leads and stakeholders ahead of time, so everyone’s aware of what role I play—and what role I expect from them—on a project, and we can have longer discussions regarding this earlier if needed.

It can be overwhelming to jump into a new project midway through, but knowing the obstacles you will face helps. Project onboarding does not have to be a long or intense process—with the right tools, communication, and planning, any freelance project manager can jump into a project in the most chaotic of positions and start making a difference immediately.

So if you’re about to start a new contract and project, I hope these experiences help you with your onboarding experience.

At the very least you’ll be armed with an idea of what steps you and your team will need to take as you get started—and the rest will be business as usual. And if you have a revelation or experience that isn’t included on this list, feel free to reach out!