Blogger- und Projekt-Kollege Marcus Raitner hat diese Woche in seinem Artikel „Wider den Heilsversprechen im Projektmanagement“ eine Lanze für die situationsangepasste Verwendung von Standards und Methoden gebrochen. Dem stimme ich zu. Der sklavische Einsatz EINER Methode kann sogar schädlich sein. Das ist mir in den letzten Tagen in einem Projekt wieder sehr deutlich vor Augen geführt worden. Einige der Meilensteine und Abhängigkeiten sind durch äußere Rahmenbedingungen unverrückbar vorgegeben. Es liegt daher nahe eine klassische Grobplanung des Projektes durchzuführen. Eine vollständige Durchplanung der Arbeitspakete ist derzeit noch nicht möglich, weil die Erhebung der Anforderungen von einigen Entscheidungen im Laufe des Projektes abhängen wird. Insofern ist es eine kluge Entscheidung statt einen fiktiven Detailplan zu erstellen einige Arbeitspakete als agile Teilprojekte aufzufassen. Die Zieldefinition eines großen Arbeitspaketes liefert den ersten Input für das agil arbeitende Teilprojekt. Die nebenstehende Grafik veranschaulicht die Situation unter Verwendung einiger Begrifflichkeiten aus Scrum. Ist das Gesamtprojekt jetzt agil oder klassisch? Ich denke die Frage alleine zeigt schon auf wie unsinnig eine »entweder-oder« Diskussion sein kann.
Hallo Herr Ksoll, Danke für Ihren ausführlichen Kommentar und den Link zur Präsentation. Bitte entschuldigen Sie meine späte Antwort, ich war erst jetzt dazu gekommen, die Folien durchzusehen. Ich stimme Ihnen zu. Ich wollte mit meinem Beitrag genau das ausdrücken, dass es keine allein glücklich machende Methode gibt und je nach Situation Kombinationen zum Einsatz kommen können, viele Grüße Eberhard Huber
Es gibt auch klassische PM-Methoden, die Arbeitspakete nicht vollständig am Projektanfang durch planen. Bei PRINCE2 zum Beispiel werden APs Phase für Phase geplant (wenn man weiss, dass man in die nächste Phase überhaupt noch will :-).
In der Softwareentwicklung kann man auf der Arbeitsebene in der Softwareentwicklung of Scrum oder was anders Agiles einsetzen. Portfolien oder Programme (und selbst ganze Projekte) sind alleine in Scrum schwierig. Formal müsste dann alles der Product Owner alleine managen und der Teammanager soll kein Scrummaster sein. Man kommt da also auch nicht um das taylorn herum und muss immer anpassen an konkrete Situationen.
Aber es gibt auch schon erste Standardansätze, die z.B. PRINCE2 und Agile zusammenbringen 😉
Ich habe dazu einen Vortrag gehalten, wo ich auch nicht abstrakt blieb („geht standardmäßig Methode X oder Y?“ sondern habe Ausprägungen in unterschiedlichen Umgebungen gezeugt (Bergbau und Softwareentwciklung im Immobilenmanagement. Ich persönlich würde ungern ein 70-jähriges Projekt mit tausenden von Stakeholdern nur mit einem kleinen Team managen, dass in einem Raum sitzt, weil ich Scrum als Standard habe 🙂
Die Folien zum Vortrag sind auf Slideshare:
http://de.slideshare.net/WolfgangKsoll/bpug-2013sepvortragksoll8