Inside out: Was bringt DIN 69901-2:2009-01 Projektmanagement – Projektmanagementsysteme – Teil 2: Prozesse, Prozessmodell

Standardisierung (Icon)Nach der Diskussion des 1. Normblattes Grundlagen in der Inside out-Artikelseite, widmet sich dieses Posting dem neuen Prozessmodell. Mit 55 Seiten ist das Prozessmodell als detailliertes Rahmenwerk für die Implementation einer konkreten PM-Methodik beschrieben. Es stellt den wesentlichen Fortschritt der neuen DIN 69901 dar, ein kurzes Posting kann dem nicht gerecht werden. Wohl möchte ich Ihnen aber einen kurzen Überblick über interessantesten Punkte und einen kurzen Blick auf DIN 69901-2 vs. PMBOK® Guide anbieten. Hier ein Überblick über die Prozesse:

Prozessmatrix

Multiprojektmanagement
Noch vor den Prozessen widmet sich DIN 69901-2 dem Thema Multiprojektmanagement. Der Fortschritt gegenüber der alten Norm ist, dass nun Multiprojektmanagement als Oberbegriff für Programm- und Portfoliomanagement definiert ist, vorher der Inhalt unklar. Die Definition weist Multiprojektmanagement als organisatorischen und prozessualen Rahmen für das Management mehrerer einzelner Projekte aus. Leider verpasst die DIN aber die Chance, die Begriffe Programm- und Portfoliomanagement zu definieren.

Phasenmodell
So gelungen das Prozessmodell als erster Wurf auch ist, so schwierig macht sich die DIN 69901-2 das Leben mit dem Begriff Projektmanagementphasen:

Phasenmodell

Grundsätzlich werden die PM-Phasen von den Projektphasen und dem Produktlebenszyklus getrennt. Allerdings suggeriert sowohl das obige Diagramm, als auch der Einsatz von Quality Gates mit zugehörigem Freigabeprozess am Ende jeder PM-Phase eine zeitliche Zergliederung. Lt. Normblatt sollen die PM-Phasen allerdings inhaltlich gliedern. Aus meiner Sicht hat sich die DIN 69901-2 hier einen inhärenten Widerspruch geleistet, der noch viele Probleme bereiten wird.

Das Mapping der PM-Phasen der DIN 69901-2 auf den aktuellen PMBOK® Guide sieht nach Analyse auf Prozess- und Prozessschrittebene wie folgt aus:

DIN 69901-2 PMBOK® Guide
Initialisierung Initiating
Planning
Definition Initiating
Planning
Executing
Planung Planning
Execution
Monitoring & Controlling
Steuerung Execution
keine Entsprechung Monitoring & Controlling
Abschluss Closing
Monitoring & Controlling

Bei den Wissensgebieten des PMBOK® Guide und den Prozess-Untergruppen (vgl. linke Spalte der Prozessmatrix) gibt es eine 1:1-Übereinstimmung. Ich bin gespannt wie die Situation aufgelöst wird, wenn die international PM-Norm ISO 21500 erscheint.

Projektmanagementphasen und Prozesse
Die einzelnen PM-Phasen werden in der neuen DIN anschaulich mit logischen Ablaufdiagrammen dargestellt:

Prozessgruppe

Alle Prozesse werden tabellarisch definiert mit

  • Vorgänger(prozessen),
  • Nachfolger(prozessen),
  • Ziel,
  • Prozessbeschreibung,
  • Inputs,
  • PM-Methoden und
  • Outputs.

Die Norm definiert in diesem Zusammenhang einen Mindeststandard für Prozesse, d.h. Prozesse, die in jedem PM-System umgesetzt werden müssen. Dies finde ich einen wesentlichen Schritt, in anderen Normen und Standards wird dies häufig nicht berücksichtigt.

Interessante Prozesse
Eigentlich würde ich die einzelnen Prozesse gerne besprechen, allerdings ist dies eher Inhalt eines Buches denn eines Blogs. Also hier nur einige kurze Kommentare zu ausgewählten Prozessen:

  • I.5.1 Zuständigkeit klären
    Das Ziel des Prozesses ist, zu klären, wer die Verantwortung für die ersten Schritte im Projekt trägt und wie wird das Projekt organisiert wird. Dies stellt in der Praxis häufig ein Problem in Trägerorganisationen dar. Deshalb finde ich die Definition eines eigenen Prozesse auf der einen Seite gut, auf der anderen Seite handelt es sich lediglich um einen kleinen Schritt, der bei neutraler Betrachung nicht in einem eigenen Prozess abgebildet werden sollte. PRINCE2 scheint hier in der neuen Version einen mutigen Schritt nach vorne gehen zu wollen, und den Überfluss an Prozessen vieler Normen massiv zu reduzieren.

  • D.3.2 Projektmarketing definieren
    Den Begriff des Projektmarketings finde ich sehr gut gewählt, meist spricht man von der Information von Stakeholdern und übersieht dabei das Ziel, diese zu Unterstützern des Projektes zu machen.

  • D.6.1 Erfolgskriterien definieren
    Auch hier wieder ein Prozess, der eigentlich in einem Planungsprozess aufgehen sollte.

  • D.8.3 Machbarkeit bewerten
    Machbarkeitsstudien sind häufig eigene Projekte oder führen zu weiteren Vorprojekten. Deshalb ist hier die Wahl gut getroffen und ein eigener Prozess definiert worden.

  • D.11.1 Ziele definieren
    D.11.2 Projektinhalte abgrenzen

    Hier tritt ein kleines Manko der Definition eines Mindeststandards an Prozessen hervor. Die beiden Prozesse sollten eigentlich in einem Prozess zusammengeführt werden, allerdings wäre es verwirrend, wenn nur ein Teil eines Prozesses verpflichtend wäre.

  • S.1.1 Vorgänge anstoßen
    S.5.1 Kick-off durchführen
    A.3.1 Projektabschlussbericht erstellen
    A.3.2 Projektdokumentation archivieren
    A.5.1 Abschlussbesprechung durchführen
    A.5.2 Leistungen würdigen
    A.5.3 Projektorganisation auflösen

    Hier noch einige Beispiele für Prozesse, die Teil anderer Prozesse sein sollten.

  • S.10.2 Nachforderungen steuern
    Im Gegensatz dazu ist Claim Management heute so wichtig geworden, dass ein eigener Prozess wichtig ist.

Die Inhalte der einzelnen Prozesse bieten keine Überraschungen und sind solide definiert. Wenn man nun wieder auf den PMBOK® Guide blickt, „fehlen“ in der DIN folgende Prozesse:

  • 8.2 Perform Quality Assurance
  • 9.4 Manage Project Team
  • 12.3 Request Seller Responses
  • 12.4 Select Sellers

Hinweis: In diesem Fall habe ich noch die 3rd Edition gewählt, da die Analyse aus dem Januar letzten Jahres stammt.
Wo man die Grenze bei einer PM-Norm zieht, darf unterschiedlich sein. Insofern ist es kein Verlust, dass die obigen Prozesse nicht Teil von DIN 69901-2 sind.

Fazit
Für einen ersten Wurf ist das Prozessmodell sehr gut. Nachteilig wirkt sich der inhärente Widerspruch zwischen logischer und zeitlicher Zergliederung bei den Projektmanagementphasen aus. Viele Prozesse könnten zusammengefasst werden, da sie einfache Aktivitäten meiner Meinung nach auf ein zu hohes Niveau heben. Derzeit sehe ich es als Überkompensation von häufigen Schwächen in Projekten.

Wer ist nun der „Kunde“ dieses Prozessmodells? Trägerorganisationen mit einer PM-Methodik auf Basis von PRINCE2 oder des PMBOK® Guide sind bereits versorgt und würden sich lediglich Widersprüche einhandeln. Somit bleiben eigentlich die Organisationen, die entweder das Kompetenzmodell der GPM/IPMA einsetzen (dort fehlt ein Prozessmodell) oder Organisationen, die unabhängig von Berufsverbänden eine PM-Methodik einführen oder weiterentwickeln wollen.

Dieses Posting könnte als sehr kritischer Blick auf die DIN 69901-2 betrachtet werden. Da ich hier aber keinen Hurra-Journalismus wie in den diverse Zeitschriften des PMI veranstalte, sind die Schmerzpunkte der neuen Norm klar benannt. Im Kontext der 55 Seiten Normblatt für die DIN 69901-2 bleibt festzuhalten, dass gute Arbeit geleistet wurde, die Norm Einsatzreife hat und ihr Geld wert ist.

Und hier nochmal der Copyright-Hinweis: Der Beuth-Verlag hat mir dankenswerterweise die notwendigen Rechte für die Veröffentlichung der Diagramme und Tabellen zur Verfügung gestellt. Die Creative Commons-Lizenz des Blogs gilt nicht für die DIN-Materialien.

Eine Antwort zu Inside out: Was bringt DIN 69901-2:2009-01 Projektmanagement – Projektmanagementsysteme – Teil 2: Prozesse, Prozessmodell

  1. […] DIN 69901-2:2009-01: Teil 2 – Prozessmodell […]

%d Bloggern gefällt das: