Why Onboarding Matters in Projects: Decisions Made Without Context Become Risks

Project teams rarely finish with the same people they started with. A schedule slips and another developer is brought in. A partner swaps out its staff. A planner moves over from another team halfway through. And every time someone new arrives, the project hears the same question again: "Why did we decide to do it this way?"

This series starts from that question. Over three posts, I'll look at why onboarding matters so much in projects, what good onboarding actually looks like, and why play belongs at work. Where all of that thinking led me is First Run, an onboarding RPG I built for new hires and people joining a project.

Projects are made of people coming and going

When I wrote about what changed at work after the PMP, I quoted the PMBOKPMBOKProject Management Body of Knowledge: A collection of processes, best practices, terminologies, and guidelines compiled by the PMI.Read More → Guide 8th edition's definition of a project: "a temporary initiative in a unique context undertaken to create value." The word I keep connecting to onboarding is temporary.

Operational teams build up context by having the same people do the same work for a long time. Projects work differently. You gather people around a goal, the skills you need change from phase to phase, and when it's over everyone disperses. Joining isn't the exception. It's routine. And the people joining aren't all the same:

• New hires: new to the company and new to the project.
• Mid-project joiners: they know the company, but not this project's decision history.
• Vendors and partners: great at their craft, unfamiliar with how your organization works.
• People changing roles: they know the people and the company, but not the judgment calls of the new role.

All four need onboarding. Yet when we say "onboarding," most of us only picture the first group: the welcome deck, account setup, the benefits briefing. The onboarding a project needs is far more specific than that.

What happens when a new member works without context

Picture this scene. It's a made-up example to illustrate the point, not a real case.

A developer joins a project three weeks before launch. On day two, the client contact messages them directly: "Could you add one filter to the product list? It's a small thing." Wanting to be helpful, the new developer ships it in half a day. But this project agreed that scope changes go through the PM as change requests, and that one filter expands the QA scope and the UAT scenarios. A week goes by before anyone notices.

Did the new developer do something wrong? I don't think so. Most likely they knew the rule but didn't realize it applied to this exact situation, even if the onboarding doc said, in one line, "Scope changes go through the PM."

That scene contains all three costs of weak onboarding:

Cost	What it looks like	Through a PM's eyes
Repeated explanations	Every new person gets the same background from scratch	Senior people's and the PM's time drains into work nobody planned for
Slow ramp-up	Long stretches of asking and waiting because nobody knows what comes first	The time until new people are fully productive is missing from the schedule assumptions
Context-free decisions	Well-meant decisions that clash with agreed scope and process	Risks to scope, quality and schedule pile up quietly

The first two are visible. The third is the scary one. Repeated explanations only cost time, but decisions made without context quietly shift the direction of the project while nobody is looking.

The numbers say onboarding is hard

This isn't only a project problem. Across organizations, onboarding is something most people say isn't done well.

• Gallup reports that only 12% of employees strongly agree their organization does a great job onboarding new employees.
• According to SHRM, only 29% of new hires felt prepared and supported to excel in their new role.

Both figures are about new hires in general, not people joining a project midway. Still, if even new employees rarely feel ready, I'd expect someone dropped into a project that's already running to feel it even more.

Onboarding is project management work

That's why I see project onboarding not as an HR event but as something the PM should manage. Lay a PM's usual responsibilities next to onboarding and the overlap is obvious:

PM responsibility	What it means for onboarding
Resource and team management	Plan the ramp-up period along with the start date. Decide who explains what in week one
Knowledge transfer	Keep decision history, what you agreed not to do and lessons learned in a structure, not in one person's head
Stakeholder alignment	On day one, make clear who decides and whom to ask about what
Risk management	Treat a new member's ramp-up period as a risk and plan a response
Change control	Show the change request process through real situations, not just a document

The last row is the heart of this post. Explaining a procedure and helping someone recognize when it applies are two different things. What the developer in the scene needed wasn't a list of rules. It was the chance to have already lived through the moment a client says "it's a small thing" and asks for something directly.

5 things project onboarding should cover

When someone new joins a project, these are the five things I'd make sure to cover at a minimum:

1. Why: once this project is done, who will be able to do what better.
2. How far: the agreed scope, and what we agreed not to do.
3. Who decides: decision makers, communication channels and when to escalate.
4. What happens when things change: the change request process and the reason behind it.
5. How we judge common situations: what this team does first when the schedule slips, requirements collide or a quality issue shows up.

Items 1 through 4 can be handed over in documents, more or less. Item 5 is different. Judgment sinks in less through reading and more through making the call yourself. And I think it's exactly where most onboarding is weakest.

That's why I built First Run

While writing this, I kept coming back to item 5. Judgment doesn't travel well through documents, yet judgment calls are usually what shake a project. So I thought there should be a kind of onboarding where you can practice those calls in advance. That's First Run.

First Run is an onboarding RPG in which new hires and people joining a project experience real workplace situations as quests. You join Make Feelbetter, a fictional IT company, pick one of five roles (developer, PMO, publisher, planner or designer) and make decisions in quests handed out by mentor NPCs. The situations are the kind you meet at work: schedule delays, API issues, requirements, UI decisions and accessibility problems. The PMO role covers risk handling, schedule coordination and change control. The idea was simple: let people live through moments like the scene above inside a game first, instead of on a live project.

I designed First Run from my practical experience as a PMP®-certified project manager, and it can be customized for a company or a project. Project onboarding scenarios, internal workflows and common workplace situations can all become quests, so it works for project kickoff training and vendor or partner onboarding as well as for new hires.

In a project, onboarding starts over every time someone joins. If that start can be an experience instead of an explanation, I believe a new member's first decisions become a lot less risky. That's why I built First Run.

Try it yourself — the demo is free and runs in your browser on desktop or mobile, with no sign-up. Play First Run →

In the next post, I'll go one step further: why document-based onboarding doesn't stick, and what good onboarding looks like.

Frequently asked questions

How is project onboarding different from new-hire onboarding?+

New-hire onboarding helps someone settle into a company and its culture. Project onboarding helps someone quickly learn a running project: its goals, scope, decision makers, change process and how the team judges common situations. Even people who have been at the company for years need project onboarding when they join a new project.

Is the First Run demo free?+

Yes. It runs in a web browser on desktop and mobile with no sign-up or payment. Progress in the public demo is saved only in that browser, with no account.

Can First Run be customized for our project?+

Yes. A custom version can be built from your real work scenarios and project rules, with NPCs modeled on your mentors, your office map and your branding. You can request it through the contact page on firstrun.fit.

Sources

• Gallup: Why the Onboarding Experience Is Key for Retention
• SHRM: Complete Employee Onboarding Guide
• First Run: Custom Game-Based Onboarding RPG