Beiträge

Ohne Architektur kann es kein nachhaltiges Projekt-Management geben

Im Projekt-Management stehen die Projekt-Organisation und die Organisation der Abläufe im Vordergrund. Abgrenzung und Abstimmung mit anderen Lösungen und Vorhaben sind für einen Erfolg ebenso wesentlich; hier können Architektur-Methoden nachhaltig unterstützen.

Einleitung
Im klassischen Projekt-Management gehört es zur Initialisierungsphase eines Projekts, dass der Kontext evaluiert und Anforderungen erhoben werden. Der Fokus auf einzelne Projekte ist insbesondere in grossen Organisationen wenig nachhaltig, einerseits, weil gewisse Grundlagen immer wieder abgeklärt werden, andererseits, weil kaum projektübergreifend gemeinsame Anforderungen erkannt werden. Dadurch entstehen Insellösungen, die gerade so weit reichen, wie das nähere Umfeld des Projekts einbezogen wurde.
Um die verschiedenen Projekte und die dabei entstehenden Anwendungen in einem Unternehmen aufeinander abzustimmen, sind Methoden der Unternehmensarchitektur (um Missverständnisse zu vermeiden oft mit „Enterprise Architecture“ bezeichnet) geeignet. Damit können Anforderungen für ein Portfolio von Lösungen projekt-übergreifend bearbeitet werden, sodass die jeweiligen Realisierungen für sich fokussiert und Interaktionen zwischen Anwendungen gut identifiziert und spezifiziert sind. Damit leisten Architektur-Methoden einen essentiellen Beitrag für eine nachhaltige Steuerung von Projekten und für die Realisierung übergreifender, langlebiger Lösungen.

Wozu Architektur?
Die IT-Architektur befasst sich mit Software-Systemen, die aus verschiedenen miteinander kommunizierenden Software-Komponenten bestehen. Diese Umgebungen werden ständig verändert und neuen Bedürfnissen, Anforderungen und auch Technologien angepasst. Methoden der IT-Architektur unterstützen diese Veränderungen, dabei dienen sie den Strategien des Unternehmens und leisten damit einen wertvollen Beitrag zur Erreichung der Unternehmensziele.
Eine IT-Architektur beschreibt die grundsätzliche Organisation eines IT-Systems, sie definiert, spezifiziert und beschreibt das IT-System mit seinen Komponenten sowie deren Beziehungen und Abhängigkeiten. Architektur-Entscheide bezüglich Funktionalität, Systeme und Produkte sind ein wichtiger Aspekt, weil einmal getroffene Entscheide später nicht mehr leicht geändert werden können, ja oft praktisch unveränderbar sind. Weiter sind Anforderungen und Einschränkungen zu berücksichtigen, womit Aspekte wie Machbarkeit, Kosten und Risiken ebenfalls im Rahmen der Architektur betrachtet werden.
Hauptaufgabe des Architekten ist Business und IT in Einklang zu bringen und die unterschiedlichen Sichten dieser beiden Seiten zu überbrücken. Dabei helfen Methoden der IT-Architektur wesentlich, die Komplexität der Gegebenheiten durch Abstraktion und Eliminieren von Details zu reduzieren. Das führt zu Darstellungen und Sichten, die besser diskutierbar sind und damit zu Lösungsansätzen, die die Komplexität adäquat abbilden.
In Kürze trägt die IT-Architektur dazu bei, dass die richtigen Dinge adäquat und korrekt ausgeführt werden (in amerikanischer Kürze: „doing the right things right“; diese Aussage ist eine Variante von Peter Druckers „Efficiency is doing things right; effectiveness is doing the right things.“).

Ohne Scope geht es nicht!
Ein wesentlicher Aspekt, um die „richtigen Dinge“ zu tun ist die Abgrenzung der einzelnen Anwendungen und damit insbesondere der Projekte. Die IT-Architektur bestimmt für jede Anwendung und jedes System den Scope zusammen mit dem Kontext. Mit dem Scope wird definiert, was von einem System, einer Anwendung und damit von einem Projekt gelöst wird und was nicht. Dies schliesst ein, dass die Interaktionen mit den benachbarten Systemen, Anwendungen etc. identifiziert und beschreiben werden. Dabei ist eine Portfolio-Sicht massgebend, die anzeigt, wo welche Anforderungen erfüllt werden.
Erfahrungen vieler Projekte zeigen, dass ohne eine klare Bestimmung des Scope und ohne entsprechende Identifikation der Schnittstellen zu benachbarten Lösungen und damit Projekte rasch in die Irre gehen können. Es genügt dabei nicht, in einer Liste die Inhalte aufzuzeigen, es muss entsprechend sichtbar gemacht werden. Eine grafische Darstellung, von verschiedenen Architektur-Methoden als «Kontext-Diagramm» bezeichnet, illustriert solche Zusammenhänge.
Aus der Perspektive der Unternehmensarchitektur wird entschieden, welches System bzw. welches Projekt entsprechende Aufgaben übernimmt. So kann das Management eines Portfolios von Informatik-Lösungen auf eine nachhaltige Grundlage gestellt werden. Die Steuerung über die Unternehmensarchitektur fokussiert die einzelnen Vorhaben und sorgt für eine nachhaltige Abstimmung der Lösungen. Damit können Architektur-Methoden aktiv zu einer adäquaten Definition des Scopes der einzelnen Vorhaben beitragen.

Architektur-Übersichten
Im Rahmen der IT-Architektur werden verschiedene Sichten eingesetzt (so wie ein Gebäude auch mit verschiedenen Ansichten dargestellt wird). Die Darstellung des Scope und des Kontexts ist somit eine Sicht, sie wird ergänzt durch eine Übersicht der verschiedenen Komponenten einer Anwendung bzw. eines Systems. Dabei wird u.a. auch erkannt, wenn verschiedenen Lösungen dieselbe Grundlage (z.B. Kommunikation oder Datenbank) verwenden.
Eine Architektur-Übersicht zeigt die innere Struktur einer Lösung, einer Anwendung bzw. eines Systems auf und benennt die wesentlichen Bausteine bzw. Komponenten. Eine solche Übersicht zeigt auch die wesentlichen Schnittstellen zu anderen Anwendungen auf. Eine grafische Darstellung, von verschiedenen Architektur-Methoden als «Architektur-Übersicht-Diagramm» bezeichnet, illustriert solche Zusammenhänge.
Aus einer Unternehmenssicht ist dabei zentral, dass damit Insel-Lösungen verhindert werden und keine Doppelspurigkeiten aufgebaut werden. Eine systematische Darstellung der Architektur-Übersichten verhindert, dass Anwendungsteile mehrfach realisiert werden oder Basis-Software mehrfach beschafft wird; dabei hilft wiederum eine Portfolio-Perspektive.
Heutige Technologien und eine Service-Orientierte Architektur (SOA) unterstützen Interaktionen zwischen Anwendungen und Systemen wesentlich. Dabei stellen Services einer Anwendung deren Information und Funktionalität einem grösseren Kreis von Nutzern zur Verfügung. Auf der einen Seite werden Services mit entsprechenden Schnittstellen (Web-Services, APIs) angeboten, die von einer anderen Seite aufgerufen werden können. So können viele Nutzer auf Services eines Anbieters zugreifen. Architektur-Methoden unterstützen den Aufbau und das Management eines Services-Portfolios.

Schlussfolgerungen
IT-Architektur kann Projekte und Entwicklungsprogramme nachhaltig bei der Steuerung der Vorhaben unterstützen. Sie liefert Inhalte und stellt Zusammenhänge dar. Deshalb sollten Projekte nicht ohne eine Architektur-Perspektive unternommen werden.

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

Warum die Agilen mit Wasserfällen nicht klarkommen (und umgekehrt) und warum sie miteinander Frieden schliessen sollten

«Agile or waterfall, that is the question». Abgegriffener geht’s nimmer, aber viel zu viele Diskussionen drehen sich nach wie vor um diesen Spruch. Allein, die blosse Polarisierung bringt uns nicht wirklich weiter. Was aber, wenn wir einen echten Lernprozess durchliefen und zu zwei banalen Erkenntnissen kämen: 1. Es kommt drauf an und 2. Zusammen ginge es besser.

Monty Python’s[1] C und P

Kennen Sie Monty Pythons epochales Werk «The Meaning of Life»? Die berühmte Szene in einer grauen, düsteren Strasse in Bradford, Yorkshire? Auf der einen Seite der Strasse wohnen die C (die Coolen), ein buntes, agiles und furchtbar fruchtbares Volk, das sich vehement und singend gegen die Verschwendung wehrt und auf der anderen Seite der Strasse leben die P (die Planer)[2]: langweilige, graue Figuren, mehr oder weniger unfruchtbar, und ohnehin nichts verschwendend.

Genau dieses Bild befällt mich immer auf subversive Weise, wenn wieder irgendwo die Diskussion um die Vorzüge und Nachteile von agilen gegenüber traditionellen Projektmanagement-Methoden losbricht.

Während allerdings die Polarisierung der C und P bei Monty witzig und humorvoll (zugegeben als tiefschwarzer britischer Humor) daherkommt, ist dieselbe Polarisierung von Agilen und Wasserfällen dumpf, humorlos und (sorry Monty, diesmal gehört das Wort mir) absurd.

Entsorgung von Schwachsinn tut not (I): Das Wasserfallmodell ist nicht

Genauso wie die amerikanische Regierung 2003 der ganzen Welt weismachte, dass Saddam Hussein über Massenvernichtungsmittel verfügt haben soll, bis sie den Krieg herbeigeschwatzt hatten, reden uns die ganz Agilen schon viel länger ein, dass die zu verdammende Methode die ‘Wasserfallmethode’ sei. Sie haben bis heute nicht verstanden, dass der erste, der die angebliche ‘Wasserfallmethode’ beschrieb[3], a) das Wort ‘Wasserfall’ in seinem Papier nie erwähnte, b) festhielt, dass er die Umsetzung eines solchen Verfahrens als ‘… risky and invites failure’ beurteilte und c) folglich nicht lineare, sondern iterative Methoden propagierte. An guten Feindbildern muss man nur lange genug festhalten, dann werden sie wahr und der Krieg kann beginnen. Sprechen wir deshalb besser von traditionellen oder iterativen Methoden, statt von Wasserfall und ähnlichem Schwachsinn.

Entsorgung von Schwachsinn tut not (II): Wahr und falsch sind auch nicht

Jeff Sutherland, der wohl bekannteste Missionar von SCRUM (und ehemaliger Kampfpilot in Vietnam, was vielleicht das Eine oder das Andere erklärt), der populärsten agilen Methode, lässt sich in seinem Buch ‘SCRUM: The Art of Doing Twice the Work in Half the Time’ (2014) über Gantt-Charts, den Balkendiagrammen also, mit welchen ‘Wasserfallprojekte’ gerne beschrieben werden, aus: «The only problem with them is that they are always, always wrong». Zwei Seiten später sagt Sutherland über ‘seine’ Methode: «Now it is the only way proven to help projects like these…”. Sutherland hat recht, nur geht der Dreh andersrum! Mit einer Projektmanagementmethode kann man Modelle von Vorhaben bilden und dass Modelle allesamt falsch sind, hat der berühmte George Box schon 1978 festgehalten: «All models are wrong, but some are useful».

Und umgekehrt wäre ja überhaupt nie ein Projekt gelungen, bevor SCRUM erfunden war.

Also lassen wir die rhetorischen Kraftmeiereien (Draufhauen statt Denken) und wenden uns der Lösung des Problems zu. Denn längst nicht alles, was die Menschen mit traditionellen Methoden hergestellt haben und immer noch herstellen, war/ist ein Desaster und längst nicht alles, was die Menschen mit agilen Methoden bauen, ist das Himmelreich.

Es wird schon so sein, dass die Traditionellen allzu lange ihre Methoden vom Hundertsten ins Tausendste verfeinert, erweitert und ergänzt haben und dabei übersehen oder verschlafen haben, dass sich der Fokus längst von Projekt per se hin zum Kunden und zum Produkt bewegt hat. Bis 2001 mit dem Agilen Manifest[4] eine pointierte, aber wohldurchdachte Richtungskorrektur eingeleitet wurde. Und es wird wohl auch so sein, dass vor allem die hard-core Agilen die konservativeren Teile (die Werte auf der ‘rechten Seite’) des Agilen Manifests gleich am Stück über Bord warfen und fortan jede Schraube mit dem Hammer einzuschlagen gedachten. Das unablässige und streng getaktete Streben nach dem Minimum (sic!) Viable Product produziert allerdings meist später mit viel Geld zu behebende Technische Schulden, obwohl der vorerwähnte Scrum-Papst Jeff Sutherland in seinem Buch dem Thema ‘Waste is a crime’ ein ganzes Kapitel widmet und darin in einem Abschnitt festhält ‘Do it right the first time’! Was sich in der einen Situation als durchaus logisch darstellt, erweist sich einen Moment später als Widerspruch.

Und zweifellos hat es in der Vergangenheit häufig zu lange gedauert, bis man einem sich abzeichnenden Misserfolg den Stecker gezogen hat, aber genauso fraglich ist es, wann das ‘Fail fast, fail often, fail forward’-Mantra nur eine dummdreiste Ausrede ist oder ein Vorhaben tatsächlich vorwärtsbringt.

Es trifft einmal mehr zu, was fast immer zutrifft: Es kommt drauf an!

Nicht einmal bei Socken gilt «One size fits all», wie kann man dann bei Projektmethoden solche oder ähnliche Erwartungen haben?  Es kommt eben drauf an, welches Problem es zu lösen gilt und welches die dafür am besten geeignete Methode ist. Und wir tun gut daran, von den verschiedenen Methoden zu lernen, sie in geschickter und nutzbringender Weise zu kombinieren und zu nutzen.

Einigkeit herrscht mittlerweile darüber, dass prinzipiengeleitete Kollaboration besser funktioniert als wenn starre Regelwerke Teams in Ketten legen. Das führt uns direkt zu einigen Fundamentalprinzipien des Projektmanagements:

  1. Tailoring
    So nannte man früher einmal das Prinzip des Anpassens der Prozesse und Werkzeuge an das zu lösende Problem. Tailoring ist aktueller denn je! Immer. Überall. Bei den Traditionellen und bei den Agilen.
  2. Planung (die Lieblingszielscheibe der militant Agilen…)
    Egal wie sehr wir mit einem Projekt unbekanntes Terrain betreten, wie wenig wir und unser Kunde zu Beginn eines Projekts wissen, wie unvollständig der Product Backlog ist und wie sehr wir uns auf Kundenwünsche einlassen wollen, wir kommen um ein Minimum an Planung nicht herum. Lars Vollmer hat das treffend beschrieben; «… Aber andererseits gibt es dennoch keinen Grund, Planung gering zu schätzen. Es ist nämlich so: Es gibt in jeder Zukunft einen bekannten und einen unbekannten Teil. Für den bekannten können Sie planen, für den unbekannten müssen Sie sich gut vorbereiten. Die Klugheit besteht darin, das eine vom anderen zu unterscheiden…»[5]Das Problem, dass sich Traditionelle oft der Überplanung hingeben und Agile notorisch unterplanen, ist bekannt und lässt sich lösen: durch Austausch und Zusammenarbeit der beiden Lager.
  3. Schätzungen
    Wie wir’s auch drehen, wir kommen um angemessene Schätzungen (Aufwände, Kosten, Zeitdauern) nicht herum, wir brauchen Schätzungen und kontinuierlich verbesserte Schätzungen, um eine halbwegs vertrauenswürdige Planung hinzukriegen. Ausschliesslich relative Schätzungen (à la Planning Poker) helfen nur bedingt, spätestens wenn der Kunde eine ‘Hausnummer’ will, um zu wissen, wie tief und wann er in seine Tasche greifen muss, sind auch absolute Grössenordnungen gefragt.
  4. Zusammenarbeit
    Zugegeben, vor allem die Traditionellen haben sich zu oft und zu sehr nur auf Kosten, Termine und Umfang des Projekts konzentriert und sich zu wenig um den Kunden, sein Bedürfnis und das dereinstige Produkt gekümmert. Obwohl alle haargenau wissen, dass die intensive Zusammenarbeit, der direkte und dauernde Austausch und ebenso die dauernden Rückmeldungen (bidirektional!) für den Projekterfolg und für die daraus entstehenden Produkte und Werte massgebliche Schlüsselfaktoren sind.
  5. Projekt vs Produkt
    Noch heute ist bei vielen Traditionellen fest verdrahtet, dass der Projekterfolg im Vordergrund steht und alles, was danach folgt (Produkt, dessen Akzeptanz, Betriebs- und Wartungskosten etc.), von sekundärer Bedeutung ist. Diese Haltung ist in mehrerlei Hinsicht schlicht falsch. Was nützt mir ein hervorragend abgewickeltes Projekt, wenn der Markt das entstandene Produkt nicht zur Kenntnis nimmt, nicht akzeptiert, nicht kauft oder dieses nicht erfolgreich betrieben werden kann? Ford Edsel (1957) und die Suchmaschine Alta Vista (1995) sind nur zwei bekannte Beispiele für solche Dramen. Es braucht mehr für den Erfolg, viel mehr. Das Verständnis für eine entsprechend ausgebaute Zielhierarchie ist vorhanden, sie gilt für die Agilen wie für die Traditionellen.
  6. Time-to-market
    Keine Frage, der Druck und die Geschwindigkeiten, rasch Innovationen umzusetzen und auf den Markt zu bringen, hat in den letzten Jahren massiv zugenommen. Oft sind wenige Tage bis Wochen Vorsprung auf die liebe Konkurrenz matchentscheidend. Da kann es durchaus sein, dass agile Verfahren helfen, den Wettlauf mit der Zeit zu gewinnen. Aber: nicht immer ist Time-to-market das entscheidende oder gar das einzige Erfolgskriterium. Gerade wenn man besser als die etablierte Konkurrenz (neudeutsch: disruptieren) sein will, gelten ganz andere Massstäbe und Faktoren wie bessere Qualität, besseres Kundenerlebnis, besseres Marketing, höhere Profitabilität etc. Hätte sich die Handelsplattform Siroop mehr Zeit genommen, einen besseren Namen zu suchen, bessere Werbung zu machen, besseres Marketing zu betreiben, hätte sie sich vielleicht gegen die etablierten Plattformen durchsetzen können, aber offensichtlich hat man sich die Zeit für ein besseres Produkt nicht genommen. Interessant wird auch sein, wie der Fall Tesla ausgehen wird. Es ist zwar cool, wenn man als Europäer seinen Tesla irgendwo in den USA per Handy öffnen kann, aber noch cooler wäre es, wenn das Auto auch wie ein Auto nach den Regeln des Gewerbes gebaut wäre.
  7. Kleine Projekte
    Verschiedene Untersuchungen haben gezeigt, dass die sequentielle (wasserfall-mässige?!) Abwicklung von kleineren Projekten gegenüber der monolithischen Durchführung von Megaprojekten massive Vorteile aufweist, dies sowohl bei der Projektentwicklung, bei der Stabilität des Vorhabens, bei Wartung und Unterstützung des späteren Produkts. In diesem Punkt sind die Agilen klar im Vorteil, die kleinteilige Entwicklung ist ihr Standard. Umgekehrt fragt man sich natürlich, weshalb trotz deutlich geringeren Erfolgschancen, immer wieder Megaprojekte bis hin zum Typus Mission Impossible in Auftrag gegeben werden. Das Prinzip der kleinen Projekte gilt genauso für Agile wie für Traditionelle.
  8. Das Team
    Das Zitat «Culture eats strategy for breakfast» wird Peter Drucker zugeschrieben. Unabhängig davon, ob Drucker dies tatsächlich gesagt hat, ist nachvollziehbar, dass gutes Teamwork enorm weit trägt und umgekehrt ein dysfunktionales Team ein Projekt rasch und zuverlässig an die Wand fahren kann. Damit sind wir beim allerwichtigsten Faktor für den Projekterfolg und wie schon zuvor illustriert, gelten auch die Prinzipien guter Teams sowohl für die Agilen wie für die Traditionellen.Wenn es nämlich gelingt, Teams zu schweissen, die verstehen, worum es im Kern bei einem Projekt geht, ohne dass man den einzelnen Teammitgliedern sagen muss, was sie zu tun haben, die sich also selber organisieren, die voneinander und füreinander lernen, die sich an gemeinsam festgelegte Prinzipien halten, dann ist die allerwichtigste Bedingung für den Projekterfolg erfüllt.

Also zurück zum Tailoring, das in diesem Fall auch gerne Cherry-Picking genannt werden darf

Lasst uns doch agile und traditionelle Techniken und Methoden gezielt immer dort einsetzen, wo sie uns am meisten nützen und helfen. In der Tendenz sind das agile Methoden, wenn wir die unbekannten Teile der Zukunft erschliessen müssen und traditionelle Techniken, wenn wir bereits mehr über die Zukunft wissen.

Und zurück zu Monty

Zum Schluss der Strassenszene bewegen sich die C und die P zusammen singend über die triste Bradforder Strasse in eine bessere Zukunft.

Allerdings trennen sich kurz danach unsere Wege von jenen von Monty Python. Während es bei «The Meaning of Life» zunehmend absurder zu und her geht, begeben wir uns friedlich und gemeinsam auf die Strasse des «Meaningful Life Cycle».


[1] Visionär wie die Truppe war, hat sie sich bereits 1969 mit Python befasst, also gut 20 Jahre bevor man das Potential von Python für Datenauswertungen erkannt hat…

[2] Eigentlich heissen sie anders, aber ich will mich jetzt nicht auch noch aufs religiöse und/oder politische Glatteis begeben.

[3] Winston P. Royce; Managing the Development of Large Software Systems; IEEE Wescon, 1970

[4]    Manifesto for Agile Software Development:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

[5] Lars Vollmer; Wie sich Menschen organisieren, wenn ihnen keiner sagt, was sie tun sollen; Gorus Certified Publications; 2. Auflage, 2018

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

Frage an Radio Eriwan: «Benötigt die Welt eine weitere Projektmanagement-Methode?». Antwort von Radio Eriwan: «Im Prinzip vielleicht doch (nicht)!»

Wie wir wissen, gibt es Dutzende von PM-Methoden, über sie alle wird leidlich gestritten, weil sie zu kompliziert, zu simpel, viel zu umfangreich oder einfach nur unmöglich, unpassend und unbrauchbar sind. Nach 10 Jahren Entwicklungs- und Erprobungszeit kommt jetzt auch noch die EU-Kommission um die Ecke und stellt ihre neue Methode PM2 anlässlich einer 2-tägigen Konferenz in Brüssel vor. Da fragt man sich, ob PM2 nun eher ein Beitrag zum Problem oder ein Beitrag zur Lösung ist.

Noch eine Methode mehr?
Die Zahl bekannter PM-Methoden ist Legion, hier eine höchst unvollständige Liste:

  • APM 6
  • BGW
  • HERMES 5
  • IPMA ICB 4.0
  • ISO 21500
  • Kanban
  • Kepner-Tregoe
  • MoV – Management of Value
  • MSP – Managing Successful Programmes
  • PMBoK 6th Ed.
  • PRINCE2
  • SCRUM
  • V-Modell XT 2.0
  • etc.

Dazu kommen unzählige Separat- und Spezial-Methoden für Risikomanagement, Portfoliomanagement etc., ganz zu schweigen von branchenspezifischen Vorgehensweisen.

Nun also hat die EU-Kommission mit PM2 (ausgesprochen “PM squared”), oder besser gesagt Open PM2 publiziert. Da darf man schon mal fragen, was das soll? Allerdings, ohne genauer hinzuschauen, wird man’s nicht rausfinden.

Woher kommt PM2?
Die EU besteht aus 17 Organisationen, 45 Behörden und über 30’000 Mitarbeitenden, diese geben im Zeitraum von 2014 – 2020 rund € 959 Mia aus, 6% davon für Administration, die übrigen 900 Milliarden werden in verschiedenste Programme investiert. 20% dieser Mittel verwaltet die EU-Kommission direkt, die anderen 80% werden durch rund 100 weitere Organisationen verwendet. Dass sich die EU-Kommission unter diesen Umständen Gedanken zu Effizienz und Standardisierung Gedanken macht, ja Gedanken machen muss, versteht sich von selbst.

Vor diesem Hintergrund hat die EU-Kommission 2007 die Entwicklung der Methode in Auftrag gegeben. Die Version 1 wurde anhand typischer IT-Projekte geprüft, die Version 2.0 wurde Kommissionsintern eingesetzt und die Version 2.5 fand in weiteren EU-Organisationen, namentlich bei den Finanzinstitutionen wie der EZB Anwendung, bis schliesslich die Version 3, bzw. Open PM2 1.0 Anfang Februar 2018 anlässlich der ersten Open PM2-Konferenz in Brüssel einem breiteren Publikum vorgestellt wurde.

Was ist PM2?
In den Worten der EU-Kommission: “PM2 is a Project Management Methodology developed and supported by the European Commission. The purpose of PM2 is to enable project teams to manage projects in an effective and efficient manner for the purpose of delivering solutions and benefits to their Organisations and Stakeholders”.

Und in den Worten des Autors dieses Beitrags: «PM2 ist eine schlanke, aber dennoch gut dokumentierte, moderne, intelligent konstruierte End-to-end PM-Methode». Folgender Nutzen soll die Methode auszeichnen:

Schlank?
 Der PM2 User Guide hat auf 137 Seiten Platz, die Methode selbst ist auf 73 Seiten dokumentiert und illustriert («alles andere ist Beilage», also Anhänge). Auch wenn man die Gefahr läuft, Äpfel mit Birnen zu vergleichen, PM2s Dokumentation ist deutlich schlanker als jene anderer Methoden (HERMES 5.1: 180 Seiten; PMBoK 6th Edition: 980 Seiten (inkl. Agile Practice Guide); IPMA ICB 4.0: 432 Seiten (inkl. Programm- und Portfolio-Management); V-Modell XT 2.0: 500 Seiten (V 1.4: 932 Seiten)). Natürlich muss kürzer nicht besser sein, aber mit Sicherheit ist ‘kürzer’ intellektuell besser in den Griff zu bekommen.

Ergänzend zum kurzen und knackigen User Guide stellt PM2, wie andere Methoden auch, dem Anwender eine ganze Menge an sinnvollen Hilfsmitteln zur Verfügung, wie zum Beispiel eine Sammlung von 32 Vorlagen für sämtliche Artefakte der Methode, einen sehr umfangreichen Study Case, der dem oft gehörten Ruf nach praktischen Beispielen nachkommt. Anhand des Study Case werden zwei Dinge der Methode sehr schön illustriert: 1. der Umgang mit den Templates und 2. das Tailoring der Methode.

Intelligent konstruiert?
Die Autoren waren sich nicht zu schade, für diverse Elemente von PM2 Anleihen bei anderen Methoden zu machen, statt zwanghaft bewährte Konzepte anders zu beschreiben oder zu bezeichnen. So entspricht zum Beispiel das Phasenkonzept von PM2 recht genau dem Prozessgruppenkonzept von PMBoK, wobei uns PM2 allerdings die recht anspruchsvolle und in der Praxis weniger hilfreiche ‘Prozessordnung und -hierarchie’ von PMBoK erspart. Das Rollenmodell ist klassisch und das Zusammenspiel der Rollen/Governance für die Ergebnisse mit der ebenfalls klassischen RAM (Responsibility Assignment Matrix) bzw. RACI-Matrix beschrieben.

Namentlich von PRINCE2 hat PM2 die umfassende Sicht über den ganzen Lebenszyklus eines Systems oder Ergebnisses übernommen (Business Case als Kern des Projekts, Fokus weg von der einseitigen Projektsicht hin zu Wertorientierung und Nutzen der Projektergebnisse).
Wie zum Beispiel HERMES 5 definiert auch PM2 keine Werkzeuge als Bestandteile der Methode selber, sondern überlässt diese dem Anwender, bietet aber mit dem PM2-Guide «Tools und Techniques» einen Überblick über 35 populäre PM-Werkzeuge, dazu gehören unter anderem PESTEL-Analyse, Critical Path Method, Earned Value Management, Balanced Scorecard Methode etc. Und bei jedem dieser Werkzeuge sind eine Handvoll Links angegeben, die auf weiterführende Unterlagen verweisen.

Modern?
PM2 ist, wie viele andere klassische Methoden planend/predictive (böse Mäuler sagen «Wasserfall»), Methoden, ausgelegt:


verfügt aber sowohl in prozessualer wie in organisatorischer Hinsicht über wohldefinierte Anschlusspunkte zu agilen Vorgehensweisen:

Wie aus obigem Schema für die PM2-Organisation hervorgeht, bestehen nicht nur Anschlusspunkte für agile Verfahren und deren Organisation, sondern die Organisation ist a priori auf eine enge Zusammenarbeit mit dem Business/Fachseite/ Kunden einerseits und der Projektentwicklung andererseits ausgelegt.

End-to-end?
PMist eine vollständige PM-Methode und hat entlang der Zeitachse nicht alleine das Projekt im Fokus, sondern den ganzen Produktzyklus.

Die Methode ist nicht nur horizontal vollständig, sondern auch vertikal, also von der Projekt-Governance über den (Projekt-) Lebenszyklus und die Projektprozesse bis hin zu den Artefakten.
PM2 umfasst und beschreibt essentielle Mindsets für Projektmitarbeitende:

Was nun?
Open PM2 ist eine nützliche und wohldurchdachte Projektmanagement-Methode, sie ist innerhalb der EU-Kommission und -Organisationen gut erprobt, sie offen und kostenfrei für jedermann verfügbar (die Ausbildungen und die Zertifizierungen stehen zurzeit erst EU-Angestellten zur Verfügung). Open PM2 soll weiter geöffnet werden, inklusive des Ausbildungs- und Zertifikationsprogramms.
Machen Sie sich ein Bild, es wird nicht zu Ihrem Schaden sein.

Hier finden Sie Angaben zur Open PM2 Initiative:
https://ec.europa.eu/isa2/solutions/open-pm2_en
und hier können Sie den PM2-User Guide runterladen:
https://publications.europa.eu/en/publication-detail/-/publication/0e3b4e84-b6cc-11e6-9e3c-01aa75ed71a1
Hier findet man das PM2-Wiki (Registrierung erforderlich):
https://webgate.ec.europa.eu/fpfis/wikis/spaces/viewspace.action?key=openPM2

Ich kann mir beispielsweise den praktischen Einsatz der Methode in einem Kontext, der sich noch nicht auf eine Methode kapriziert hat und wo keine allzu steile Lernkurve verkraftet werden kann, sehr wohl vorstellen und nicht zuletzt bin ich überzeugt, dass sich die derzeitig vorliegende Dokumentation sehr wohl auch als Lehrmittel für angehende Projektleiterinnen und Projektleiter eignet.

Fazit:
Ja, Open PM2 ist ein Beitrag zur Lösung!


Sämtliche Abbildungen in diesem Beitrag sind den offiziellen Publikationen der EU zu PM2 entnommen:
https://ec.europa.eu/isa2/solutions/open-pm2_en, namentlich dem PM2 User’s Guide (https://bookshop.europa.eu/en/pm-project-management-methodology-guide-pbNO0716056/) bzw dem PM2 Wiki (https://webgate.ec.europa.eu/fpfis/wikis/display/openPM2/) .

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

Digitalisierung im Projektmanagement – was Revolution, Happiness Coins und Transformation mit dem Megaprojekt Bahnhof Bern zu tun haben

Erneut vor «ausverkauftem» Hause fand am 27. Februar 2018 die Tagung «HERMES 5 angewandt: Digitalisierung im Projektmanagement» der Berner Fachhochschule BFH (E-Government-Institut) zusammen mit der APP Unternehmensberatung AG statt. Wer im Berner Rathaus dabei war, hat sicher einige «Happiness coins» mit auf den Weg genommen, hat sich gut mit einigen der über 210 anderen Teilnehmenden vernetzt und beginnt nun bestens gerüstet mit der digitalen Erneuerung des Unternehmens.

Vortrag von Dr. Bruno T. Messmer

Die digitale Revolution, vorgestellt von Dr. Bruno Messmer, verändert die Welt mehr und mehr und immer schneller. Digital wird das neue Normal. Egal, wann und wo wir was tun. Dies ist bereits heute in vielen Lebens- und Arbeitsbereichen der Fall. Wir leben, ob bewusst oder unbewusst, schon bald in einer total vernetzten, digitalen Welt. Wie das vor sich gehen kann, hat Prof. Dr. Marc K. Peter im 2. Vortrag anhand eines Saugroboters illustriert. Welcher Kunde macht sich schon Gedanken darüber, wie solch ein Saugroboter vernetzt ist und was mit den gesammelten Daten – dem Grundriss meiner eigenen Wohnung zum Beispiel – genau passiert? Im privaten Leben erwarten wir seit geraumer Zeit, dass digitale Systeme mit uns sprechen können, wir viel Wissen aus diesen Systemen übernehmen können. Die Geschwindigkeit der digitalen Entwicklung ist enorm, bereits vor mehr als 20 Jahren gewann der Schachcomputer gegen den Schachweltmeister, heute nutzt der weltbeste Go-Spieler ein Computerprogramm, um sein Spielverhalten mittels künstlicher Intelligenz weiter zu verbessern. In chinesischen TV-Shows spielen Menschen gegen Maschinen, die Menschen geraten zunehmend auf die Verliererstrasse.

Vortrag von Prof. Dr. Marc K. Peter

Spannend sind innovative Ansätze, wie man mit der Vernetzung und den Veränderungen im digitalen Umfeld umgeht: «Scrum Areas», in denen gemeinsam Probleme gelöst werden, oder auch «Transformation Journeys» anstelle eines fast schon alltäglichen Apéros, bieten Lösungen. Ähnlich die Zeichen, die man als Unternehmen seinen Mitarbeitenden geben kann, um den digitalen und dadurch auch den kulturellen Wandel zu stärken: Krawatte weg, Nicht-Erreichbarkeit nach Feierabend, Qualität und Leistung nur ohne Überstunden. Dabei gibt es natürlich auch die Kehrseite der Medaille: Menschen die mit der digitalen Transformation nicht umgehen wollen oder können. Wenn nach wenigen Wochen oder Monaten Entwicklungsarbeit Mitarbeitende entlassen werden, dann ist das eben eine dieser Kehrseiten der digitalen Welt. Sowohl angemessene Beschäftigungen für frei werdende Mitarbeitende als auch in kürzester Zeit hochqualifizierte Fachkräfte für die neuen Stellen zu finden, sind weitere grosse Herausforderungen, die auf uns zukommen. Wie flexibel sind Universitäten, Hochschulen und Ausbildungsbetriebe aber heute? Und welches Unternehmen hat sich überlegt, wie sich aufgrund der digitalen Wandlung die Wertschöpfung im Unternehmen verändern wird?

Vortrag von Andrea Vaterlaus Marty und Goran Raspor

Einen Blick in die Zukunft vermittelten schliesslich Frau Andrea Vaterlaus Marty und Herr Goran Raspor: der Bahnhof Bern in der Zukunft, den im Jahr 2030 etwa 365’000 Zugreisende, also 40% mehr als heute benützen werden. In der digitalen Welt können wir uns schon heute ein gutes Bild der Zukunft machen: Modelle und VR-Brillen helfen mit, die Kundenfreundlichkeit des Bahnhofs zu prüfen und zu verbessern, die Bewirtschaftung der Flächen zu gestalten und zu optimieren sowie schneller Mieter zu finden etc. Gerade in einem Projekt mit solch einem öffentlichen und politischen Interesse, in dem ein Kompromiss zwischen Bedürfnissen und Wünschen gefunden werden muss, hilft die Digitalisierung enorm.

Ab 2025 treffen sich diejenigen Tagungsteilnehmenden, die die digitale Revolution und Transformation überstanden haben, im Mega-Bahnhof Bern wieder, um die selbsterklärenden Wege, die Schilder und Uhren mit (Happiness-)Coins zu bewerten. Bis dahin aber gerne auch erstmal im nächsten Jahr im Frühling, wenn es wieder «HERMES 5 angewandt» heisst!

PDF erstellen

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.