Onboarding als Projekt: wo das Projekttool reicht und wo nicht

In Firmen, die in Projekten arbeiten, landet das Onboarding früher oder später im Projekttool. Jemand legt ein Projekt „Onboarding Jonas" an, kopiert die Vorlage vom letzten Mal, und aus der Excel-Liste werden Aufgaben mit Namen, Datum und Status. Das ist ein echter Fortschritt, und die Anbieter von Planner, Asana, Jira und anderen beschreiben diesen Weg nicht ohne Grund in ihren eigenen Ratgebern.

Onboarding als Projekt funktioniert für einen Teil der Einarbeitung sehr gut und für einen anderen kaum. Die Grenze verläuft nicht zwischen wichtig und unwichtig, sondern zwischen zwei Arten von Schritten: solchen, die erledigt sind, wenn jemand etwas getan hat, und solchen, die erst erledigt sind, wenn jemand etwas kann.

Was ein Projekttool beim Onboarding gut kann

Das Projekttool löst die Schwäche, an der klassische Checklisten am häufigsten scheitern: Jede Aufgabe hat einen Namen und ein Datum. „Laptop bestellen" gehört der IT und ist drei Wochen vor dem Start fällig, „Zugang zum Ticketsystem" gehört der Teamleitung, und wer den Stand wissen will, sieht ihn. Dazu kommt, was ein Projekttool ohnehin mitbringt:

• Vorlagen. Der Ablauf muss nicht bei jeder Einstellung neu erfunden werden.
• Status und Kommentare. Die IT schreibt „Gerät kommt erst Mittwoch" an die Aufgabe, statt eine Mail zu schicken, die niemand wiederfindet.
• Ein vertrautes Werkzeug. Alle Beteiligten arbeiten ohnehin darin, und die neue Person lernt gleich das Werkzeug kennen, das sie später jeden Tag braucht.

Für alles rund um den Eintritt ist das die richtige Wahl: Gerät, Zugänge, Arbeitsplatz, Vertrag, die ersten Termine. Diese Schritte sind für jede Rolle ähnlich, sie haben einen klaren Eigentümer, und sie sind erledigt, wenn jemand sie getan hat. Genau dafür ist ein Projekttool gebaut.

Wo Onboarding als Projekt an seine Grenze kommt

Schwierig wird es bei den Schritten, die die Rolle ausmachen. Dort zeigen sich drei Grenzen, und keine davon ist ein Fehler des Werkzeugs. Ein Projekttool ist für Vorhaben gebaut, die ein Ende haben. Einarbeitung hat keins, sie geht in Entwicklung über.

1. Ein Projekt endet, die Einarbeitung nicht

Ein Projekt wird abgeschlossen, meist mit der Probezeit oder schon vorher, und danach archiviert. Die entscheidende Phase liegt aber oft dahinter: das Gespräch nach 90 Tagen, die erste eigene Verantwortung, der Schritt von der Einarbeitung in die Entwicklung. Im archivierten Projekt steht dazu nichts, und ein neues gibt es für diese Person nicht mehr.

2. Eine geschlossene Aufgabe ist noch keine Fähigkeit

Der Status „erledigt" sagt, dass jemand die Aufgabe geschlossen hat. Bei „Laptop bestellen" ist das dasselbe wie das Ergebnis. Bei „Kostenschätzung nach DIN 276 kennenlernen" ist es das nicht. Ob jemand etwas kann, zeigt sich an einem äußeren Zeichen, etwa an der ersten eigenen Schätzung, die ohne Rückfrage durch die Prüfung geht. Ein Aufgabenstatus kennt dieses Zeichen nicht. Warum ein Haken so wenig beweist, steht ausführlich in Abhaken ist nicht sehen.

3. Die Vorlage wird kopiert und nicht klüger

Jede neue Person bekommt eine Kopie der Vorlage. Was in ihrem Projekt verbessert wird, eine fehlende Aufgabe, eine bessere Reihenfolge, ein Hinweis in einem Kommentar, bleibt in diesem Projekt und wird mit ihm archiviert. Die nächste Einstellung derselben Rolle beginnt wieder mit dem alten Stand, es sei denn, jemand trägt die Änderungen von Hand in die Vorlage zurück. Im Alltag passiert das selten, denn wenn das Projekt schließt, ist die Aufmerksamkeit längst bei der nächsten Sache.

Ein typischer Verlauf im Planungsbüro

Ein Ingenieurbüro mit gut hundert Beschäftigten führt sein Onboarding seit zwei Jahren im Projekttool. Für einen neuen Projektingenieur legt die Teamleitung wie immer das Projekt an, 38 Aufgaben aus der Vorlage. Nach sechs Wochen sind alle geschlossen, das Projekt wird archiviert, und alle sind zufrieden.

In Woche elf gibt er seine erste eigene Kostenschätzung ab, und sie kommt zurück. Die Gliederung stimmt nicht, weil er die Vorlage des Büros nie benutzt hat. Die Aufgabe dazu war in Woche zwei geschlossen worden, mit dem Kommentar „Unterlagen gelesen". Nachlässig war dabei niemand. Die Aufgabe war erledigt, sie war nur die falsche Art von Aufgabe: Sie hätte nicht „kennenlernen" heißen dürfen, sondern „erste Schätzung mit der Vorlage erstellen, durchgesehen von der Teamleitung", und sie hätte in Woche sechs gehört statt in Woche zwei.

Die Arbeitsteilung: getan gehört ins Projekt, gekonnt in den Pfad

Die Lösung ist nicht, das Projekttool abzuschaffen. Sie ist eine Arbeitsteilung, und die lässt sich an einer einzigen Frage je Schritt festmachen: Ist dieser Schritt erledigt, wenn jemand etwas getan hat, oder erst, wenn jemand etwas kann?

• Getan: Gerät bestellt, Zugang eingerichtet, Termin gebucht, Vertrag unterschrieben. Das gehört ins Projekttool oder auf die Checkliste, mit Namen und Datum. Es ist für jede Rolle ähnlich und nach den ersten Tagen vorbei.
• Gekonnt: die erste eigene Kostenschätzung, der Freigabeprozess, das erste Gespräch mit einem Kunden. Das gehört in einen Pfad je Rolle, mit Reihenfolge, Phase und einem äußeren Zeichen, und dieser Pfad läuft bis Tag 90 und darüber hinaus.

Der Pfad hängt an der Rolle und nicht an der Person. Deshalb wird er mit jeder Einstellung besser, statt mit jedem Projekt archiviert zu werden. Wie ein solcher Pfad mit vier Angaben je Schritt aufgebaut ist, steht in Ein Pfad je Rolle schlägt zehn Checklisten.

Für die neue Person bedeutet das keine zwei Welten. Sie arbeitet im Projekttool wie alle anderen, und ihr Pfad sagt ihr daneben, was als Nächstes dran ist und woran sie merkt, dass sie es kann.

Checkliste: Reicht euer Projekttool für das Onboarding?

1. Ist für jeden Schritt klar, ob er erledigt ist, wenn jemand etwas getan hat, oder erst, wenn jemand etwas kann?
2. Stehen die Schritte der ersten Art mit Namen und Datum im Projekttool?
3. Haben die Schritte der zweiten Art ein äußeres Zeichen statt nur eines Status?
4. Geht die Einarbeitung weiter, auch wenn das Projekt geschlossen ist?
5. Fließt, was bei einer Einstellung verbessert wurde, in die Vorlage für die nächste zurück?
6. Gibt es je Rolle einen eigenen Ablauf statt einer Vorlage für alle?
7. Findet ihr den Nachweis einer Pflichtunterweisung auch dann noch, wenn das Projekt längst archiviert ist?
8. Weiß die neue Person in Woche sechs, was als Nächstes dran ist, ohne jemanden zu fragen?

Fazit

Onboarding als Projekt ist besser als jede lose Liste, weil jede Aufgabe einen Namen und ein Datum bekommt. Es reicht für alles, was erledigt ist, wenn jemand es getan hat. Für die Schritte, die erst erledigt sind, wenn jemand etwas kann, braucht es einen Pfad je Rolle, der über das Projektende hinausläuft und mit jeder Einstellung besser wird. Wie beides im Alltag zusammenspielt, zeigt der Anwendungsfall Onboarding neuer Mitarbeitender, und ein Muster für den ersten eigenen Pfad liegt bei den Vorlagen. Warum Einarbeitung überhaupt reißt und woran sich das messen lässt, steht im Leitfaden.