Tasleemat Forms Guide

Project Artifact: Team Onboarding Checklist

Document Reference: PMO-05.12

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Team Onboarding Checklist in alignment with the Tasleemat framework.

1. What?

A table of the steps that have to happen before somebody can be useful, one row each: the task written so its completion is checkable, who does it, when it should be done, and whether it is done. The dates are relative to the joining date rather than to a calendar day, because the joining date moves and a checklist full of fixed dates has to be redone every time it does.

2. Why?

Because the steps that are missed are the ones nobody can see are missing. A new member without access does not raise a problem, they sit quietly, and the team's interpretation is that they are taking a while to settle. Written down, the same list serves the second person, the fifth person and the person who joined while two others were on leave.

3. When?

Started on the joining date and closed when the last entry is done, which is normally the end of the first week. It is also reopened whenever somebody joins mid-cycle, because the checklist is per person and not per project, and a checklist written for the first joiner is not automatically true for the second.

4. Who?

Owned by whoever is responsible for the new member's first week, which on most projects is the team lead rather than the project manager. That is worth being explicit about, because the tasks themselves mostly belong to other people: access is granted by whoever administers it, the tooling introduction is given by whoever knows it best, and neither of them is the team lead. The checklist exists so that the team lead knows they have been asked.

Tailoring Tips

Write what done looks like, not what to do. A task nobody can mark as complete is a task nobody completes, and "get set up" is the commonest example of one.
Name the one-off. Most of these are a single action by a single person, and the step that gets missed is almost always one that belongs to somebody outside the team who was never told.
Close the checklist. The last entry is the one that says the onboarding is finished, and without it the list has no end and the status column stops meaning anything.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Project Management Plan (PMO-04.01.01)
- Approved Baselines: Scope (PMO-04.02.05), Schedule (PMO-04.03.08), Cost (PMO-04.04.04)
Optional / Contextual:
- Risk Register (PMO-04.08.02)
- Stakeholder Engagement Plan (PMO-04.10.01)

2. Downstream Dependents

Mandatory:
- Project Status Report (PMO-06.01)
- Change Log (PMO-05.04)
- Lessons Learned Summary (PMO-07.01)
Optional / Contextual:
- Variance Analysis (PMO-06.04)
- Decision Log (PMO-05.02)

5. How?

To accurately complete the Team Onboarding Checklist, populate the following sections based on the project context (ensuring reference to parameters.md for the general project variables):

Task: The activity, written so that a person who does not know the project can tell whether it is done. "Get set up" is not a task; "reviewed the onboarding document" is.
Assigned To: Who does it, which is not the same as who is waiting for it. Most onboarding tasks are somebody's one-off action, and naming the one-off is what stops the new member chasing something nobody owns.
Due Date: When it should be complete, relative to the joining date rather than to a calendar day, because the joining date moves and a checklist full of fixed dates has to be redone when it does.
Status: Done or pending, and the date it was done. A checklist nobody updates is one that has quietly stopped being true, and the entry is what shows it has.

Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 05_12_Team_Onboarding_Checklist_Example.md