Agile Methoden sind in aller Munde. Viele Großkonzerne haben jetzt Product Owner, Squads, Tribes und Stand-Ups. Und damit ist nicht die Improvisations-Comedy gemeint. Nicht zu vergessen sind der Scrum Master und das Kanban Board.
Wir haben einiges davon auch, und nutzen agile Methoden für große Teile unserer Arbeit. Aber eben nicht immer und nicht für alles. Der gute alte Projektplan hat nach wie vor seine Daseinsberechtigung.
Projektplan in der agilen Welt? Mit Deadlines, Abhängigkeiten und so? Was soll das denn? Und noch viel wichtiger – warum sollte mich das interessieren?
Projektmanagement und Digitalisierung
Digitalisierungsprojekte sind oft vielfältig und komplex. Vielfältig meine ich dabei in mehrerer Hinsicht. Inhaltlich reichen unsere Projekten von Internet der Dinge und Künstlicher Intelligenz bis zu digitalen Prozessen am Arbeitsplatz und der Einführung großer ERP und DMS Systeme. Manche dieser Projekte sind technisch komplex, manche menschlich, manche prozessual, manche kaufmännisch, manche strategisch, und manche alles davon.
Was haben diese Projekte oft gemeinsam?
Oft erwarten unsere Kunden ein bestimmtes inhaltliches Ergebnis zu einem bestimmten Zeitpunkt. So funktionieren Ausschreibungen, Verhandlungen, Diskussionen. Dadurch sind von den vier Dimensionen eines Projekts, Zeit, Umfang, Qualität und Kosten, der Umfang und die Zeit sehr klar definiert, wobei der Umfang (das Ergebnis) der Haupttreiber ist. Ganz selten haben wir eine(n) Kundin, die/der sagt: „Ich möchte mit diesem Projekt in zwei Jahren ein neues Geschäftsfeld aufbauen, mit dem ich mindestens xyz Neukunden gewinne und xyz Umsatz mache. Es soll grob in die inhaltliche Richtung gehen, und jetzt testen wir die Idee erstmal.“ Dieser Ansatz ist jedoch eigentlich nötig, um Agilität richtig umsetzen zu können. Auf der Prozessoptimierungs- und Kostenspar-Seite hieße das „Ich möchte diesen Prozess um mindestens x% schneller und y% günstiger machen. Wie das geht, dürft ihr selbst herausfinden, und hier ist Budget dafür.“
Warum ist der Ansatz so schwierig?
- Kaum jemand ist es gewöhnt, auf diese Art zu arbeiten. Oft glauben wir Führungskräfte, dass wir genau wissen, was unsere Firmen brauchen, um an bestimmten Stellen erfolgreicher zu sein. Also versuchen wir, genau das einzukaufen, und am besten bis morgen. Auf jeden Fall bis zu einem festgelegten Zeitpunkt.
- Verträge mit Dienstleistern sind schwieriger zu managen. Man muss seine Dienstleister über andere Ziele steuern als über klar definierte Ergebnis-Meilensteine. Manche glauben, agiles Arbeiten ließe nur Time & Material Verträge mit Dienstleistern zu. Es geht auch anders, muss aber gut durchdacht sein.
- Das öffentliche Ausschreibungsrecht lässt das überhaupt nicht zu. Arbeitspakete, die ausgeschrieben werden, müssen extrem klar und detailliert definiert sein. Das passt nicht zu Agile.
Wo ist der Einsatz von Agile sinnvoll?
Agiles Projektmanagement und agile Methoden passen gut zu Entwicklungen, bei denen die Funktionalität, also der genaue Umfang einer Lieferung, nicht von vornherein bis ins Detail feststeht. Agiles arbeiten ist dadurch charakterisiert, dass der Umfang sich ändert und man damit hervorragend umgehen kann.
Auf viele technische Entwicklungsprojekte, z.B. Software, trifft diese Arbeitsweise zu. Dann brauche ich eine(n) Product Owner, die/der das kommerzielle Ergebnis verantwortet und in der Umsetzung viel Freiheit hat. Ich brauche agile Teams, die die Arbeitspakete in Eigenverantwortung in Sprints abarbeiten. Kanban-Boards oder ähnliches reichen aus, um die Arbeit zu organisieren, denn ein detaillierter, langfristiger Projektplan würde nach jedem Sprint auf den Kopf gestellt.
Wenn aber einfach ein bestimmtes Ergebnis geliefert werden soll zu einer Deadline, und keine Flexibilität bezüglich Features, Deliverables etc. besteht, hilft all das nur begrenzt. Kanban Boards zeigen i.d.R. keine Abhängigkeiten, keine Deadlines und Meilensteine.
Wo brauchen wir klassisches Projektmanagement?
Beispiel 1: Einführung eines ERP Systems. Wir wissen relativ genau, was getan werden muss. Ist-Prozesse analysieren, Soll-Prozesse definieren, passende Software auswählen, Einführung. Bei der Einführung gibt es eine Menge Dinge, die in bestimmten Abfolgen getan werden müssen, und wenn die Abfolge nicht stimmt, gibt es Probleme. Es gibt keine Flexibilität – das System benötigt Daten und Konfiguration, die Mitarbeiter*innen benötigen Prozesse und Schulungen. Unter diesen Umständen muss ich einen Projektplan haben, der all diese Dinge wiedergibt, damit ich auf einen Blick sehen kann, welche Auswirkungen Verschiebungen oder Veränderungen haben. Natürlich gibt es auch hier mal Veränderungen, und der Plan muss angepasst werden. Er ist jedoch einfach ein sinnvolles Tool, um dafür zu sorgen, dass nichts vergessen wird und die Reihenfolge sinnvoll ist.
Beispiel 2: Aufbau eines Internet of Things / LoRaWAN Anwendungsfalls zu einem bestimmten (knappen) Termin. Unsere Kund*innen haben manchmal gegenüber ihren Kund*innen zeitliche Zusagen einzuhalten, oder sie haben einen Vorstandstermin, bis zu dem etwas fertig sein muss. Selbst wenn wir vorher einen schönen agilen Entwicklungsrhythmus hatten mit einer festgelegten Ressourcenmenge, heißt es dann „All Hands On Deck“ und los gehts. Um das koordiniert und erfolgreich zu tun, muss zuerst ein Projektplan her. Was muss zuerst passieren – Hardware bestellen! Während die unterwegs ist, kann das Backend aufgesetzt werden, die Frontend- und Schnittstellenentwicklung beginnen und so weiter. In dem Projektplan steht relativ genau für den Zeitraum drin, wer was wann tut. So können wir effizient arbeiten und sofort reagieren, wenn etwas aus dem Ruder läuft.
Warum ist Projektmanagement überhaupt wichtig?
Es gibt immer wieder Kund*innen, mit denen ich darüber diskutieren muss, ob Projektmanagement nötig ist. Die Methoden sind je nach Projekt unterschiedlich, aber ohne geht es nicht. Projekte sind arbeitsteilig, und je mehr beteiligte Parteien ich habe, desto wichtiger ist es, diese zu organisieren. Nur mit gutem Projektmanagement kann ich sofort sehen, wenn etwas nicht funktioniert, und entsprechend handeln, um die Projektziele nicht zu gefährden. Der Wert der Funktion wird oft unterschätzt, und ihre Komplexität überschätzt. Gute Projektmanager*innen sind strukturierte Menschen, denen es leicht fällt, Dinge in sinnvolle Reihenfolgen zu bringen und Zusammenhänge zu erkennen. Außerdem sind sie pragmatisch, sehr gut im Bereich Kommunikation, und äußerst hartnäckig. Ob sie dann Agile, Prince2, PMP oder sonst welche Methoden anwenden – am besten wissen sie, welche wofür geeignet ist und suchen sich aus dem großen Werkzeugkasten immer das raus, was dem Projekt angemessen ist.
Foto von Jo Szczepanska auf Unsplash
