Wie viel Agilität verträgt ein Projekt?

Agilität ist in aller Munde und das auch zurecht, löst sie doch unsere gewohnte Prozesswelt zusehends auf. Viele Projekte scheitern jedoch auch. Wurde sie zu früh eingeführt? War das Umfeld nicht geeignet für frische Ideen? Oder ist das System der Agilität in sich noch fehlerhaft? Mag sein…
In diesem Artikel möchte ich mich dieser Diskussion von der Projektseite her nähern.

Ich habe mich 1998 zum ersten mal mit Projektmanagement auseinandergesetzt, als wir die Organisationsberatung für eine Bank gemacht haben, die neben der Linienfunktion auch noch eine Projektorganisation implementieren wollten. Neben den Teamentwicklungs-Aspekten wurde auch noch die Software-Einführung von MS-Project begleitet. Schon damals wurde mir schnell klar: Sollte die Software das zentrale Steuerungsinstrument werden, würde dies einen enormen Pflegeaufwand bedeuten. Zudem schienen die Lösungen zu diesem Zeitpunkt noch nicht ausgereift und Multiprojektmanagement war auch noch nicht möglich. Ich hatte neulich die Gelegenheit, auch wieder einmal etwas tiefer einzusteigen und habe gemerkt, dass das PM nur noch komplexer – und damit aufwendiger – geworden ist. Man braucht also gute Gründe ein klassisches Projektmanagement aufrechtzuerhalten und die gibt es auch.

Staudamm
Starke prozessabhängige Aufgaben
Dokumentations- und Nachweispflicht

Im Grunde ist das klassische Projektmanagement der Versuch, die Prozesserfahrung aus der Linie auch auf Aufgaben außerhalb der Linie zu projizieren. (Kommt hier eigentlich der Projekt-Begriff her?)

Aus meiner Erfahrung ist aber für viele Organisationen der Hauptgrund das klassische PM-Modell beizubehalten eher subtil zu erahnen, und er nennt sich Führungsschwäche. Das Idealbild ist, dass man in einer Startphase die Phasen, Teilprojekte und Arbeitspakete zusammen mit den Projektmitarbeitern definiert, deren Aufwand schätzt und auf Köpfe verteilt. Durch die Abhängigkeiten entsteht der Projektplan; meist in Form eines Gantt-Diagrammes. Durch Modifikation der Ressourcen und Anpassung des Zeiteinsatzes, berechnet dieser sich ständig neu. Das Schöne für die Führungskraft dabei ist, dass sie die Mitarbeiter nicht ständig anspornen und motivieren muss. Schließlich wurde der Plan ja gemeinsam entwickelt und der Aufwand von allen akzeptiert und übernommen. Wenn es zu Verzögerungen kommt, ist der Schuldige schnell ausgemacht.

Doch wie heißt es so schön: “Laut Projektplan können neun Frauen in einem Monat ein Kind zur Welt bringen.” Rechnerisch korrekt, realistisch gesehen aber völliger Nonsens. Unter vielen Bedingungen funktionieren klassische Projekte meistens einfach nicht; zumindest nicht so wie man es geplant hat.
Doch halt! Dies ist nicht ganz richtig: Sie funktionieren schon, wenn man die Arbeitspakte nicht schätzen muss, sondern sie valide benennen und deren Aufwand gut einschätzen kann. Wenn die Daten ständig aktuell gehalten werden und man genug Puffer einplant. Kurzum wenn man auf ausreichend Erfahrung zurückgreifen kann.

Wenn dies nicht ständig gewährleistet werden kann, welche Optionen bleiben dann? Hier kommt die Agilität ins Spiel. Ende der Neunziger hatten die Software-Entwickler es langsam satt, dass Ihre Projekte unhaltbare Deadlines hatten, während viel Zeit mit sinnlosen Arbeitspaketen und Abstimmungsrunden verschwendet wurde, die dann für qualitativ hochwertige Programmierung fehlte. Es wurden Ordner-füllende Lastenhefte geschrieben und mit noch dickeren Pflichtenheften geantwortet. Letztendlich wurde dann mangelhafte Software herausgegeben, nur um noch rechtzeitig fertig zu sein. Wenn dann etwas falsch lief, waren natürlich die Entwickler schuld.

2001 trafen sich in Utah 17 Softwareentwickler und formulierten das agile Manifest, das bis heute als Grundphilosophie für dieses Thema steht:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und Anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

- Individuen und Interaktionen  mehr als Prozesse und Werkzeuge

- Funktionierende Software  mehr als umfassende Dokumentation

- Zusammenarbeit mit dem Kunden  mehr als Vertragsverhandlung
- Reagieren auf Veränderung  mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Quelle: Agiles Manifest

Doch was unterscheidet nun beispielsweise den Bau eines Staudamms von der Entwicklung einer Software? Im Grunde alles: Es ist sehr klar, wie ein Damm auszusehen hat. Es gibt dafür einen fertigen Plan und die spätere Funktionsweise ist auch eher simpel: Oben wird das Wasser angestaut, in der Mitte läuft es durch Turbinen, erzeugt Strom und fließt unten wieder raus. Letztlich wird er von unten nach oben gebaut. Wie auch sonst?

Ein Bau-Projekt ist das beste Beispiel für die Notwendigkeit des Wasserfall-Modells

Ich habe viele Lastenhefte gesehen – und ebenso viele Prozessschaubilder – welche eine Software abbilden sollen, doch diese wurden immer während des laufenden Projektes angepasst. Somit wurden sie schnell komplex, und Aufwände dabei zu kalkulieren war, wie auf bewegte Ziele zu schießen, und schon in der Mitte des Projektes hatte all das Papier, das im Vorfeld erzeugt wurde, nur noch einen Brennwert. Die Prozesse, die Daten, die Schnittstellen und letztlich die beteiligten Personen bringen immer eine enorme Komplexität in solche Projekte. Zu guter Letzt bietet Softwareentwicklung auch meist die Möglichkeit, dass nicht immer alles der Reihe nach geschehen muss. Mann kann Vieles auch dann schon mal erledigen, wenn die kompetentesten Mitarbeiter zu Verfügung stehen, und muss nicht warten bis die Zeit dafür gekommen ist.

Software-Entwicklung ist ein hervorragendes Beispiel für Wissensarbeit. Laut einer Definition des Fraunhofer Institutes ist Wissensarbeit

Komplex
Neuartig
Autonom

Ganz im Gegensatz zur prozessualen Arbeit. Diese ist sehr gut kalkulierbar und einschätzbar. Laut Wikipedia sind Projekte wie folgt definiert:

Ein  Projekt  ist ein  zielgerichtetes, einmaliges  Vorhaben, das aus einem Satz von abgestimmten, gesteuerten  Tätigkeiten  mit  Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von  Vorgaben bezüglich  Zeit,  Ressourcen  (zum Beispiel  Finanzierung  bzw.  Kosten,  Produktions– und  Arbeitsbedingungen,  Personal  und  Betriebsmittel) und  Qualität  ein  Ziel  zu erreichen.

Quelle: Wikipedia

Agil heißt, dass die Arbeitspakete bekannt sind und ggf. ständig weiter ergänzt, neu terminiert oder wieder entfernt werden. Die Flexibilität kommt durch das ständige Besprechen des aktuellen Status. Sogenannte Daily-Meetings oder Stand-ups sind fester Bestandteil der Projekt-Kultur. Sie sollten kurz und prägnant sein, dafür aber auch in kurzen Abständen terminiert werden. Die Tatsache, dass das Projektende nicht immer klar terminiert ist, macht viele Leute unruhig; liegt aber in der Natur der Dinge.

Meiner Meinung nach sollten die meisten Projekte eher eine hybride Form des Managements haben, wobei sie einmal mehr agil und ein mal mehr klassisch betrachtet werden können. So kann ein Meilensteinplan die Schwäche der Agilität ausmerzen, da hier das Ziel nicht deutlich in Sicht ist. Auch was die eventuell notwendige Dokumentation anbelangt. hat das traditionelle Projektmanagement seine Stärken. Die Dinge, die nicht geplant werden können, weil die Parameter noch nicht Alle bekannt sind oder sie sich ständig verändern, sind in mit der Agilität besser in den Griff zu bekommen.

Durch meine Projekte habe ich mittlerweile Microsoft Teams sehr zu schätzen gelernt: Hier kann man schön agile Elemente wie den MS Planner mit prozessualen Bestandteilen aus Excel oder PowerPoint kombinieren. Wer möchte, kann hier auch noch mit MS-Project-Online arbeiten, doch darf hier (wie bei allen Teams-Ansätzen) die Organisation nicht vergessen werden. Viele Dinge müssen geklärt und kommuniziert werden. Jedes Projekt kann dabei anders aussehen, was hat Vor- und Nachteile hat. Vorteile weil dann Teams optimal zu dem Projekt passt, Nachteile weil Jemand, der nicht ständig in diesem Projekt ist (z.B. Führungskräfte), sich ständig neu orientieren muss. Gerade im Multiprojektmanagement müssen auch viele Konventionen gefunden werden.

Ich bin aber davon überzeugt, dass es uns mit diesen Lösungsansätzen gelingt, das Managen von Projekten auf einen neuen Level anzuheben. Es wird aber auch ein Umdenken bei den Projektleitern erfordern, denn sie müssen sich in beiden Welten zurecht finden, sich das Beste heraus picken, verstehen und es auch zu vermitteln.