Thought Leadership
Erfahrene Projektmanager arbeiten selten nach Lehrbuch. Egal ob PMI, IPMA oder Prince 2. Egal ob agil oder klassisch. Die Kunst besteht darin, für das konkrete Projekt die sinnvollen Techniken, Methoden, Werkzeuge und Führungsansätze zu kombinieren: Die Mojito-Methode.
Wenn Entscheider etwas in ihrer Organisation ändern wollen, dann werden Projekte initiiert. Ein Projektmanager wird eingesetzt, umdie Veränderungsmaßnahme durchzuführen. Und der geht meist nach einem klassischen Projektmanagement-Ansatz (siehe Kasten „Klassisches Wasserfall- Projekt“) vor. Die Lehrbücher beschreiben die notwendigen Schritte, um ans Ziel zu kommen: Anforderungen aufnehmen, eine Lösung finden, Arbeitspakete definieren, Ressourcen buchen, Tätigkeiten delegieren und die Durchführung überwachen. Weil aber zahllose Studien in den letzten Jahrzehnten offengelegt haben, wie hoch der Anteil der scheiternden Projekte ist, wurde das Führungssystem weiter verfeinert. Es wurde engmaschiger. Die Vorgaben wurden konkreter, die Zeitfenster kleiner, die Überwachung größer, das Reporting aufwendiger.
Im Fokus: die Innovationskraft
Man kann nachvollziehen, dass so der Kreativität der Raum genommen wird. Was aber bekommt man für den Preis einer geringeren Innovationskraft? Ist damit sichergestellt, dass Projekte erfolgreich sind? Natürlich nicht, wie wir aus Erfahrung wissen. Aber wir können das noch differenzierter betrachten: Es gibt Projekte, wo es funktioniert. Beispielsweise beim Bau einer Fußgängerbrücke kann es funktionieren, einen detaillierten Arbeitsplan exakt durchzuexerzieren. Der Bau eines Bahnhofs in einer schwäbischen Landeshauptstadt funktioniert aber so nicht. Die Betriebskantine kann man so renovieren. Aber eine neue Regelung für den Überstundenabbau kann man so nicht umsetzen.
„Ich begleite seit 15 Jahren IT-Projekte und habe noch nie eine Ressource gesehen. Immer wenn ich meine, eine entdeckt zu haben, erkenne ich bei genauerem Hinsehen, dass es ein Mensch ist.“Tonio GraweIT-Strategieberater, Advicio
Erfahrene Projektmanager fühlen das im Bauch, wann das klassische Projektmanagement funktioniert – oder auch nicht. Wissenschaftler können es explizit ausdrücken: Das Projektmanagement, bei dem logisch aufeinander folgende Schritte zum geplanten Ziel führen, setzt voraus, dass es sich um ein triviales Ursache-Wirkungssystem handelt. Wenn wir aber Veränderungen in Unternehmen durchführen, dann haben wir es nicht mit einem trivialen, sondern mit einem komplexen System zu tun. Genau genommen sind Organisationen komplexe adaptive Systeme. Adaptiv bedeutet dabei, dass die Organisation selbst mit Veränderung auf Veränderungen reagiert, sich anpasst. Und diese Reaktion auf Veränderung kann niemand – nicht der Projektleiter und auch nicht die Unternehmensführung – vorhersagen und schon gar nicht steuern.
Bild 1: Komplexität liegt zwischen Ordnung und Chaos. Ordnung ist zwar oft gewünscht, aber dieses Modell bildet nicht die Realität ab. Unternehmen mit ihren Mitarbeitern, den zahlreichen Beziehungen, Abhängigkeiten und Kommunikationskanälen können nicht als triviales Ursache-Wirkungssystem betrachtet werden. Während Chaos unbeherrschbar ist und daher unerwünscht ist, ist Komplexität mit geeigneten Methoden beherrschbar.
Muss man also das Projektmanagement im Umfeld von Organisationen für gescheitert erklären? Das wäre schade, haben Unternehmen doch viel darin investiert und auch einiges damit erreicht. Wenn wir aber bereit sind, die Methode mit ein paar Zutaten aus dem agilen Bereich zu verfeinern, hilft es effizienter und zielgerichteter Vorzugehen.
Die agile Bewegung
In den letzten zwei Jahrzehnten wurde speziell in der Softwareentwicklung mit agilen Entwicklungsmethoden Erfahrungen gemacht. Scrum (siehe Kasten „Agiles Projekt am Beispiel Scrum“), Extreme Programming (XP), und Feature Driven Development (FDD) sind Methoden, die sich unter dem Dach „Agile“ versammeln. Gemeinsam haben sie das Agile Manifesto, das zwar erst 2001 erstellt wurde, aber heute die gemeinsame Wertebasis ist.
Sinngemäß sagt das Agile Manifesto folgendes:
- Personen und Beziehungen sind wertvoller als Prozesse und Werkzeuge
- Funktionierende Projektergebnisse sind wertvoller als umfangreiche Dokumentation
- Zusammenarbeit mit dem Kunden ist wertvoller als Vertragsverhandlung
- Auf Änderungen reagieren ist wertvoller als einem Plan zu folgen
Agil zu sein ist in erster Linie eine Weltanschauung und hat mit der Unternehmenskultur zu tun. Es gibt ja Organisationen, deren Kultur mit Recht und Ordnung, Stabilität und Kontrolle verwurzelt ist. Solche Organisationen werden sich naturgemäß schwer tun, Agilität zu leben – und wollen das wahrscheinlich gar nicht. Es gibt aber ja auch Unternehmen, die innovativ sein wollen, die sich ständig verändern wollen („Kontinuierliche Verbesserung“), die flexibel auf Marktveränderungen reagieren wollen. Solche Unternehmen haben Agilität in ihrer Unternehmenskultur verankert und tun sich leichter, agile Methoden in ihren Projekten zu leben.
Stärken und Schwächen
Viele Projektmanager hassen Change Requests. Viele Change Advisory Boards haben das Ziel, Change Requests abzuschmettern. Andererseits haben wir erkannt, dass in Organisationen, die komplexe adaptive Systeme sind, kein Projekt nach Plan durchgeführt werden kann. Das Umfeld reagiert auf die Ergebnisse des Projekts, auf das Projekt selbst, ja manchmal schon auf die Überlegungen ein Projekt zu machen. Die Möglichkeit, geänderte Anforderungen kontinuierlich in den Projektverlauf einfließen zu lassen, ist sicher für das klassische Projektmanagement die attraktivste Eigenschaft der agilen Methoden.
Eine weitere agile Eigenschaft ist, wie mit den Menschen umgegangen wird. Die klassische Lehre verwendet den Begriff Ressource. Als ob beispielsweise „Oracle Certified Professional Java Programmer“ ein Artikel wäre, den man vom Lager abrufen kann. Die agilen Methoden sehen den Menschen und gehen damit um, dass Menschen unterschiedliche Charaktereigenschaften haben und dass gewachsene heterogene Teams mehr leisten als die Summe der Einzelleistungen. Das fördert die Mitarbeiterzufriedenheit, kann aber auch ein Klima schaffen, in dem Kreativität und Innovation zuhause sind.
Das hört sich alles gut an, aber es gibt natürlich auch in diesem Fall Schattenseiten. Eine Studie von Versionone [Versionone: State of Agile Survey 2011], die bereits seit sechs Jahren den Einsatz von „Agile“ untersucht, legt die Probleme offen: Nur 16% der über 6000 Befragten gab an, noch kein gescheiteres agiles Projekt erlebt zu haben. Gängige Fehlerursachen sind demnach (Bild 2) die geringe Erfahrung mit agilen Methoden, fehlende Anpassungen in der Organisation, die nicht zu Agile passende Unternehmenskultur, externe Einflüsse und so weiter. All das liegt doch im Verantwortungsbereich des Managements. Ist das Management dafür verantwortlich, dass Agile-Methoden nicht zum Erfolg führen?
Bild 2: Die meisten der identifizierten Fehlerquellen von agilen Projekten liegen nicht im Verantwortungsbereich des Projektteams, sondern sind Management-Aufgaben. Paradoxerweise haben die agilen Methoden wie beispielsweise Scrum die Rolle des Managers gar nicht berücksichtigt.
Jurgen Appelo deckt in seinem Buch [Jurgen Appelo: Management 3.0, 2011] eine essentielle Schwäche von der Agile-Idee auf: Die Agile-Methoden propagieren die Selbstorganisation von Teams und ignorieren die Rolle des Managements. Management kommt bei Agile nicht vor. Wen wundert es da, dass Manager die Agile-Bewegung lange ignoriert haben. Das ist also die verzwickte Situation: Erstens: es gibt Manager im Unternehmen, weil Unternehmer und Aktionäre diese einsetzen, damit die Manager das Unternehmen in ihrem Sinne führen. Und zweitens: Die an sich guten agilen Methoden scheitern an Themen, die typischerweise im Verantwortungsbereich des Managements liegen.
Die Management-Akzeptanz ist genau eine Stärke des klassischen Projektmanagements. Wie aber könnte man die Stärken des klassischen Projektmanagement und die Stärken der Agile-Methoden miteinander kombinieren? Dafür sollten drei Aspekte in das klassische Projektmanagement eingearbeitet werden:
- Kurze Iterationszyklen
- Intensives Stakeholder-Management
- Mit Menschen arbeiten.
Kurze Iterationszyklen
Auf Änderungen reagieren sei wertvoller, als einem Plan zu folgen, sagt das Agile Manifesto. Änderungen sind gut, weil sie das Produkt verbessern. Also sollte ein Change Board nicht mit dem Ziel eingesetzt werden, Änderungen zu verhindern – so wie das heute leider oft der Fall ist. Andererseits braucht das Projektteam auch stabile Anforderungen, um mal in Ruhe etwas entwickeln zu können. Der Clou sind kurze Iterationszyklen, die in Scrumals Sprints bezeichnet werden. Die Anforderungen, die das Projektteam derzeit bearbeitet, sind eingefroren, während andere Anforderungen beliebig geändert und ergänzt werden können.
Stellt sich die Frage, wie kurz die Iterationen sein sollen. In der agilen Softwareentwicklung werden Zeiträume zwischen zwei und vier Wochen gewählt. Für die meisten IT-Projekte und Organisationsveränderungen wie etwa ein Carve-In ist dies eine realistische Größenordnung.
Kurze Zyklen und häufiges Planen ist auch ein Konzept, das dem klassischen Projektmanagement bekannt ist. Beim PMI wird es „rolling wave planning“ genannt. Allerdings wird es selten praktiziert, weil die Kultur der Organisation kein Vertrauen hat und die Stakeholder lieber einen umfassenden Plan in der Hand haben, um eine Investitionsentscheidung zu treffen. Vielleicht kann dieses Vertrauen ja aufgebaut werden, wenn man den folgenden agilen Grundsatz umsetzt.
|
Klassischer Wasserfall-Projekt |
|
Beim Klassiker unter den Projektmanagementmethoden wird zunächst viel geplant. Es wird viel Papier erzeugt, was man als „big design up front“ (BDUF) bezeichnet. Erst anschließend geht es in die Implementierung und es entsteht das Produkt als Ergebnis des Projekts. Da ein solches Projekt einige Monate – manchmal gar Jahre – läuft, und die Welt rund um das Projekt nicht still steht, gibt es Änderungsanforderungen. Manche Projektleiter empfinden das so, als würde ihr sorgfältig geplantes Projekt bombardiert werden. Um das Projekt zu schützen, wird ein starkes Change Management aufgesetzt. Während das Change Management an sich gut ist, ist doch die häufig anzutreffende Intuition, damit möglichst viele Änderungsanforderungen abschmettern zu können, sehr zweifelhaft. Änderungsanforderungen, die zu berücksichtigen sind, werfen das Projekt zurück. Das wirk schlecht auf die Moral des Projektteams, kostet Geld und ist ungünstig für die„time to market“. Eine Budgeterhöhung und eine Ausweitung des Zeitplans wird vom Change Board genehmigt, wenn dies sinnvoller erscheint, als die neuen Anforderungen zu ignorieren. |
Intensives Stakeholder-Management
Zusammenarbeit mit dem Kunden sei wertvoller als Vertragsverhandlung, sagt das Agile Manifesto. Konkret bedeutet das, dass der Kunde – beziehungsweise die Stakeholder – nach jeder Iteration das Zwischenergebnis ansehen, es überprüfen und Feedback geben soll. Zu diesemAufwand sei der Kunde nicht bereit, hört man oft. Da liegt die Frage auf der Zunge, wie groß denn das Interesse des Kunden an dem Projekt ist, wenn ihn die Ergebnisse nicht interessieren.
Tatsächlich ist doch auch der Aufwand für eine Requirements Engineering im Vorfeld groß und allein die gewissenhafte Abnahme einer umfangreichen Spezifikation nimmt enorm viel Zeit ein. Ich wage die These, dass der kundenseitige Aufwand für ein „big design up front“ nicht geringer ist, als die kontinuierliche Mitarbeit in einem agilen Projekt. Wobei letzteres ertragreicher und befriedigender ist. Projekte bedeuten Veränderung. Die Stakeholder sind die Betroffenen. Gerade bei Organisationsveränderungen sollte ein Change Agent eingesetzt werden, der behutsam die Organisation auf die Veränderungen vorbereitet und die Akzeptanz sicherstellt. Es gibt gute Erfahrungen damit, dass der Projektmanager auch die Rolle des Change Agents hat.
Allerdings sehen sich traditionell viele Projektmanager nur als Manager des Projektteams und meinen der Verantwortungsbereich sei auf die Projektorganisation beschränkt. Dadurch entsteht manchmal eine Kluft, welche die Einbindung der Stakeholder schwierigmacht. Besser ist es, wenn der Projektmanager ganz offiziell als Change Agent benannt wird und sein Verantwortungsbereich klar über die Grenzen des Projektteams hinaus geht.
|
Agiles Projekt am Beispiel Scrum |
|
Von den agilen Entwicklungsmethoden ist Scrum heute die am weitesten verbreitete. Scrum definiert drei Rollen: den Product Owner, das Team und den Scrum Master. Der Prodcut Owner ist allein verantwortlich für das Ergebnis, das Produkt, aber auch für die Finanzen. Unmissverständlich wird die Rolle auch als „single wringable neck“ bezeichnet, um deutlich zu machen, dass nur genau eine Person diese Rolle hat. Der Product Owner ist das Bindeglied zwischen den Stakeholdern und dem Entwicklerteam. Der sammelt und priorisiert kontinuierlich die Anforderungen, die als sogenannte User Story im Product Backlog gesammelt werden. Das Team muss interdisziplinär aufgestellt sein, um möglichst alle anfallenden Aufgaben selbst erledigen zu können und möglichst wenige Abhängigkeiten„nach außen“ zu haben. Das Team ist selbst-organisiert: Es verteilt die anstehenden Aufgaben selbst, koordiniert sich selbst und bestimmt selbst welche Methoden und Tools eingesetzt werden sollen. Zu Beginn eines jeden Sprints, so wird eine Iteration genannt, wählt das Team die User Stories aus, die es in dem Sprint umsetzen möchte. Diese werden aus dem Product Backlog genommen und bilden das Sprint Backlog. Am Ende des Sprints liefert das Team ein Produktinkrement ab. Der Product Owner testet dieses zusammen mit den Stakeholdern. Der Scrum Master wirkt eher im Hintergrund wie ein Coach. Er beobachtet wie Product Owner und das Team arbeiten, gibt Hinweise wie effektiver gearbeitet werden kann und räumt Hindernisse aus dem Weg. |
Systemische Führung
Personen und Beziehungen seien wertvoller als Prozesse undWerkzeuge, sagt das Agile Manifesto. Manche Projektmanager bezeichnen Mitarbeiter als Ressourcen und stellen sie damit auf gleiche Ebene wie Besprechungsräume und Rechenzentrumskapazitäten. Kaufmännisch gesehen mag es nachvollziehbar sein, jedoch schöpft man das Potential nicht aus. Gewachsene Teams können mehr leisten als die Summe der Teammitglieder ist. Das ist regelmäßig zu beobachten bei neu zusammengestellten agilen Entwicklungsteams, die mittelprächtig anfangen, dann eventuell noch etwas nachlassen, um im vierten oder fünften Sprint zu Höchstleistungen zu kommen. Ein solches „winning team“ kann entstehen, wenn die Mitglieder durch intrinsische Motivation angetrieben sind und das Umfeld Raum für Innovation lässt, aber gleichzeitig eine Richtung vorgibt.
Das Stichwort ist hier „Systemische Führung“. Der wissenschaftliche Hintergrund von diesem Führungsstil ist die Komplexitätstheorie. Dabei akzeptieren Führungskräfte, dass sie nicht alles kontrollieren können, sondern dass die Organisation ein komplexes System ist. Wenn man Selbstorganisation fördert, aber nicht ungelenkt lässt, wennman Teams geschickt aufstellt und Mitarbeiter richtig motiviert, wenn man Kompetenzen entwickelt und die Strukturen passen, dann reicht es, gelegentlich einen Implus zu geben, um das System am Laufen zu halten.
Die Mojito-Methode
Ein Mojito besteht aus Rum, Limettensaft, Minze, Rohrzucker und Sodawasser. Das sind unspektakuläre Zutaten. Und dennoch schaffen es Barkeeper daraus etwas Tolles zu kreieren. Und obwohl es Rezepte für Mojito gibt, werden sie immer unterschiedlich interpretiert und der Cocktail schmeckt an jedem Ort anders. Einfache Zutaten zu mixen und daraus etwas Besseres machen, das funktioniert auch mit Ideen, stellt Jurgen Appelo [Jurgen Appelo: How to Change the World, 2012] fest. Wenn man Konzepte unterschiedlichen Ursprungs geschickt kombiniert kann etwas entstehen, das die Eigenschaften der ursprünglichen Ideen aggregiert und übertrifft.
So müssen auch Projektmanager denken, die Organisationsveränderungen durchführen. Die Zutaten sind die klassischen Projektmanagement-Methoden, die agile Denkweise mit ihren Methoden, sowie systemische Führung und eine Prise Komplexitätstheorie. Die Kunst besteht darin, das Rezept so zu variieren, dass der Methodenmix zur konkreten Aufgabenstellung und zur Unternehmenskultur passt – und den Geschmack der Stakeholder trifft.
TONIO GRAWE
Diesen Artikel lesen Sie auch in der it management , Ausgabe 4-2012.
