Um was kümmern Sie sich derzeit und was sind Ihre wichtigsten Ziele?
Ich bin Direktor des Einzelunternehmens Oraone. Ich bin Senior Consultant, Projektmanager und Trainer. Ich bin Software-Ingenieur, und das hat mir ermöglicht, all diese Berufe zu entwickeln.
Wie haben Sie die AgilePM-Methode kennengelernt? Was war Ihr ursprünglicher Bedarf?
Wie haben Sie die AgilePM-Methode kennengelernt? Was war Ihr ursprünglicher Bedarf?
Ich wollte meine Kenntnisse erweitern im Agile Bereich in Bezug auf Project Management. Ich hatte schon angefangen, Best Practice von Projektmanagement zu lernen und realisieren, vorerst mit PMP und dann mit PRINCE2, in traditioneller Form, aber ich wollte die Agile Welt kennenlernen und sehen was diese Methoden und Techniken mir geben konnten im Hinblick auf meine Projekte.
Ich habe an einem PSD-Ausbildungskurs teilgenommen, aber ich war ziemlich enttäuscht vom Projektmanagement-Aspekt, insbesondere in Bezug auf der Governance. Anschließend besuchte ich eine AgilePM-Schulung, die auf dem DSDM-Framework basiert war, und in der ich den rigorosen Aspekt der PRINCE2-Methode mit den Besonderheiten des agilen Projektmanagements verbinden konnte.
Haben Sie nach Ihrer Ausbildung die AgilePM-Methode im Projekt management benutzt?
Ja, absolut! Ich kann ein Beispiel für mein erstes Projekt mit AgilePM geben, das auch heute noch aktuell ist. Es handelte sich um ein mittelgroßes Projekt im Bereich der Luftfahrt, das sich über einen längeren Zeitraum erstreckt hat.
Das Projekt wurde mit der PRINCE2-Methode eingeführt, die sich für die Bedürfnisse und Anforderungen der damaligen Zeit besonders gut eignete. Während des gesamten Projekts stießen wir jedoch auf eine Reihe von Problemen, die sowohl die Verbindung mit der IT-Abteilung als auch Probleme mit der Leistung, der Sicherheit betrafen…. Um diese Probleme zu beheben, wurde das IT-Team meines Kunden mit Hilfe der AgilePM-Methoden zusammengestellt, die es uns ermöglichte, die Zusammenarbeit zwischen den verschiedenen Abteilungen zu verbessern und neue Rollen zu definieren, die für eine bessere Entwicklung des Projekts erforderlich waren. So wurde zum Beispiel ein Business Analyst aus der IT-Abteilung in der business unit aviation versetzt. Von diesem Moment an wurde alles einfacher, sowohl die Arbeit als auch die Zusammenarbeit und Integration zwischen der IT-Abteilung und den anderen Abteilungen.
Sobald das erste Produkt ausgeliefert war, gab es jedes Jahr Updates. Daher ist es sinnvoll, bei der Projektverfolgung auf den Agile Modus umzuschalten, da Agilität bei der Aktualisierung bestehender Produkte und Dienstleistungen nach dem Prinzip der ständigen Verbesserung äußerst praktisch ist. Aber Vorsicht: Agile bedeutet nicht, keine Kontrolle zu haben, und das ist die Stärke der AgilePM-Methode. Die Methode hat es uns – sowohl mir, einem externen Berater/externen Dienstleister als auch der IT-Abteilung und dem Geschäftsbereich – ermöglicht, eine strenge Dokumentation zu führen, einen wirksamen Überwachungsprozess einzurichten und nicht die ganze Strenge zu verlieren, die bei der ersten Version des Produkts angewandt wurde. Wir haben auch die Vorteile der regelmäßigen Besprechungen genutzt, die für die Agile Methode erforderlich sind, wodurch wir als Team besser zusammenarbeiten konnten.
Welche Einschränkungen und Herausforderungen gab es?
Einerseits bestand die Herausforderung darin, die Zusammenarbeit mit der IT-Abteilung zu verbessern, um sicherzustellen, dass Integration und Produktaktualisierungen so gut wie möglich funktionieren. Die AgilePM-Schulung des Teams ermöglichte es, eine Vision und gemeinsame Grundwerte zu schaffen, die Beziehungen zu erleichtern, eine Verbindung zwischen den verschiedenen Diensten und Geschäftsbereichen herzustellen und das Projekt zu beschleunigen und ohne Probleme ablaufen zu lassen.
Andererseits erleichterte AgilePM den Übergang zur kontinuierlichen Verbesserung, die die Arbeit an einem Rückstand möglicher Verbesserungen und dann an einer Liste von Prioritäten Anforderungen erfordert. AgilePM ist die ideale Methode dafür, da sie eine Reihe von Agile Techniken wie MoSCoW-Priorisierung und Timeboxing umfasst. Zu Beginn jeder neuen Version konnten wir anhand dieses Backlog vorhersagen, was wir bei der nächsten Steigerung tun würden.
Und schließlich ist Agilität bei unserer Arbeit an der kontinuierlichen Verbesserung fast zu einer Notwendigkeit geworden, da sie den Anforderungen perfekt entspricht. Der Scrum-Rahmen hätte für dieses Projekt funktionieren können, aber er liess nicht die von AgilePM geforderte Strenge zu. Darüber hinaus gibt es in Scrum 3 Rollen, während AgilePM ein Dutzend hat. Dadurch konnten wir auch Rollen positionieren, die außerhalb der IT-Abteilung liegen, wie z. B. Lieferanten-, Kunden- und Geschäftsrollen.
Die Deklination dieser verschiedenen Rollen ist von dem Moment an, in dem man mit der Arbeit an einem Projekt beginnt, deutlich spürbar. Wenn Sie nur Entwicklungsarbeit an bestehenden Produkten mit kleinen Product-Backlogs leisten, können Sie sehr gut mit Scrum arbeiten, aber für das Management eines komplexen Projekts ist es meiner Meinung nach besser, die Agile PM-Methode zu verwenden, die die Interaktion verschiedener Rollen ermöglicht, um zu wissen, wer was tut und um sich zu vernetzen. Nehmen wir mein eigenes Beispiel: Als Lieferant und Unterstützer im Bereich des Projektmanagements musste ich genaue SPECs für die Anforderungen haben und die Strenge im Management beibehalten.
Wie war die Umsetzung der Methode?
Die Einführung verlief recht Problemlos, da das IT-Team gebildet worden war und das Team der Geschäftseinheit bereits mit der Methode sich schon vertraut war (und ich ihnen natürlich helfen konnte). Wir waren in der Lage, von Anfang an die Rollen klar zu definieren, die Liste der Anforderungen aufzuschlüsseln, den Fortschritt in regelmäßigen Sitzungen zu verfolgen und gleichzeitig die Dokumentation aufrechtzuerhalten.
Der Business Analyst spielte eine Schlüsselrolle für den Erfolg des Projekts, da er zur Verfügung stand, um das Projekt zu unterstützen und das Verständnis zwischen allen Abteilungen (IT und Unternehmen) zu erleichtern.
Ich denke, es ist wichtig, diese Rolle zu betonen, die in Agile PM und nicht immer in anderen agilen Methoden zu finden ist. Da es anfangs einige Kommunikationsschwierigkeiten zwischen der internen IT-Abteilung und der business unit aviation gab (das Unternehmen war sehr groß, die IT-Abteilung musste mit vielen Geschäftsbereichen interagieren, nicht nur mit dem Luftverkehr), war die Wahl des Business Analysten entscheidend. Der betreffende Business Analyst verstand sehr gut die Herausforderungen der verschiedenen Interessengruppen, einschließlich der Bedürfnisse der Geschäftseinheit Avion zur Modernisierung ihrer Dokumentation (unterstützt durch die Tatsache, dass er vor Ort war) und die Bedürfnisse/Grenzen/Einschränkungen der IT-Abteilung.
Wie hat Ihnen die AgilePM-Methodik geholfen? Welches Element war für Sie am nützlichsten?
Einige Elemente der Methode haben uns geholfen: einerseits die Strenge, die AgilePM vorschreibt, um die Qualität der Dokumentation aufrechtzuerhalten, aber auch die gemeinsamen grundlegenden Werte,welche die Kommunikation und Zusammenarbeit im Team erleichtert haben. Hinzu kommt die Bedeutung von Rollen, die für die Aufteilung von Aufgaben und vor allem von Verantwortung notwendig sind. Und schließlich, und das ist meiner Meinung nach das Schlüsselelement der Methode, die Wirksamkeit der Agile Techniken „MoSCoW“ und „Time-boxing“, auf denen AgilePM basiert.
Tatsächlich basiert AgilePM auf der Kombination von MoSCoW und Time-Boxing, die auch außerhalb von AgilePM zu finden sind oder verwendet werden, aber zumindest hat diese Methode den Vorteil, dass sie diese Techniken klar als wesentlich definiert. Ohne die MoSCoW-Technik wären die Teams nicht in der Lage gewesen, rechtzeitig zum Ende der Timebox zu liefern. Diese Techniken ermöglichen es, die Dauer eines Zeitfensters festzulegen und sich zu verpflichten, die „MUSTs“ am Ende des Zeitfensters zu liefern. Dies zwingt den Kunden, seine Bedürfnisse zu strukturieren und sie in Form von Prioritäten geordneten Funktionen auszudrücken: „absolut notwendig“ (lebenswichtig), „sollten getan werden“ (wesentlich), „könnten getan werden“ (das Tüpfelchen auf dem i) und „wird jetzt nicht getan, aber vielleicht später“.
Bei AgilePM steht die Dauer fest, während bei traditionellen Methoden die Tendenz besteht, den Liefertermin zu verschieben, wenn die Zeit knapp ist. Daher liefert das Team mit AgilePM die prioritären Elemente, vielleicht etwas weniger auf einmal, aber pünktlich.
Sind Sie auf Widerstand gegen Agile Veränderungen und Umgestaltungen gestoßen?
Wir sind auf eine klassische Zurückhaltung gegenüber Agile gestoßen, d.h. der Sponsor, der eine finanzielle Rolle spielt und seine Zustimmung zum Budget gibt, hofft oft, dass alle Prioritäten ein „MUSS“ sind. Es gibt daher einen gewissen Widerstand, zu verstehen, dass er für Dinge bezahlen könnte, die geliefert werden „könnten“.
In unserem Projekt zum Beispiel, musste der Dokumentationsmanager das Projekt und das Budget zur Validierung durch die Geschäftsleitung (den Sponsor) vorschlagen. Es hat sich herausgestellt, dass es äußerst schwierig ist, ein Budget zu verstehen und zu akzeptieren, wenn man nicht zuvor einen Evangelisierungsprozess über Agilität auch in den Entscheidungsbereichen durchgeführt und erklärt hat, wie die Agile Projektmanagement Mentalität funktioniert.
Haben Sie einen Rat für Fachleute in diesem Sektor?
Sie wissen, dass ein Projekt wie dieses, das mit einer herkömmlichen Methode durchgeführt worden wäre, die 2 oder 3 Jahre gedauert hätte, am Ende nicht so effektiv gewesen wäre. Dank der Flexibilität wurde dieses Projekt über 5 Jahre schrittweise durchgeführt, wobei nach jeder Version das Feedback der Kunden berücksichtigt wurde. Dies führte zu großen strategischen Veränderungen, kontinuierlichen Verbesserungen in der Wertschöpfung und einer Lösung, die manchmal weit von den ursprünglichen Vorstellungen entfernt war, die aber letztendlich den Bedürfnissen des Kunden entspricht und diese perfekt erfüllt. Dies wäre bei einer traditionellen Arbeitsweise nicht unbedingt der Fall gewesen.
