Projektprozesse und Vorgehensmodelle

Share on Facebook0Share on Google+67Tweet about this on TwitterShare on LinkedIn0

„Ein Vorgehensmodell organisiert einen Prozess der gestaltenden Produktion in verschiedene, strukturierte Phasen, denen wiederum entsprechende Methoden und Techniken der Organisation zugeordnet sind. Aufgabe eines Vorgehensmodells ist es, die allgemein in einem Gestaltungsprozess auftretenden Aufgabenstellungen und Aktivit√§ten in einer sinnf√§lligen logischen Ordnung darzustellen.“ (Quelle: Wikipedia)

Vorgehensmodelle sind insbesondere im IT-Projektmanagement und der Softwareentwicklung weit verbreitet (√úberblick: Download). Aber auch in anderen Bereichen des Projektmanagements machen strukturierte Vorgehensmodelle (=¬†Projektprozesse) Sinn. In der Produktentwicklung sind es die Stage-Gate- bzw. Innovationsprozesse, im Bauprojektmanagement sind es die verschiedenen Projektabwicklungsmodelle, sogar in Organisationsentwicklungs- und Ver√§nderungsprojekten werden systematische Prozesse vorgeschlagen (wo ich es pers√∂nlich nicht f√ľr sehr sinnvoll erachte).

K√ľrzlich habe ich zu diesem Thema eine Blitzumfrage durchgef√ľhrt. An dieser Stelle ein herzliches Dankesch√∂n an alle, die an der Umfrage bereits teilgenommen haben. Es zeigt sich nach 57 R√ľckmeldungen folgendes Bild (siehe oben):

  • 44% der Befragten verwenden teilweise einheitliche Projektprozesse / Vorgehensmodelle
  • 40% der Befragten verwenden keine Projektprozesse / Vorgehensmodelle, w√ľrden die Anwendung aber f√ľr sinnvoll erachten
  • 12% der Befragten beurteilen das prozessorientierte PM f√ľr gut integriert
  • lediglich 4% wenden keine Prozessmodelle

Meines Erachtens ist es von entscheidender Bedeutung, in der Anwendung von Vorgehensmodellen / Projektprozessen sehr differenziert vorzugehen. Denn gerade bei sehr komplexen, neuartigen und dynamischen Projekten ist es wenig sinnvoll, nach einem verhältnismäßig starren Prozess vorzugehen. In solchen Anwendungsfällen eignen sich iterative und agile Vorgehensmodelle, die im Kern nur aus einigen sinnvollen Prinzipien und Grundregeln bestehen.

Sehr strukturierte Modelle machen dort Sinn, wo Projektaufgaben schon einen starken Routinecharakter haben. Dies ist beispielsweise h√§ufig bei „Kundenprojekten“ der Fall. Aber auch hier gilt: Je neuartiger und komplexer ein Projekt ist, umso besser sollte gepr√ľft werden, ob das jeweilige Vorgehensmodell anwendbar ist.

FAZIT: Vorgehensmodelle k√∂nnen im Einzelfall sehr viel Sinn machen, da sie das gemeinsame Verst√§ndnis f√ľr ein systematisches und strukturiertes Vorgehen in Projekten f√∂rdern. Gleichzeitig k√∂nnen Vorgehensmodelle aber auch sehr negative Auswirkungen haben, wenn sie starr und b√ľrokratisch angewendet werden – insbesondere bei neuartigen, komplexen und dynamischen Projekten.

Weiterf√ľhrende Artikel:

2 Gedanken zu „Projektprozesse und Vorgehensmodelle

  1. Thomas

    Mehr als Kommentar auf das von Dir verlinkte Video √ľber Scrum im Schnelldurchlauf aber auch mit Bezug zu Deinem Blog-Beitrag.

    In meinem Umfeld haben sich die stage-gate Modelle durchgesetzt. Diese Vorgehensweise halte ich bei gro√üen Entwicklungsvorhaben (bspw. ein neues Auto) auch f√ľr sinnvoll, da man damit sehr gut die vielen Entwickler synchronisieren kann.

    Jetzt der Bezug zum Scrum Video. Wenn ich andere Rollennamen verwende, dann komme ich schnell zu einer Vorgehensweise, die ich aus meinem Umfeld kenne.

    Ein Requirements-Engineer (Product Owner) definiert die in Form eines Lastenheftes (Product Backlog). In Abstimmung mit einem Lieferanten wird festgelegt, welche Funktionen zu welchen Release (Sprint) implementiert werden (Sprint Backlog). Der Lieferant entwickelt dann sein Produkt (bei mir ist das gerade ein Steuerger√§t f√ľr ein Auto) und liefert es ab. Das Daily-Scrum machen wir dabei eher nicht. Statt dessen gibt es regelm√§√üige Kommunikationsrunden in gr√∂√üeren Abst√§nden. Unser Scrum Master ist ein Projekt Qualit√§ts-Manager. Er sorgt daf√ľr, dass Prozesse eingehalten werden und Rahmendbedingungen f√ľr die Prozesseinhaltung vorhanden sind. Das Product Review hei√üt bei uns „testing“ und findet f√ľr das einzele Produkt (Steuerger√§t) aber auch f√ľr alle Produkte (Steuerger√§teverbund) statt.

    Unsere Frequenz ist hingegen viel langsamer. Wir arbeiten mit nur 4 Releases im Jahr und sind somit weit von den 2 Wochen-Sprints entfernt.

    Ansonsten halte ich f√ľr mich fest, dass Scrum ein release-orientiertes Arbeiten darstellt, dass schon heute gut √ľber stage-gate Modelle abgebildet werden kann.

    Antworten
  2. Michael

    Diese Auswertung w√ľrde ich mir zu gerne mal gekreuzt nach L√§ndern (bes. D und √Ė) ansehen… ūüôā

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.