Wir haben gesehen: Die technische Lösung an sich, die Bewegungen der Mitbewerber und des Marktes, die Anforderungen unserer Kunden, die Randbedingungen durch Stakeholder und andere Ereignisse wie Pandemien, all das kann in komplexen Projekten zu Veränderungen führen, mit denen ein Projektleiter und das Team umgehen muss.
Es hat sich gezeigt, dass komplexe Aufgaben in selbstorganisierten und interdisziplinären Teams am besten erledigt werden können. Mit anderen Worten: Wenn unterschiedliche Experten in einem selbstorganisierten Team zusammenarbeiten, erreicht man dadurch u. a. eine Komplexitätsreduktion, weil diese Experten viele Abhängigkeiten zwischen Teilaufgaben untereinander ausregeln, ohne dass es dafür eine zentrale Lösungskompetenz (sei es der Projektleiter oder jemand anderes) braucht. Die notwendige Voraussetzung dafür ist natürlich, dass das Team tatsächlich als Team zusammenarbeitet und sich für das Ergebnis gemeinsam verantwortlich fühlt.
Damit kommen wir zu der wirklich spannenden Frage: Wie bringen wir denn nun das Projektteam in diesen Idealzustand?
Das ist keine einfache Aufgabe, sie ist noch nicht mal "nur" kompliziert, sondern tatsächlich sehr komplex, mit anderen Worten: Den einen richtigen Weg, die eine richtige Antwort gibt es nicht. Aber es gibt gute Zutaten dafür, von denen wir die wichtigsten im Folgenden beleuchten wollen.
2.1 Zutaten: Verantwortung und Partizipation im klaren Rahmen
2.1.1 Ziele und Leitplanken definieren
Wie beschrieben ist es die grundsätzliche Idee, das Team in die gemeinsame Verantwortung bringen. Dafür ist es zielführend, innerhalb eines klaren Rahmens dem Team den größtmöglichen Freiraum zu geben, um den Lösungsweg zu erarbeiten. Aus Führungssicht (und zwar sowohl einer Führungskraft als auch der Projektleitung) liegt der erste Schritt darin, sich über die Ziele und Leitplanken klarzuwerden.
- Welche Ziele hat das Projekt? Welches Ergebnis möchte das Unternehmen mit diesem Projekt erreichen? Welche Auswirkungen wird es haben, wenn wir das Ziel erreichen oder nicht erreichen? Gibt es Haupt- und Nebenziele, und wenn ja, wie sind diese zu gewichten? Je konkreter und messbarer die Ziele gefasst werden können, desto besser.
- Welche Leitplanken sind relevant? Welche Rand- und Rahmenbedingungen gibt es? Welche Grenzen dürfen nicht überschritten werden? Auch hier gilt wieder: je konkreter, desto besser.
Erfahrungsgemäß sind die Ziele und Leitplanken nicht sehr gut beschrieben und/oder werden nicht transparent dargestellt. Das gilt insbesondere für das WOZU des Projekts, also den Sinn und Nutzen, der mit diesem Projekt verfolgt wird. Diese Informationen konkret und transparent zu haben, hilft jedoch allen Beteiligten enorm bei der Einordnung und der Priorisierung.
Ein Wort zur Messbarkeit der Ziele: Wichtig ist es, die tatsächlichen Ziele abzubilden und dafür Metriken zu entwickeln. Es ist wenig sinnvoll (und sogar schädlich!), nur diejenigen Ziele transparent zu machen, die sich rein zufällig gut messen lassen.
Sinn und Nutzen eines Projekts messbar machen
Ein Logistikdienstleister für Spezialtransporte möchte sein Beschwerdemanagement digitalisieren und hat ein entsprechendes Projekt aufgesetzt. Das Projektziel ist es, den bisher teilweise manuellen Prozess weitestgehend digital zu führen. Dafür lassen sich Metriken formulieren, die bspw. den Digitalisierungsgrad der verschiedenen Prozessschritte oder Schnittstellen abbilden. Der Sinn und Nutzen des Projekts liegt jedoch nicht einfach in der Existenz dieses digitalen Prozesses, sondern darin, (z. B.) die Kundenzufriedenheit zu erhöhen. Dafür lassen sich durchaus messbare Größen formulieren wie NPS oder durchschnittliche Antwortzeiten. Im Verlauf des Projekts kann sich unter Umständen herauskristallisieren, dass das Projektziel nicht im geplanten Umfang den eigentlich gewünschten Nutzen erzielt, z. B. weil die Kundenzufriedenheit auch bei digitalisiertem Prozess nicht steigt. Dann ist es sinnvoll, das Projektziel (und damit das Projekt) anzupassen.
Es könnte an dieser Stelle der Eindruck entstehen, dass dieser erste Schritt alles andere als einfach und möglicherweise echte Arbeit ist. Dieser Eindruck wäre richtig. In der Anwendung führt die geforderte Klarheit manchmal zu schwierigen Diskussionen mit Stakeholdern oder Auftraggebern und wird daher gern vermieden, ist jedoch sehr wichtig.
Es ist durchaus möglich (und in einer komplexen Umgebung sogar wahrscheinlich), dass sich das Ziel des Projekts im Laufe der Zeit verändert. Das können kleinere Anpassungen sein, die sich sehr klassisch über Change Requests verarbeiten lassen, es können sich aber auch signifikante Veränderungen des Projektziels ergeben. Oft entsteht dann "scope creep", also die "schleichende "Veränderung bzw. Erweiterung des Leistungsumfangs. Eine Veränderung des Projektziels ist jedoch nicht per se schlecht, im Gegenteil: Es gibt...