Skip to content

Projektmanagement – Methoden & Modelle

Christian Brunner edited this page Oct 1, 2024 · 13 revisions

Während der Planung und Konzeption von Projekten zahlt es sich aus, sich frühzeitig über die Abläufe und das Projektmanagement zu machen, Rollen zu definieren und diese innerhalb des Projektteams zu verteilen. Modelle dafür gibt es zahlreiche. Welche Methode für welches Vorhaben geeignet ist, hängt in der Regel von der Natur des Projekts und verschiedenen Faktoren ab. Zum Beispiel:

  • Strategische Zielausrichtung und Unternehmenswerte
  • Stakeholder-Anforderungen
  • Projektrisiken
  • Projektgröße
  • Ressourcen(verfügbarkeit)
  • Projektkomplexität
  • Zeitrahmen
  • Individuelle Bedürfnisse/Präferenzen der Projektleitung

Was für ein Projekt funktioniert kann für ein anderes völlig ungeeignet sein. Diese individuellen Unterschiede erfordern maßgeschneiderte Ansätze im Projektmanagement. Eine Einheitslösung ist kaum in der Lage den spezifischen Anforderungen und Herausforderungen jedes Projekts gerecht zu werden.

Wasserfallmethode (Waterfall model)

Ursprünglich für die Bau- und Produktionsindustrie entwickelt (um 1970 von Winston W. Royce beschrieben), handelt es sich bei der Wasserfallmethode um das wohl traditionellste Modell in der Softwareentwicklung. Es ist ein lineares, nicht iteratives Projektmanagement-Modell, bei dem die Phasen eines Projekts nacheinander durchlaufen werden. Jede Phase muss abgeschlossen sein, bevor die nächste beginnt. Typischerweise umfasst es 5 Phasen:

  • Requirements: Anforderungsanalyse und -spezifikation resultiert im Lastenheft
  • Design: Systemdesign und -spezifikation resultiert in der Softwarearchitektur
  • Implementation: Programmierung und Modultests resultiert in der eigentlichen Software
  • Verification: Integrations- und Systemtest
  • Maintenance: Auslieferung, Einsatz und Softwarewartung

Das Modell eignet sich besonders für Projekte mit klaren Anforderungen, da es wenig Spielraum für Änderungen bietet. Ein Rücksprung in vorherige Phasen ist schwierig und kostspielig, daher liegt der Fokus auf gründlicher Planung und Dokumentation.

Agile

Der agile Softwareentwicklungsprozess ist eine flexible und iterative Vorgehensweise zur Softwareentwicklung. Er konzentriert sich auf die kontinuierliche Zusammenarbeit zwischen Entwicklern und Kunden sowie auf die schnelle Bereitstellung funktionierender Software. Der Prozess ist in kurze Entwicklungszyklen, sogenannte Sprints (meist 1-4 Wochen), unterteilt. Am Ende jedes Sprints wird ein lauffähiges Software-Produktinkrement geliefert, das Feedback vom Kunden erhält. Dieses Feedback wird in den nächsten Sprint integriert, um das Produkt schrittweise zu verbessern.

Die Prinzipien des agilen Prozesses umfassen:

  • Individuen und Interaktionen vor Prozessen und Werkzeugen
  • Funktionierende Software vor umfassender Dokumentation
  • Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen
  • Reagieren auf Veränderungen vor dem starren Befolgen eines Plans

Diese Leitsätze wurden im Februar 2001 zusammen mit 12 agilen Prinzipien in Form des «agilen Manifestos» Manifesto for Agile Software Development formuliert und von diversen namhaften Vertretern der Branche unterzeichnet.

Zu den bekanntesten agilen Frameworks zählen:

Gemäss dem 17th State of Agile Report ist Scrum das populärste Modell unter Teams mit agilem Workflow (63%). Ebenfalls oft verwendet wird Kanban oder eine Mischung aus beiden (Scrumban).

Scrum

Scrum Diagram

Scrum beruht auf der Auffassung, dass umfangreiche Projekte zu komplex sind, um Sie im Voraus präzise planen zu können. Der Großteil der möglichen Risiken und Anforderungen ist also zu Beginn des Projekts noch unklar. Dieser Tatsache soll das Aufstellen und Besprechen von Zwischenergebnissen entgegenwirken.

Zu Beginn des Projekts legt Scrum einen langfristigen Plan (Product Backlog) fest. Anders als bei klassischen Wasserfall-Methoden, wird dieser Plan während der Durchführung des Projekts regelmäßig angepasst und optimiert. Dem Projekt zugehörige Aufgaben und Handlungen werden in sich wiederholenden Abläufen (Sprints) umgesetzt. Jeder Sprint hat das Ziel, ein funktionierendes Zwischenprodukt präsentieren zu können.

Damit Scrum-Teams dies umsetzen können, finden sich alle Projektbeteiligten zu Beginn des Tages in Daily Scrums zusammen, um Aufgaben, Probleme und Fortschritte zu besprechen. Die Scrum Projektmanagement-Methode legt die folgenden Rollen innerhalb eines Teams fest:

  • Product Owner: Produktexperte, der die Stakeholder des Projekts repräsentiert und die Meinung und Wünsche des Kunden vertritt
  • Entwickler-Team: Projektteam (bspw. Entwickler und Designer), das an der Durchführung des Projekts beteiligt ist und Aufgaben übernimmt
  • Scrum Master: Vermittelt und unterstützt das Entwickler-Team und trägt die Verantwortung dafür, dass die Scrum-Methode korrekt umgesetzt wird. Zudem vermittelt er zwischen Entwickler-Team und Product Owner. Aber Achtung: Der Scrum-Master nimmt keine klassische Chef-Rolle ein. Er bestimmt also nicht, wer welche Aufgabe zu erledigen hat.

Kanban

Kanban oder auch kamban kommt aus dem Japanischen und bedeutet Anschlagtafel. Es entstand aus dem Produktionssystem des Autoherstellers Toyota, welches besonders kundenorientiert arbeitete und damit den Vorläufer des modernen Kanban-Systems schuf. Das Ziel von Toyotas Planungssystem war es, für ihre Kunden einen Mehrwert zu schaffen, ohne dabei größere Kosten zu verursachen. Sie strebten damit auch die Minimierung von Verschwendung an, ohne jedoch die Produktivität zu verringern.

Simple Kanban Board

Kanban soll dabei helfen, die Zusammenarbeit von Teams zu verbessern, indem Arbeitsprozesse visualisiert werden. Dadurch lassen diese sich verwalten und deren Effizienz und Qualität können gesteigert werden.

Zusammengefasst stützt sich Kanban auf sechs Säulen:

  • Beim Kanban-Verfahren steht die Visualisierung von Arbeitsprozessen im Vordergrund, wobei selbst kleinste Arbeitsschritte und deren Fortschritt im Prozess visuell dargestellt werden können.
  • Begrenzung trifft hier insbesondere auf die maximale Anzahl an Aufträgen pro Spalte zu, um das Board nicht zu überladen. Um den Arbeitsablauf zudem so effizient wie nur möglich zu gestalten, darf erst dann eine neue Aufgabe von links nehmen, wenn zuvor eine andere Aufgabe erledigt wurde.
  • Während des Prozesses ist es notwendig, das Kanban-Board zu beobachten und zu verwalten. In kritischen Situationen muss die Lösung von Konflikten priorisiert werden.
  • Durch festgelegte Regelungen werden Arbeitsabläufe klarer und transparenter für das Team. Dazu gehören etwa Deadlines und Zuständigkeiten von Aufgaben. Diese Regulierungen müssen für alle Beteiligten sichtbar und nachvollziehbar sein, um sie optimal umsetzen zu können.
  • Feedback ist ein notwendiger Bestandteil von Arbeitsabläufen und eine Voraussetzung für deren Verbesserung, weshalb regelmäßige Besprechungen des Kanban-Boards notwendig sind.
  • Im Rahmen der Kanban-Methode sollte eine kontinuierliche Verbesserung (genannt Kaizen, aus dem Japanischen für «Gute Verbesserung») anzustreben.

PRINCE2

PRINCE2 steht für PRojects IN Controlled Environments (Projekte in kontrollierten Umgebungen). In der PRINCE2-Projektmanagementmethode werden Projekte in sieben Prozesse aufgeteilt: Lenken eines Projekts, Starten eines Projekts, Initiieren eines Projekts, Managen des Phasenübergangs, Steuern einer Phase, Managen der Produktlieferung sowie das Abschließen eines Projekts.

CPM / PERT

Die Methode des kritischen Pfades (Engl. critical path method, CPM) und die Program Evaluation and Review Technique (PERT) wurden in den 1950er Jahren als erste Projektmanagement Methoden entwickelt. CPM bietet einen Algorithmus, um den kritischen Pfad, also die wichtigsten Vorgänge, zwischen komplexen, verknüpften Aufgaben mit definierten Zeitrahmen abzubilden. Mit CPM können Teams den längsten Abschnitt voneinander abhängiger Vorgänge und damit die Mindestdauer des Projektes bestimmen. PERT hilft Teams, den kritischen Pfad zu bestimmen, wenn Zeitplan und Zeitrahmen unbekannt sind. In PERT identifizieren Projektmanager alle Aufgaben, die erledigt werden müssen (nicht nur den kritischen Pfad), um die Mindestdauer bis zum Abschluss des Projekts zu bestimmen.

Quellen

Clone this wiki locally