Projektprozesse und Vorgehensmodelle

Share on Facebook0Share on Google+0Tweet 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

Schreibe einen Kommentar

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