Agiles Projektmanagement – eine Einführung

Teil 1:
Grundsätze und ihre Anwendung in der Praxis
Im Agilen Projektmanagement wird – im Gegensatz zum traditionellen Vorgehen – nicht der gesamte Projektablauf durchgeplant und detailliert ein Endziel festgelegt. Vielmehr wird während des Projekts Schritt für Schritt geplant, um sich so einem Ziel anzunähern, das sich immer klarer abzeichnet. Im ersten Teil dieser Artikelserie erfahren Sie, wie agile Konzepte entstanden sind und auf welchen Grundprinzipien sie basieren. Darüber hinaus zeigt Ihnen Philipp Meyerbröker praxisnah, wie Sie anhand dieser Grundprinzipien die eigenen Prozesse, Methoden und "Glaubenssätze" im Unternehmen "unter die Lupe" zu nehmen und so das Projektmanagement optimieren können.

 

Download PDFDownload PDF

Artikelserie

  1. Grundsätze und ihre Anwendung in der Praxis
  2. Empfehlungen für die Umsetzung

Agiles Projektmanagement – eine Einführung

Teil 1:
Grundsätze und ihre Anwendung in der Praxis
Im Agilen Projektmanagement wird – im Gegensatz zum traditionellen Vorgehen – nicht der gesamte Projektablauf durchgeplant und detailliert ein Endziel festgelegt. Vielmehr wird während des Projekts Schritt für Schritt geplant, um sich so einem Ziel anzunähern, das sich immer klarer abzeichnet. Im ersten Teil dieser Artikelserie erfahren Sie, wie agile Konzepte entstanden sind und auf welchen Grundprinzipien sie basieren. Darüber hinaus zeigt Ihnen Philipp Meyerbröker praxisnah, wie Sie anhand dieser Grundprinzipien die eigenen Prozesse, Methoden und "Glaubenssätze" im Unternehmen "unter die Lupe" zu nehmen und so das Projektmanagement optimieren können.

 

Wir empfehlen zum Thema Agile
3 x 4 Stunden
07.11.2024
1.295,00,-
User Story Mapping - Die Nutzer im Blick mit der Produkt-Landkarte

Stellen Sie Kundenanforderungen – ohne endlose Dokumentationen – strukturiert dar und behalten Sie mit diesem Seminar die Kontrolle über den gesamten Entwicklungsprozess. Mit vielen Praxisübungen und direkt anwendbar. Mehr Infos

Einer meiner ersten Arbeitgeber bat mich eines Tages, bei einem Projekt – die Planung und Durchführung einer mittelgroßen Veranstaltung – "reinzuschnuppern". Auf diese Weise sammelte ich meine ersten Erfahrungen mit Projektarbeit und bekam schließlich innerhalb kürzester Zeit die Verantwortung für das Projekt übertragen. Also machte ich mich an die Arbeit und versuchte, mein Bestes zu geben, um das Projekt erfolgreich umzusetzen. Dabei entwickelte sich auch mein Interesse, mehr über Projektarbeit zu erfahren. Zum einen holte ich mir Rat von erfahrenen Kollegen, zum anderen las ich diverse Bücher zum Thema "Projektmanagement".

Schnell stellte ich eine große Diskrepanz zwischen dem fest, was ich in den Büchern vorfand, und dem, was ich selbst erlebte bzw. von Kollegen erzählt bekam. Die reale Projektarbeit war geprägt von Dynamik, Herausforderungen und Erfolgen, von viel Interaktion und Kommunikation, oft auch Hektik – also von Lebendigkeit und manchmal auch etwas Chaos. Die meisten Bücher beschäftigten sich jedoch überwiegend mit Plänen, Listen, dem Berichtswesen, der Bewertung von Risiken und vielen anderen Dingen. Dies entsprach so gar nicht meinem persönlichen Eindruck von Projektarbeit.

Und so suchte ich in der Praxis oft einen Mittelweg: Ich lernte mit der Zeit, wie ich im Projektalltag die Methoden einsetzen konnte, die mir empfohlen wurden oder manchmal sogar als Standard vorgegeben waren, ohne dabei zu viel von meiner Handlungsfreiheit einzubüßen. Viel später lernte ich dann über einen Kollegen das Konzept des "Agilen Projektmanagements" kennen. Mein erster Gedanke war: "So nennt sich das also, was ich schon immer versucht habe, hinzubekommen."

Im ersten Teil dieses Beitrags erfahren Sie, aus welchen Überlegungen heraus agile Konzepte entstanden sind und auf welchen Grundprinzipien sie basieren. Diese kurze Darstellung der Prinzipien kann Ihnen auch dabei helfen, die eigenen Prozesse, Methoden und "Glaubenssätze" im Unternehmen "unter die Lupe" zu nehmen und so das Projektmanagement zu optimieren.

Warum Agiles Projektmanagement?

Projektmanagement als Arbeitstechnik entstand bereits in der Mitte des 20. Jahrhunderts und ist somit seit über 50 Jahren kontinuierlich entwickelt und verbessert worden. Davon zeugen unzählige Bücher sowie viele Methoden und Tools, die es zur erfolgreichen Umsetzung der Projektarbeit gibt.

Dabei haben die meisten "traditionellen" Ansätze – wie ich sie hier in Abgrenzung zu agilen Konzepten nennen möchte – gemein, dass sie die Projektarbeit stark strukturieren. Dies soll dazu beitragen, die größten Risiken zu minimieren, die bei den meisten Projekten schon aufgrund ihres Charakters nicht zu vermeiden sind. Denn die meist innovativen Projektaufgaben und oft komplexen Projektumfelder sorgen dafür, dass es viele Stolperfallen auf dem Weg zu den Projektzielen gibt. So wollen in Unternehmen oft nicht nur der direkte Auftraggeber, sondern auch andere Interessensgruppen, wie z.B. der Betriebsrat, das Qualitätsmanagement oder die Führungskräfte der beteiligten Mitarbeiter, in die Projektplanung mit einbezogen werden. Das macht selbst einfachere Projekte oft zu einem politischen Balanceakt.

Die Schwäche des traditionellen Projektmanagements

Die traditionellen Projektmanagement-Methoden haben einen enormen Beitrag geleistet, Projektarbeit effektiver und besser zu machen. Allerdings ließen sich bei komplexen Projekten die Probleme bislang nicht so lösen, dass es keinen Bedarf mehr an besseren Methoden gäbe.

Das hat vor allem zwei Gründe:

Zum einen hat sich neben dem "Werkzeugkasten" des Projektmanagers auch die Welt verändert. Die verbesserten Methoden und das größere Wissen rund um Projektarbeit müssen sich heute in einer deutlich komplexeren, schnelleren Arbeitswelt bewähren, in der sich die Summe der Informationen, die verarbeitet werden müssen, vervielfacht hat. Somit musste sich die Projektarbeit alleine schon verbessern, um mit dieser Entwicklung Schritt halten zu können. Agile Methoden können aus meiner Sicht ein wichtiger Beitrag sein, dieser Komplexität besser gerecht zu werden, da nach dem beweglichen Ansatz nicht alle Eventualitäten im Projekt im Vorfeld bedacht werden müssen und das Projektmanagement sich so darauf konzentrieren kann, die meist schon ausreichende Komplexität der aktuellen Situation zu bewältigen, ohne noch zu weit in die Zukunft schauen zu müssen.

Zum anderen weist das Grundverständnis dieser traditionellen Herangehensweise einen große Schwäche auf: Die meisten traditionellen PM-Methoden sollen einen Beitrag dazu leisten, dass sich der Rahmen, der zu Beginn eines Projekts mit der Planung abgesteckt wird, möglichst wenig verändert, um möglichst schnell das definierte Ziel zu erreichen. Dies hat zur Folge, dass alle Veränderungen, die stattfinden, als "Feind" des Projektmanagers angesehen werden, da sie Zusatzaufwand bedeuten.

Agiles Projektmanagement – eine Einführung


Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten

  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand und der Messung von Öffnungs- und Klickraten. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.

Fortsetzungen des Fachartikels

Teil 2:
Empfehlungen für die Umsetzung

Agile PM-Methoden sollten traditionelle ergänzen, so Philipp Meyerbröker im zweiten Teil der Artikelserie zum Agilen Projektmanagement.

Alle Kommentare (4)

Georg
Thoma

Der Artikel ist für meinen Geschmack zu akademisch und oberflächlich.

 

Peter
Wild
Dr. Dipl. Ing.

Interessante Betrachtung der agilen Methoden von einem, der offenbar sehr erfahren ist und gute Beispiele für die einzelnen Disziplinen mitbringt.

 

Christoph
Zahrnt
Dr.

Herr Meyerbröker karikiert die früheren Methoden des Projektmanagements im Softwarebereich: Alles sei starr, fest; die Kommunikation mit dem Kunden werde möglichst eingeschränkt. „Der Rahmen, der zu Beginn eines Projektes mit der Planung abgesteckt wird, [soll] möglichst wenig verändert [werden], um möglichst schnell das definierte Ziel zu erreichen.“ Veränderungen würden als „Feind“ des Projektmanagers angesehen. Ich habe schon in den 70er Jahren das Thema Änderungen in meine Vertragsmuster aufgenommen, auch das Thema Einbeziehung der künftigen Benutzer. Meyerbröker macht aus dem Grundprinzip des Agilen Manifest “Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung.“ den Grundsatz „Kommunikation mit dem Kunden ist wichtiger als die Erfüllung von Verträgen“. Auf dieser Basis verliert ein Auftragnehmer jeden Rechtsstreit mit einem Auftraggeber, der nicht bekommen hat, was er meint bestellt zu haben. Selbstverständlich gibt es überall Menschen, die sich durch Formalismus absichern wollen („Hauptsache, ich habe zu meinen gescheiterten Projekten ausreichend Berichte geschrieben und aufgezeigt, dass ich nicht an ihrem Scheitern schuld bin.“). Das kann man aber nicht den Methoden anlasten. Selbstverständlich ist auch für die bisherigen Methoden das reale Projektergebnis wichtiger als die Frage, wer die Schuld für ein mögliches Scheitern trägt. Ich würde mich als Auftragnehmer aber durch Berichte in diesem Punkt absichern wollen, abgesehen davon, dass solche Berichte sehr wohl fördern können, dass das Projekt nicht scheitert, sondern der Kunde sich bessert. Der Autor spekuliert über die Auswirkungen, wie sich Veränderungsbedarf auf Vertragswerke, Lasten- und Pflichtenhefte auswirkt. Es ist außerordentlich nützlich, bei Änderungswünschen des Kunden erst einmal zu überlegen, inwieweit diese sich bereits auf dessen Lastenheft und sodann auf das Pflichtenheft (die Spezifikation) auswirken. Selbstverständlich „bedeutet es viel Arbeit“, Fernwirkungen zu bedenken. Aber es ist sehr gut, das zu tun. Also: Weiterentwicklung der herkömmlichen Modelle dank des APM, aber bitte keine Selbstgerechtigkeit.

 

Nina
Schwanzer

Immerhin wird klar abgegrenzt, wann agile Ansätze sinnvoll sind und wann eher nicht. Am Ende kommt es genau darauf an, das realitätsnah und projektbezogen abzuwägen und dann zu entscheiden.