Quick Wins im klassischen Projektmanagement mit agilen Ansätzen

Von Axel Bothur , 16.04.2019, 10:07
Projekt M

Als Projektleiter in Projekten mit klassischem Vorgehen kämpfen sie oft mit einer Reihe von Herausforderungen:

  • Nach initialer Planung verzögert sich die Genehmigung des Projekts, am Zieltermin wird aber nicht gerüttelt und ihr Plan wird herausfordernd, wenn nicht unrealistisch.
  • Sie kämpfen oft mit unklaren Anforderungen, da notwendige Grundlagen nicht dokumentiert sind und die Fachexperten für die Erarbeitung nicht ausreichend verfügbar sind.
  • Sie agieren in einer schwachen Matrix und die Mitglieder ihres Projektteams haben wenig Zeit. Insbesondere Endanwender werden dann „geschont“ und nicht ausreichend involviert.
  • Beim Test, der häufig sehr spät startet, werden sie dann von einer Welle von Fehlern überrollt. Kritische Fehler können oft nicht mehr hinreichend analysiert und gelöst werden.
  • Ihre Anwender sind frustriert, weil sie das Projektergebnis „so nicht erwartet haben und es nicht ihrem Bedarf entspricht“. Der Test führt zu weiterer Frustration: „Es geht ja gar nichts“.

 

PM1

 

Bestätigt wird dies auch vom Chaos Report der Standish Group (1): Unklare Anforderungen, fehlende Ressourcen und mangelhafte Einbindung der Anwender sind Kernprobleme in Projekten.

Ein agiles Projektvorgehen könnte viele dieser Probleme lösen, ist aber oft nicht möglich: Ihrem Unternehmen fehlt die Erfahrung oder die Bereitschaft hierfür. Auch sind agile Vorgehen nicht bei allen Projektzielen uneingeschränkt geeignet.

Unsere Erfahrungswerte haben gezeigt, dass sie dennoch Konzepte aus agilen Ansätzen gewinnbringend und als Quick Win für ihr Projekt einsetzen können, ohne komplett agil zu agieren:

  • Co-Location: Ziehen Sie ihr Projektteam räumlich zusammen. Das fördert den Austausch von Fachkollegen und Entwicklern deutlich. Gleichzeitig bekommen beide Seiten ein besseres Verständnis für die Arbeit des Anderen.
  • Mini-Wasserfälle: Schneiden Sie ihr Projekt in „Releases“, mit denen sie in Mini-Wasserfällen Funktionen schnell zum Test bereitstellen. Die Endanwender werden sehr früh eingebunden. Sie können bei Fehlentwicklungen schneller gegensteuern. Ihr Projekt wird quasi in „Sprints“ durchgeführt.
  • Kreativer Einsatz von Tools: Nutzen Sie existierende Tools kreativ, um zum Beispiel Anforderungen zu dokumentieren und Transparenz zu den Zielen zu schaffen. Oft ist es schon ein großer Mehrwert für das Team, wenn der aktuelle Projektplan oder Kernprojektziele an einem Whiteboard hängen.
  • Anforderungsanalyse in Workshops: Gehen sie weg vom üblichen Vorgehen für Fachkonzepte und erarbeiten Anforderungen in Workshops, bei denen sowohl die Fachexperten als auch die Entwickler dabei sind. Hier können Sie die zeitlich limitierte Verfügbarkeit von Fachkollegen optimal nutzen.
  • Hospitation: Lassen sie die Entwickler bei den Fachanwendern hospitieren: Was und wie arbeitet der Kollege? Entwickler verstehen dann viel besser, was für die Fachanwender von Relevanz ist.
  • Regelmäßige Feedbackschleifen: Führen sie regelmäßige Feedbackschleifen ein (z.B. Quality Gates), mit denen sie ihre Projektergebnisse immer wieder auf Richtigkeit überprüfen.
  • Testdailys: In kritischen Testphasen haben sich Testdailys bewährt. Testbeteiligte treffen sich täglich zu einem festen Zeitpunkt und Raum. Anhand eines visualisierten Testfortschritts diskutiert man, was getestet wurde, was als nächstes getestet wird und wo es Probleme gibt.
  • Bieten Sie ihrem Projektteam regelmäßige Events zum Socialising an und fördern den Teamzusammenhalt. Einfach umzusetzen ist hier eine tägliche Kaffeerunde oder ein wöchentliches Mittagessen.
  • „Lessons learned“ werden oft nur am Ende des Projekts, wenn überhaupt durchgeführt. Beginnen sie damit bereits regelmäßig während des Projekts, um früh aus positiven und negativen Aspekten zu lernen.
  • Verwenden Sie Begrifflichkeiten, mit denen die Organisation vertraut ist (z.B. Lessons Learned anstelle Retrospektive, Testjourfix anstelle Daily, Projektzyklus anstelle Sprint)

 

Dabei sollten Ihnen immer bewusst sein, dass es kein Patentrezept mit einer einfachen Lösung gibt. Sie müssen hier situativ prüfen, ob etwas funktioniert. Haben Sie dann auch den Mut, etwas über Bord zu werfen, was nicht funktioniert.

 

(1) Eine Zusammenfassung des Reports von 2014 findet sich hier: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

 

Neuen Kommentar schreiben

Ich habe die Datenschutzhinweise zur Kenntnis genommen. Ich stimme zu, dass meine Angaben und Daten zur Beantwortung meiner Anfrage elektronisch erhoben und gespeichert werden.