Sobald ein Projekt bzw. die Menge der irgendwie daran teilnehmenden Personen größer wird, ist es meist fortgeschritten charmant zu wissen, wer denn eigentlich welche Rolle hat.
Wenn man sich jedoch mit dem Thema Rollen näher beschäftigt, wird man merken, dass bereits die Klärung von Rollen ein eignes Projekt darstellen kann. Zumindst bei sehr großen Projekten und vielen Teilnehmern oder einem größeren Kernteam.
Und wenn wir das tun, werden wir ebenfalls sehr schnell sehen, dass es nicht ausreichend ist, nur die Rollen zu vergeben sondern auch zu klären, was genau die Rollen bedeuten. Also welche Aufgaben oder Verantwortlichkeiten hat denn welche der Rollen?
Und weiterhin werden wir sehr schnell an den Punkt angelangen, wo wir uns neben der Definition von Rollen auch intensivere Gedanken über einen Prozess machen müssen:
- Wer kommt denn zu welchem Zeitpunkt mit Projektanforderungen auf wen genau zu?
- Wer entscheidet wann, welche Anforderungen wichtig sind, welche später umgesetzt werden dürfen oder welche direkt in die Tonne weitergeleitet werden?
- Wer wird angerufen, wenn sich Jan-Cedric und Paris-Jaqueline nicht einig werden?
- Welche Regelmeetings benötigen wir denn für ein Projekt oder in der Firma?
- Und machen wir das ganze Wasserfall oder Scrum oder Kanban oder ScrumBan oder mit einem agilen Wasserfall?
- Und was ist überhaupt mit dem Empfang und dem Catering?
Was ist deine Mission?
Bei vielen Rollenbezeichnungen ist nur anhand der Benennung nicht unbedingt hundertprozentig klar, was die exakten Aufgaben sind. Wenn wir jemandem die Rolle als bspw. Projektleiter zusprechen, können wir grob vermuten, was dessen Aufgabe ist, wissen tun wir es zu dem Zeitpunkt aber nicht wirklich.
Wenn wir nun Rollen oder Rollenbezeichnungen definieren, egal ob es sich um allgemein bekannte und gängige oder firmen- bzw. projektintern speziell definierte Bezeichnungen handelt (bspw. „head over heels incoming communications assistant“), so meinen wir letztendlich eine Menge an zugewiesenen Verantwortungen bzw. Aufgaben.
Solange jedoch nicht im Detail niedergeschrieben oder anderweitig nachvollziehbar verankert ist, welche Aufgaben und Verantwortungen eine Rolle wirklich hat, differieren Wahrnehmung, Erwartungshaltung und Realität meist stark. Mit den üblichen Folgen für Projekte: Verwirrung und fehlgeleitete Schafe.
Neben der Definition von Rollen gibt es darüber hinaus noch eine weitere Problemstellung: Hat die Person überhaupt das entsprechende Skill-Set oder das Standing, eine bestimmte Rolle einnehmen zu können? Denn wir werden kaum eine direkt frisch vom Studium stammende Person an ein betriebskritisches System einer Bank lassen wollen, wo dazu noch ein Haufen Director- und C-Level-Persönlichkeiten orchestriert werden müssen.
Da diese Problemstellung mit diesen Rollen aber eine grundsätzliche ist, werden wir sie an dieser Stelle nicht behandeln (können) und fokussieren uns auf die Bezeichnungen und Definitionen. Vielleicht finde ich irgendwann einmal die Zeit, mich konstruktiv und hilfreich mit Skill-Sets auseinander zu setzen.
Da ich nicht anfangen möchte, zusammenzustellen, wie viel interessante Rollenbezeichnungen es in Unternehmen gibt, mit dem man auf den ersten Blick nichts anfangen kann (egal ob deutsch oder englisch), wollen wir uns mal auf die üblichen Verdächtigen in (größeren) Projekten konzentrieren.
Die einzelnen Rollen betrachten wir auf eigenen Seiten in unpriorisierter Reihenfolge:
Es folgen bald: