Agileres Projektmanagement mit Methode – mehr Qualität, weniger Risiko

Wenn man heute über Projekte spricht, fällt jedem sofort der Berliner Flughafen BER, der neue Stuttgarter Hauptbahnhof  S21 oder die Hamburger Elbphilharmonie ein. Manche denken auch an gescheiterte IT-Projekte der öffentlichen Hand wie INPOL-neu (150 Mio. DM) oder Fiskus (250 Mio. DM). Der Stammtisch und die Boulevardpresse wissen dann auch sofort, wie man es hätte richtig machen müssen. Hinterher. Dass man aber in München von dem Absturz eines Flugzeuges in der Innenstadt 1960 mit 52 Toten bis zur Eröffnung 1992 des Flughafen Franz-Josef-Strauß im Erdinger Moos dann auch 32 Jahre brauchte und die Kosten von 200 Mio. DM auf 8,5 Mrd. DM stiegen, wissen dann schon weniger. Beim Flughafen Düsseldorf schlampte man beim Brandschutz, wegen dem BER nicht eröffnet wurde. In Düsseldorf gab es bei einem Brand 17 Tote.

Für Carl Clausewitz war die Strategie „die Lehre vom Gebrauch der einzelnen Gefechte zum Zweck des Krieges„. Heute verwechselt man gerne die Strategie mit der Vision (also dem Ziel, wo man hin will in einer geänderten Zukunft). Aber schon im klassischen  Griechenland war der Strategos der, der für den Feldherrn planen musste, wie man das Kriegsziel erreicht. Wie viele Truppen brauche ich zur Erreichung des Kriegszieles? Wie viel Material, wie viel Proviant? Wie bekomme ich Proviant und Material zum Kriegstheater hin geschafft? Der Strategos war also derjenige, der sich um die Umsetzung der Kriegsziele kümmern musste, wenn sich der Tross wie bei Alexander dem Großen über viele Jahre von Makedonien über Afghanistan und Indien dann nach Babylon vorarbeitet. So wie heute der Projektmanager.

Projekte sind schwierig, bergen Risiken, haben Änderungen und verändern auch ihre Qualität, also das, was der Nutzer des Projektergebnisses eigentlich haben will. Nach der ersten Mondladung in den 1960ern entwickelten sich daher Projektmanagementmethoden, um Risiken (der Engländer versteht unter Risiken Bedrohungen und Chancen) beherrschbar zu machen und die Qualität zu heben. Eine Sonderrolle spielen dabei IT-Projekte, oder genauer Softwareprojekte, die auch eigene Methodiken entwickeln. Die Entwicklungen gehen dahin, dass von den anfangs eher starreren Methoden heute mehr Flexibilität oder Agilität erwartet wird. Wir sehen uns daher von den traditionellen Methodenwelten, mit denen man Gebäude bauen kann, olympische Spiele veranstalten kann oder eben zum Mond fliegen kann, drei Beispiele an: die GPM / IPMA (Gesellschaft für Projektmanagement / International Project Management Association), PMI (Project Management Institute) und PRINCE2 (Projects in controlled environments).

Generell haben diese drei Methodiken verbindliche Lehrkanons und zertifizierenden Prüfungen. Der Vorteil von allen dreien ist (die zudem auch noch leicht konvergieren), dass Mitarbeiter in unterschiedlichen Kontexten und Organisation schneller eingesetzt werden können, da die Verfahren standardisiert sind. Man kann also externe beschäftigen oder sich Pools von Projektmanagern schaffen, die in verschiedenen Projekten in der Organisation eingesetzt werden können.

Aus der Tabelle ist ersichtlich, dass die älteren Methoden eher Wert auf die persönlichen Kompetenzen des Projektmanagers mit umfangreichem Wissen legen, während bei den jüngeren Methoden Lehrbücher und Zertifikate verschlanken und die Organisation mehr im Vordergrund steht als die Person.

Am Beispiel von PRINCE2 sollen nun einige Merkmale diskutiert werden, die eine PM-Methode ausmachen. PRINCE2 strukturiert seine Lehre in 7 Grundprinzipien, 7 Themen und in einem Prozessmodell mit 7 Phasen.

PRINCE2 im Überblick

Zwei Beispiele sollen hier herausgehoben werden.

1.)  Steuern nach dem Ausnahmeprinzip: hiermit soll erreich werden, dass nicht in festem Takt Meetings abgehalten werden, sondern nur ausnahmsweise, wenn es wichtige Entscheidungen zu treffen sind, die zum Beispiel vom Projektmanager zum Lenkungsausschuss eskaliert worden.

2.) Der Business Case: anders als bei anderen Methoden soll nicht ein Budget verbraucht werden, sondern während der Laufzeit des Projekts ständig geprüft werden, ob das Projekt noch gerechtfertigt ist (Rechnet es sich noch? Sind die gesetzlichen Anforderungen noch so, wie ich sie durch das Projekt erfüllen will?).

PRINCE2-Prozessmodell: Steuern über Managementphasen

2009 wurde die Anzahl der PRINCE2-Prozesse auf sieben reduziert. Drei Ebenen werden unterschieden:

• Lenken: hier agiert der Auftraggeber und steuert, dass das Projekt das gewünschte Ergebnis liefert
• Managen: hier wird geplant, koordiniert, Arbeitspakete geschnürt, vergeben und abgenommen, Qualität, Änderungen, Fortschritt  und Risiko bearbeitet: die Domäne des Projektmanagers,
• Liefern: hier wird gearbeitet. Bei Softwareprojekten findet hier die Entwicklung statt.
• Wesentlich bei PRINCE2 ist, dass das Projekt in Managementphasen operationalisiert wird. Am Ende jeder Phase wird der Business Case überprüft. Stimmt er nicht mehr, kann das Projekt abgebrochen werden oder durch Änderungen korrigiert werden. Hierdurch bekommt PRINCE2 ein hohes Maß an Agilität.

Um das reine Projektmanagement herum hat die britische Regierung als Urheber weiter Methodiken gerankt für Programme, Portfolien, Projektmanagement Offices, usw.

Hat man sich für eine Methodik entschieden, verläuft die Integration in die Organisation meist in folgenden Schritten:

• Erstellung eine Projektmanagementhandbuches („Wie machen wir Projekte?“)
• Schulung der Projektmitarbeiter mit und ohne Zertifizierung
• Nutzung einer Projektmanagementsoftware
• Einrichtung eines Projektmanagementoffices (PMO), das die Standards pflegt und ihre Anwendung unterstützt

Nach einer Zeit kann man dann den Reifegrad des PM in der Organisation messen und evtl. durch gezielte Maßnahmen verbessern.

Einen Sonderfall stellt die Softwareentwicklung dar, die PRINCE2 auf der Lieferebene ansiedelt, die eigene Methodiken entwickelt hat. In den 1980er Jahren wurde das Wasserfallmodell modern: hintereinander erfolgen Anforderungsanalyse, Systemdesign und -spezifikation, Programmierung und Modultests, Integrations- und Systemtest, Auslieferung, Einsatz, Wartung. Sequentiell hintereinander werden die Module durchlaufen und die Arbeit plätschert wie an einem Wasserfall an ihnen herunter. Knickt man den Strahl an der Programmierung ab und stellt scheinbar korrespondierende Einheiten gegenüber (z.B. Systementwurf und Systemtest) kommt man zum V-Modell. Wasserfall und V-Modell liegt zugrunde, dass man glaubt, dass hinten das heraus käme, was man vorne plante. Möglicherweise Jahre vorher.

Bei Software wird das aber immer unwahrscheinlicher, insbesondere bei langen Laufzeiten der Projekte. Bei der in der staatlichen Steuerverwaltung geplanten Software Fiscus[4] z.B. verteilte man anfangs die Arbeit auf die Bundesländer. Man einigte sich auf die Integrationsplattform San Francisco von IBM. Als die Länder aber nicht synchron auf neuere Releases umstiegen, ließ sich das System nachher nicht mehr integrieren.

Zur Erhöhung der Flexibilität kamen daher in den 1990er agilere Softwareentwicklungsmethoden auf, die sich am Agile Manifesto[5] orientieren wie Kanban[6], Lean Project Management[7], DSDM (Dynamic Systems Development Method)[8], XP (eXtreme Programming)[9] oder Scrum[10].

Scrum ist eine sehr schlanke Methodik mit folgenden Hauptmerkmalen:

• Rollen: Product-Owner, Team, Scrum-Master, selbstorganisiert
• Zeremonien: Sprint-Planung, Sprint-Review, Sprint-Retrospektive und tägliche Scrum-Meetings
• Artefakte: Produkt-Backlog, Sprint-Backlog, und Burndown-Chart.

Idealerweise sitzt ein Team von 4-9 Personen in einem Raum, hat zum Projekt gehörige Informationen an der Wand hängen und arbeitet selbstorganisiert in Sprints Backlogs ab. Dabei entstehen schnell neue Produkte oder Produktinkremente, die  übernommen oder verworfen werden. So können hochdynamisch, auch mit iterativen Zyklen statt in ständiger Sequenzialität Produkte entstehen. Schneller und besser als mit Wasserfall oder V-Modell.

Scrum-Prozesse

Erforderlich ist hier natürlich auch Disziplin bei den Akteuren. Die Agilität wird durch genaues bearbeiten der Zeremonien in den richtigen Rollen mit den passenden Artefakten erreicht. Mangelt es an Disziplin (keine Dokumentation, Unwilligkeit zu Aufwandsschätzung) wird die gute Methode leicht diskreditiert. Für Scrum-Tools gibt es eine Übersicht[11].

In DSDM (Dynamic Systems Development Method) 8 steht ein iterativer Prozess im Vordergrund, der so lange durchlaufen wird, bis nach inkrementeller Implementierung  die Qualität des Projektendproduktes stimmt:

DSDM Atern Project Phases“ by Craig Cockburn – Own work. Licensed: CC BY-SA 3.0

Die agilen Methoden aus der Softwareentwicklung erzeugen Veränderungsdruck auf die klassischen Projektmanagement-Methoden, denen man bei falscher Anpassung schnell einen Hang zur Bürokratie nachsagt. Deshalb entstehen in den klassischen PM-Methoden Anpassungen, um das Agile zu integrieren.

• Das PMI hat z.B. eine neue Zertifizierung geschaffen, den PMI Agile Certified Practitioner (PMI-ACP), die klassische Projektmanager mit agilen Methoden vertraut macht (hauptsächlich Scrum).
• Für den Bereich GPM/IPMA gibt es zum Beispiel das Buch von Brian Wernhem Agile Project Management for Governement“. Hier werden klasssische Methoden um Teile aus Scrum, DSDM und XP (eXtreme Programming)
• Auch eine theoretische über die praktische hinaus Methodenintegration bietet zum Beispiel PRINCE2 mit „Agile Project Management: Running PRINCE2 projects with DSDM Atern“ aus dem Jahre 2007. Hier wird die Arbeitsebene von PRINCE2 für Practitioner agil strukturiert, z.B. Timeboxing eingeführt und Rollen verwendet, die differenzierter als Scrum sind. In 2015 ist dieser Ansatz zu „PRINCE2 Agile“ überarbeitet worden, was PRINCE2 voraussetzt und nun als Ergänzung von PRINCE2 angesehen wird.

Wesentlich ist auch, dass das klassische magische Dreieck aus Kosten, Qualität und Zeit ergänzt wird um den Umfang des Projektes (Scope; für Software auch Features) und nun die ersten drei fest sind und der Umfang variabel. Mit allen agilen Methoden werden auch die Iteration und das Arbeiten mit Inkrementen zur besseren Befriedigung der Kundenanforderungen eingeführt. Bei der Softwareentwicklung geht das hervorragend, bei einem Ingenieurbauwerk wie einer Autobahnbrücke muss man von vorne anfangen, wenn der Kunde nicht mehr vier Spuren sondern sechs Spuren wünscht und man kann auch nicht vier Spuren als erstes Inkrement bauen. Manche sagen, dass schon ein Viertel der Projekte mindestens auf Arbeitsebene agil durchgeführt werden.

Die folgende Abbildung zeigt, in welchen Bereichen wir eher ein klassisches Projektmanagement haben werden und in welchen eher ein agiles. Dabei kann es sein, dass man auf Lenkungsebene und Managementebene klassisch operiert und auf Arbeitsebene agil. Auch können einzelne Elemente von bewährten Methoden zum Einsatz kommen.

Klassische oder agile PM-Methode oder Mischungen?

Zusammenfassend lässt sich sagen, dass das Projektmanagement in den letzten Jahrzehnten, auch im Sinne einer funktionalen Differenzierung sozialer Systeme nach der Systemtheorie von Niklas Luhmann, in methodischer Weise in den Organisationen mit Standard-Frameworks entwickelt hat, die zunehmend durch agile Methodensätze auf der Arbeitsebene ergänzt werden. Gelingt eine Integration gut, werden die Projekte in der Organisation (Unternehmen oder Behörde) einfacher bearbeitet, die Qualität steigt und das Risiko sinkt.

Fußnoten

[1] http://de.wikipedia.org/wiki/International_Project_Management_Association