Ich will hier mal eine Lanze brechen für das gute alte Projektmanagement, das irgendwie in der Schublade für verkrustete Dinge gelandet ist. Agil ist heute hipp. Bekannte Buchautoren verteufeln das Gantt-Diagramm. Das Spannende daran: es gibt kein nicht-agiles Projektmanagement. Wer sich intensiv mit der Methode auseinandersetzt, merkt schnell, dass ein paar Anwender irgendwann falsch abgebogen sein müssen. Sie haben Methode als zu befolgendes Regelwerk verstanden und den Sinn hinter der Methode vergessen.
Erste Verwechslung: Das Wasserfall-Modell wird mit Projektmanagement gleichgesetzt
Das mag jetzt für manchen eine Spitzfindigkeit sein: Das Wasserfallmodell, quasi das Ur-Gegenstück aller agiler Vorgehensmodelle, ist eben ein solches, ein Vorgehensmodell. Es hat insofern nur etwas mit Projektmanagement zu tun, dass ich es innerhalb eines Projekts nutzen kann, um mein Vorgehen inhaltlich und zeitlich zu strukturieren. Die Verquickung unter dem Dach „Projektmanagement“, so mein Verständnis, kommt daher, dass der Begriff Projektplanung irgendwann in diesem Modell gelandet ist.
Ein Projekt allerdings hat zwei unterschiedliche Perspektiven: da ist zum einen der Inhalt des Projekts, der Projektgegenstand. Dessen Erstellung wird durch Vorgehensmodelle beschrieben. Zum anderen gibt es organisatorische Notwendigkeiten, etwa die Abstimmung, wer welche Aufgabe nach welcher Systematik übernimmt und wie dessen Verfügbarkeit sichergestellt wird. Diese beiden Aspekte wurden durch die Aufnahme der Planung in das Wasserfallmodell vermischt.
Zweiter Irrtum: Pläne müssen eingehalten werden
Über dieses Thema hatte ich an anderen Stellen bereits mehrfach geschrieben. Der Artikel „Bitte hört auf Termine einzuhalten!“ war besonders beliebt. Und ehrlich: ich weiß nicht, wer wann aus welchem Grund auf die Annahme gekommen ist, man könne Pläne einhalten. Wir müssten Hellseher sein, um Pläne einhalten zu können. Wer also behauptet, ein Plan sei deshalb nicht agil, weil er starr sei, hat meiner Meinung nach den Sinn von Planung nicht verstanden.
Jeder von uns macht ständig Pläne. Wir überlegen, wie wir unseren Tag gestalten wollen – und selbstverständlich wird es Störungen und Abweichungen geben. Wir überlegen, wie der nächste Urlaub aussehen soll und was wir vorbereiten müssen – und selbstverständlich wird es Störungen und Abweichungen geben. Außerdem werde ich im Projektverlauf klüger. Beides sollte Eingang in meine Planung finden.
Die Weiterentwicklung des Plans, oder besser: des Vorgehens, muss der Normalzustand sein und deshalb mit möglichst wenig Aufwand einhergehen.
Wobei genau genommen der Plan gar nicht geändert werden muss. Vielmehr wird dem Plan die Realität gegenübergestellt. Aus dem Delta können wir lernen.
Sobald ich jedoch nicht alleine bin, sollte ich eine gewisse Systematik haben, nach der wir von den Anpassungen erfahren und uns beteiligen können. Warum? Weil uns Pläne helfen, dass uns unsere Arbeit leichter von der Hand oder besser: Hand in Hand geht. Pläne sind auch das Ergebnis von Abstimmung. Wenn jemand ein Gantt-Diagramm erstellt, ist das nichts anderes, als die Dokumentation dessen, wie wir vorgehen wollen.
Allerdings habe ich auch gelernt, dass diese Pläne oft als Terminpläne erstellt werden. Abhängigkeiten werden nur grob betrachtet. Und es werden Dinge geplant, die man heute noch nicht weiß. Wenn jemand das erlebt hat, kann ich gut verstehen, dass er diese Form von Planung als starr erlebt hat und deshalb ablehnt. Dann kommt agil als Segen daher. Fußt dann jedoch auf einem Irrtum, denn das ist keine gute Projektplanung. „Projektplanung ist Denken“ ist ein weiterer Artikel, in dem ich darauf eingehe.
Wobei ich eine Sache festhalten will: Die Diskussion, die dank „agil“ angestoßen wurde, halte ich für sehr fruchtbar. Auch denen, die Pläne als „einzuhalten“ definiert haben, wird dadurch nach und nach bewusst, dass das so nicht sein muss. Gar nicht sein darf. Pläne sind Hilfsmittel für gute Zusammenarbeit.
Projektmanagement ist eine Sammlung von Hilfsmitteln, die es uns leichter machen, gut zusammenzuarbeiten. Punkt.
Eine dritte Gefahr: Die Weiterentwicklung von Software wird als Projekt betrachtet
Was ist ein Projekt?
Diese Frage kommt mir in der aktuellen Debatte zu kurz. Wenn wir im Spannungsfeld zwischen Routineprozessen (definierte Aufgabenstellungen, viele Wiederholungen, stets dasselbe produzieren, identische Abfolge von Tätigkeiten, gleichbleibende Verantwortung) und Projekten (neuartig, einmalig, unbekannte Aufgabenstellung, unbekannte Mitstreiter unterschiedlicher Disziplinen, unklare Verantwortung und Tätigkeiten) handeln, erfordert das einen reflektierten Umgang mit der jeweiligen Ausgangslage. Projekte erfordern eine andere Organisation als Routineprozesse. Bei Routineprozessen wird einmal für viele Wiederholungen organisiert, bei Projekten individuell für das einzelne Vorhaben.
Als agil bezeichnete Vorgehensweisen sind besonders häufig in der Softwareentwicklung anzutreffen. So meine Wahrnehmung. Dort funktioniert etwa Scrum unglaublich gut. Auch das meine Wahrnehmung. Softwareentwicklung wird als Projekt bezeichnet. Also wird daraus gefolgert, dass man dieses Vorgehen mühelos auf andere Projekte übertragen kann. Dabei ist Softwareentwicklung meist gar kein Projekt.
„Kein Projekt?“, höre ich jetzt die Frage schon laut im Raum stehen. Ja, kein Projekt. Die häufigsten Fälle, die mir begegnet sind, werden als Projekte bezeichnet und sind keine. Was als „Softwareentwicklung“ bezeichnet wird, ist meist eine „Software-Weiterentwicklung“. Hier noch eine Funktion dazu, dort noch eine Komponente. Das ist eher ein kontinuierlicher Prozess des „Funktionen-Hinzufügens“, der sich nur dadurch von der Automobilproduktion unterscheidet, dass die Inhalte der Tätigkeiten, also die Funktionen selbst andere sind. Die Vorgehensweise ist wiederholend. Ein reines Projekt ist ein solches Vorhaben nicht.
Diesen Unterschied sollte man sich bewusst machen, bevor man beginnt, Methoden zu übertragen. Die Softwarentwicklung in dieser Form hat einen höheren Standardisierungsgrad der Abläufe als etwa die Implementierung einer Geschäftsmodellinnovation. Erst wenn wir uns bewusst machen, wo die Unterschiede liegen, wird ein sinnvolles Übernehmen von Vorgehensmodellen möglich.
„Entspannt Euch!“
„Entspannt Euch!“, will ich rufen, denn Pläne sind keine Wahrheit und Lernen muss jeder. Was als Gegenteil von agil ins Feld geführt wird, ist das Ergebnis von Missverständnissen und Kontrollenthusiasten. Das, was im Moment als „klassisches Projektmanagement“ bezeichnet wird, ist schlicht eine Sammlung von Hilfsmitteln, die uns das Organisieren von guter Zusammenarbeit erleichtern. Diese Organisationsleistung benötigen wir, um neue, unbekannte Aufgabenstellungen anpacken zu können. Die dürfen dann gerne auch komplex sein.
Wir sollten dann nur anerkennen, dass wir zu Projektbeginn noch nicht alle Antworten kennen und deshalb keinen Plan für das gesamte Vorhaben machen können. Wir verwenden in Projektplänen gerne drei Fragezeichen als Symbol für die Bereiche, von denen wir noch keine Ahnung haben. Logische Konsequenz? Müssen wir uns wohl Ahnung beschaffen. Und warum drei Fragezeichen? Weil wir in Dokumenten leichter danach suchen können. Das macht uns die Arbeit leichter.
Die Methode „Projektmanagement“ selbst fordert nicht deren Einhaltung. Das sind stets die Menschen im Umfeld eines Vorhabens. Deren Einstellung und Haltung sind es, die aus einem Werkzeug ein Kontrollinstrument machen – oder eben ein nützliches Werkzeug. Dass sich an der Haltung vieler Beteiligter etwas ändern könnte, das wird vermutlich der große Verdienst derjenigen sein, die heute so vehement agil fordern und als Gegner klassischen Projektmanagements auftreten.
Wie bei jeder kleinen handwerklichen Tätigkeit auch, verwende ich Werkzeuge im Projektmanagement nur dann, wenn sie mir von Nutzen sind, mein Leben und das meiner Mitstreiter leichter machen etwa. Das was im Moment als „agil“ betitelt wird, fügt dieser Sammlung neue Werkzeuge hinzu oder manchmal auch schlicht eine neue Perspektive auf ein bekanntes Instrument. Die Werkzeugkiste des Projektmanagements wird umfangreicher.
Und was bei der ganzen Sache irgendwie logisch ist: Wer erst lernt, nachdem das Projekt bereits abgeschlossen ist, lernt zu spät. Das gilt völlig unabhängig von der Wahl des Vorgehensmodells.
Ihr
Holger Zimmermann
Projektmensch