Der Projektstart: ‚Onboarding‘ für die Mitstreiter.

Wie löst man das Henne-Ei-Problem zu Projektbeginn? Wer einsteigen will, braucht ein Team, kann aber noch nicht sagen welche Mitstreiter tatsächlich nötig sind.

Da ist dieses Henne-Ei-Problem gleich zu Projektbeginn. Man sollte ein Projektteam haben, um vernünftig in ein Projekt zu starten, allerdings bräuchte man eine Übersicht über die anstehenden Themen, um sagen zu können, wen man denn nun im Projektteam benötigt. Ganz abgesehen davon, dass es in einer Matrixorganisation gar nicht so leicht ist überhaupt ein Projektteam zu bekommen. Statt dessen wird oft mit Abteilungen anstatt mit Personen gearbeitet, was die Projektarbeit unnötig kompliziert macht. Wie kommt man zu einer Mannschaft, mit der es Spass macht zu arbeiten und die so richtig was auf die Beine stellt?

Wen ins Team holen? Auch Chefs sind Mitstreiter.

Ein Problem, das immer wieder auftaucht, entsteht durch den hierarchischen Aufbau vieler Organisationen. Auch Projektleiter denken in „oben“ und „unten“. Weshalb es leicht vorkommen kann, dass die Chefs, „die da oben“, außen vor bleiben. Was auf erster Näherung auch Sinn macht, denn es sind ja die Chefs, nicht die operativen Kräfte.

Allerdings kennt das Projekt als Organisationsform erst einmal keine Hierarchie. Der Projektleiter wird engagiert, um etwas zu liefern, was die Routine und was die Standardabläufe in einem Unternehmen nicht liefern können. Das kann er nicht alleine tun, weshalb er Mitstreiter braucht. Diese Mitstreiter benötigen ein bestimmtes, für das Projekt erforderliches Know-how und, solange wir in einer hierarchischen Organisation arbeiten, auch die notwendige Entscheidungskompetenz. Die haben im Normalfall die Chefs in der Linie. Weshalb es Sinn macht, sie in die Arbeit am Projekt zu integrieren.

Diese Erkenntnis ist nicht wirklich neu und sicherlich nicht bahnbrechend. Sie ist insofern jedoch spannend, da mit dieser Aussage soeben die Chefs zu Mitstreitern im Projekt wurden. Damit verlässt das Projekt als temporäre Organisationsform die Strukturen der Linienorganisation (siehe auch „Wer von Abteilungen redet, denkt nicht in Projekt„). Die Hierarchie, wie sie im Organigramm des Unternehmens beschrieben ist, gilt im Rahmen der Arbeit am Projekt nicht mehr. Das ist mindestens gewöhnungsbedürftig für alle Beteiligten. Dann sitzt der Boss als Teammitglied am Tisch. Darf er jetzt immer noch bestimmen? Wie soll er sich verhalten?

Wird diese Situation, dieser Rollenkonflikt, von den Beteiligten nicht angesprochen und geklärt, führt das nicht selten zu unnötig viel Arbeit und Verantwortung für die Führungskräfte. Ohne dass darüber geredet wird, wird von den Führungskräften im Projekt dasselbe erwartet, was in der Linie von ihnen erwartet wird: sie sollen die Führung übernehmen. Der Projektleiter schaut darauf, was die Chefs sagen und degradiert sich im Extremfall selbst zum Erfüllungsgehilfen. Einem teuren und sicherlich bald auch demotivierten Erfüllungsgehilfen, wohlgemerkt.

Erwartungen, Kompetenzen, Spielregeln: Rollen klären ist unabdingbar.

Macht man sich bewusst, dass ein Projekt sich zwar in der Hierarchie des Unternehmens bewegt, jedoch die Organisation des Projekts im Innenverhältnis mit dieser Hierarchie zunächst einmal nichts zu tun hat, wird der Hinweis auf eine notwendige Rollenklärung banal. Dann sitzt da zwar noch dieselbe Person am Tisch, die in der Linie Chef des Projektleiters ist, allerdings diesmal in einer anderen Rolle. Das Know-how und die Kompetenzen dieser Person werden im Projekt benötigt, nicht der Chef als Funktion.

Aus diesem Grund lohnt es sich drei Stichworte auf die Agenda der ersten Besprechungen zu setzen:

Erwartungen, Kompetenzen und Spielregeln.

  • Was erwartet im Rahmen des Projekts wer von wem?
  • Welche Kompetenzen werden wem zugestanden, etwa wenn es um Entscheidungen geht?
  • Und welche Spielregeln im Sinne von übergeordneten Prinzipien sollen für die Zusammenarbeit gelten, etwa wenn es darum geht, Entscheidungen zu treffen?

Ob es sich dabei um ein informelles Treffen in kleiner Runde handelt, oder einen offiziellen Projektstart-Workshop, spielt dabei keine Rolle. Die Fragestellung sollte jedes Mal auf der Agenda stehen, wenn Mitstreiter teilnehmen, für die diese Fragen bisher nicht beantwortet wurden.

Wir verwenden übrigens bewusst nicht die „AKV„, die Aufgaben, Kompetenzen und Verantwortung. Das Besprechen der üblicherweise unausgesprochenen Erwartungen sowie der damit verbundenen Spielregeln der Zusammenarbeit, die den Umgang mit den Erwartungen beschreiben, ist deutlich wirkungsvoller für eine gute Zusammenarbeit. Damit werden auch Themenfelder handhabbar, die zu Projektbeginn noch gar nicht erkannt werden können und deshalb erst später identifiziert werden.  Aufgaben und Verantwortung sollten sich aus der Projektplanung ergeben. Die Erstellung des operativen Projektplans steht erst später auf der Agenda, nachdem die Projekteinrichtung vollzogen ist. Schafft die Planung diese Klarheit nicht, hat sie den Namen nicht verdient. Das gilt bei agilen Ansätzen ebenso, wie bei allem, was in die Schublade „klassisch“ gepackt wird.

Nicht außer Acht sollte man beim Projektstart die Führungskräfte der Personen, die am Projekt mitarbeiten. Diese indirekten Mitstreiter sollten ebenfalls Klarheit und Verlässlichkeit darüber haben, in welchem Rahmen und nach welchen Spielregeln ihre Kollegen, sprich: ihre Mitarbeiter im Fachbereich, im Projekt eingesetzt werden sollen. Die sind schließlich ihre „Untergebenen“, um in der Sprache hierarchischer Organisationen zu bleiben. Wer als Projektleiter immer wieder Schwierigkeiten damit hat, dass die Chefs der Teammitglieder sich in das Projekt einmischen, der kann davon ausgehen, dass eine weitere Rollenklärung zu weniger Spannungen führen wird. Rollenklärung wird so lange betrieben, bis für alle Beteiligten Klarheit und Akzeptanz erreicht sind.

Projektteams benötigen eine Strategie, um mit Konflikten konstruktiv umgehen zu können

Man müsste allerdings Hellseher sein, um bereits beim Projektstart alle Mitstreiter identifizieren und deren Rollen zu 100 Prozent klären zu können. Nicht nur deshalb muss man davon ausgehen, dass es Konflikte geben wird. Die entstehen meist, weil zwei unterschiedliche Erwartungen aufeinander treffen. Was nicht schlimm ist, sofern der Konflikt geklärt wird.

Ein Projektteam wird umso produktiver zusammenarbeiten können, je mehr es in der Lage ist, Konflikte selbst und zügig ausräumen zu können. Deshalb lohnt es sich auf Spielregeln für die Konfliktlösung besonders zu achten:

  • Wie wollen wir damit umgehen, wenn wir einen Konflikt erkennen?
  • Wie sprechen wir ihn an?
  • Wie gehen wir die Lösung an?
  • Wer soll, kann und darf in welcher Form daran mitwirken?

Konflikte sind normal. Wer weiß, wie er sie lösen kann, tut sich leichter, sich auf die notwendigen Ergebnisse zu fokussieren.

Allein die gemeinsame Auseinandersetzung mit diesen Fragen wirkt Wunder auf die Zusammenarbeit. Damit werden Konflikte normal, es ist in Ordnung, wenn welche auftreten, was sie besprech- und damit lösbar macht. Wobei am Ende der Diskussion im Idealfall klare Spielregeln formuliert sind, die alle Beteiligten akzeptiert haben.

Das vorläufige Projektteam als Mittel des Brückenbaus

Und wie kommt man nun zum Projektteam? Nicht in einem Schritt. Das lehrt die Erfahrung. Selten sind Organisationen so klar aufgestellt, dass bereits mit Erteilung des Projektmandats das Projektteam benannt werden kann. Ganz abgesehen davon, dass Projekte zu diesem Zeitpunkt selten so klar umrissen werden können, damit dies gelingt.

In der Startphase ist deshalb diplomatisches Geschick gefragt. Der Weg über ein „vorläufiges Projektteam“ kann helfen, die Lücke zu schließen, die zu Beginn oft entsteht. Der Projektleiter bittet in diesem Fall die Fachbereiche darum, einen Experten in das vorläufige Team zu entsenden, das lediglich die Projekteinrichtung vollziehen soll. Die Zusage dafür fällt dem Fachbereich leichter, als einen Experten für das gesamte Projekt zu entsenden, wo doch der Umfang der Mitarbeit noch nicht annähernd klar ist. Angefragt wird der Experte für das vorläufige Team schließlich lediglich für ein paar Stunden oder Tage zur Mithilfe an der Projekteinrichtung, nicht für monatelange Mitwirkung am Vorhaben über die nächsten zwei Jahre hinweg. Mit dieser Vorgehensweise unter Einrichtung eines vorläufigen Projektteams hat sich das eingangs erwähnte Henne-Ei-Problem erledigt.

Die so für die Projekteinrichtung gewonnenen Experten versuchen dann gemeinsam mit der Projektleitung so viel Klarheit über das Vorhaben zu schaffen, wie nur irgendwie möglich. Das Ergebnis kann eine Projektskizze sein, die eine grobe Planung des Vorhabens und erste inhaltliche Gedanken enthält. Diese Projektskizze dient der Abstimmung mit den Auftraggebern des Projekts über die Vorgehensweise und die Ausstattung des Vorhabens. Jetzt ist es erstmals möglich den Umfang und die Bedarfe des Projekts abzuschätzen, so dass nun tatsächlich geklärt werden kann, wer in welchem Umfang und unter welchen Spielregeln für die weitere Zeit ins Projekt entsendet wird.

Im Idealfall werden diejenigen Experten weiter am Projekt mitarbeiten, die bereits an der Einrichtung mitgewirkt haben. Das spart Schleifen für die Abstimmung. Allerdings ist es utopisch anzunehmen, dass dies jedes Mal gelingt. Weshalb ein gewisses Maß an Wiederholung der Projekteinrichtung eingerechnet werden sollte, damit den später hinzukommenden Mitstreitern die Chance bleibt, das Vorhaben zu verstehen sowie die Vorgehensweise zu akzeptieren und mitzutragen. Anpassungen der Vorgehensweise an die Bedürfnisse der neuen Mitstreiter sollten deshalb als Normalfall betrachtet werden, der die spätere Arbeit in der Umsetzungsphase deutlich erleichtert.

Die Projekteinrichtung ist ein Gemeinschaftswerk

Ein Projektstart-Workshop als erste Besprechung des vorläufigen Projektteams ist ein bewährtes Mittel, um einen soliden und zügigen Einstieg in die Projektarbeit zu machen. Darin wird über

  • Ausgangslage,
  • Risiken,
  • Ergebniserwartung,
  • zu bearbeitende Themen,
  • anvisierte Zwischenergebnisse sowie
  • Rollen,
  • Kommunikation und
  • Informationsflüsse gesprochen.

Im Idealfall arbeitet der Auftraggeber daran (in Teilen) mit, denn oft kennt er alleine die Vorgeschichte und die wesentlichen Anforderungen. Die Vorgehensweise bei Scrum, in der der Product Owner am Einstieg in die Planung mitwirkt, trägt genau dieser Tatsache Rechnung.

Das gemeinschaftliche Erarbeiten der Vorgehensweise bringt mehrere Vorteile mit sich. So wird zum einen das gesamte Know-how der beteiligten Experten genutzt, was in den meisten Fällen zu einer schlüssigeren und belastbareren Vorgehensweise führt. Zum anderen entlastet dieses Vorgehen sehr häufig den Projektleiter von der gefühlten Erwartung, alles alleine liefern zu müssen. Der Projektleiter ist eine Art „Dienstleister für gute Zusammenarbeit“ für sämtliche Beteiligte. Wird in einem solchen Workshop die gesamte Arbeit sichtbar gemacht, die ansteht, wird jedem Beteiligten klar, dass das nicht der Projektleiter alleine lösen kann.

Das alles zusammen führt wiederum zu einer viel höheren Akzeptanz für das Vorgehen bei allen Beteiligten, womit sich die Energie und die Diskussionen auf Lösungen und Ergebnisse konzentrieren können. Endlose Diskussionen warum was wie nicht geht und wer was wie falsch gemacht hat, sollten damit deutlich weniger werden. Unterm Strich antworten viele Teams, die so ins Projekt einsteigen, dass die Zusammenarbeit viel mehr Freunde macht und das unter anderem deshalb, weil die Teams weit besser vorankommen.

Das wünsche ich Ihnen!

Ihr
Holger Zimmermann
Projektmensch.

(Visited 3.114 times, 1 visits today)

Kommentar verfassen