Projektmanagementmethoden unter der Lupe
Klassisch, hybrid, integriert, agil – bei der Wahl der richtigen Projektmanagementmethode für ein geplantes Vorhaben kann man schon mal ins Grübeln kommen. Was machen wir? Sind wir schon gut genug, um uns für Methode xyz zu entscheiden? Und warum finden alle Scrum gut?
Doch so wenig „one size fits all“ für Socken gilt, so wenig ist das Überstülpen einer Standardprojektmanagementmethode ein Allheilmittel für Projekterfolg. Brauchen wir Struktur? Wenn ja, wie viel? Und wann haben wir uns schon überplant? Oder mal umgekehrt betrachtet: wie viele Freiheiten gestehen die von „außen“ uns zu, bei denen wir uns von uns vorgeschriebenen Strukturen zum Wohle des Projekterfolgs loslösen können, um die nötige Flexibilität zu haben, das Projekt sicher in den Hafen zu fahren?
Bevor wir uns nun mit der Auswahl der richtigen Methode beschäftigen, sollen nachfolgend einmal kurz die gängigen Projektmanagementmethoden angerissen werden:
Da gibt es zum einen das klassische Projektmanagementvorgehen: „Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation“ – beispielhaft kann man hier die Entwicklung neuartiger Produkte, Umstellung der Produktion auf neue Technologie oder Reorganisation benennen. Klassisch benutzt man hierfür althergebracht ein Standardmodell, das sich etwa mit Initiierung, Planung, Durchführung, Überwachung und Kontrolle und Projektabschluss in eben diese Phasen unterteilt und einer mehr oder weniger klaren Struktur unterliegt … und am Ende steht ein Ergebnis da (z.B. ein Produkt). Doch wollen wir genau das? Denn während wir uns genau diese Struktur aufbauen und noch mit dem Einbetten der Inhalte in ebendieselbe beschäftigt sind, schauen wir auf einmal hoch und stellen fest, dass unser Wettbewerber uns überholt hat und alles schon da steht, womit wir uns ja gerade in neuem Glanz hervortun wollten. Quasi das alte Hase- und Igelspiel.
Ok, denken wir uns, da geht doch noch was anderes. Wir wollen näher an den Kunden ran, damit er am Ende des Tages auch bei uns kauft, und raus geht und jedem erzählt, wie toll es ist, bei uns zu kaufen. Lassen wir ihn doch mal mitreden und intensivieren bereits an dieser Stelle unsere Kundenbeziehungen, damit wir so durch gekonnte Einbindung in die Produktentwicklung das Kundeninteresse hochhalten. Da kommt uns Scrum doch gerade recht. Wir entwickeln Increments, zeigen sie dem Kunden und der Kunde teilt uns quasi noch im unfertigen Produkt seine Meinung und seine Gedanken und Veränderungswünsche mit. Im Umkehrschluss bedeutet dies, dass Scrum vor allem als Ansatz bei sich häufig ändernden Anforderungen an ein Projekt, bei kurzen Planungshorizonten und einem hohen Forschungsanteil punkten kann. Das Vorgehen verläuft hier iterativ-inkrementell, die Prozesse wiederholen sich und die Teilnehmenden arbeiten kontinuierlich an einer Verbesserung und Fortentwicklung. Klingt nach hohem Anteil an Eigenverantwortung? Ist es auch. Kritiker behaupten ja, dass man am Anfang eines Scrum-Projektes oft noch gar nicht weiß, wie das Produkt am Ende aussieht. Oder dass doch was anderes dabei herauskommt als das, was man sich eingangs ausgemalt hatte.
Jetzt ist es an der Zeit, nochmal in das Unternehmen und dessen Projektlandschaft reinzuschauen – da gibt es auf der einen Seite die Scrum Teams, die flexibel, schnell und anpassungsfähig sind. Auf der anderen Seite sind da die Stakeholder, die Gremien und die starren Entscheidungsprozesse, die man besser nach Wasserfall bedienen würde. Oder? Oder nicht? Bringen wir an dieser Stelle mal SAFe ins Spiel – das Scaled Agile Framework. Dieses schreibt sich nun auf die Fahne, die Vorteile des einen mit denen des anderen zu verknüpfen und dabei sogar den Kunden in den Mittelpunkt zu stellen. Sozusagen kundenzentrisch. Doch was kann dieses SAFe? Man kann sagen, dass die Vorteile von Scrum mit SAFe auf komplexere Strukturen skaliert werden, während gleichzeitig zentralisierte Entscheidungsprozesse beibehalten werden. Konkret heißt dies, dass auf der Teamebene SAFe über die gleichen Rollen wie Scrum verfügt. Auf der Programmebene kommen die Stakeholder, Systemarchitekten und Release Train Engineers hinzu. Epic Owners und Enterprise Architekten sind Rollen der Portfolioebene, während weitere Rollen auf der Lösungsebene dezentralisiert Verantwortlichkeiten übernehmen.
Kommen wir nun zu der Frage zurück, die wir beantworten wollen. Wer soll für welches Projekt welchen Ansatz benutzen?
Für die Anwendung des SAFe Frameworks sprechen Faktoren wie das agile Arbeiten und die Realisierung in einer großen Organisation. Die Skalierung der Agilität kann in komplexen Strukturen mehr umsetzen als Scrum allein – wobei sie andererseits auch eine Gefahr für die Grundprinzipien der Agilität darstellt.
Bei der Auswahl der Methodik sind neben Time-To-Market aber auch der Kontext und die Ziele des Unternehmens, die Klarheit des Projektauftrags, seinem Inhalt und der Planbarkeit, dem Mindset der beteiligten Personen, sowie die interne Struktur und die Anforderungen der Stakeholder in Betracht zu ziehen. Gerade in Zeiten der Digitalisierung ist die Wahl des „richtigen“ Projektmanagementansatzes eine wichtige Frage. Immer kürzere Produktentwicklungs- und -lebenszyklen, Ziele, die aufgrund der steigenden Komplexität nicht mehr exakt planbar sind, eine neue Teamkultur sind nur einige Herausforderungen für Projektverantwortliche, die die Wahl der „richtigen“ Projektmanagementmethode ins Zentrum des Interesses rückt.
Sie wissen noch nicht, wie Sie bei Ihrem nächsten Projekt ansetzen sollen und Ihnen fehlt noch Klarheit?
Gerne helfen wir Ihnen in einem persönlichen Gespräch bei der Auswahl der richtigen Methode anhand unserer internen Matrix. Kontaktieren Sie uns für ein persönliches Gespräch mit unseren Experten.
Wir freuen uns über die Kontaktaufnahme unter kontakt@constructive.de, Jens Voh unter 0175 43 41 42 5 oder Armin Herbers unter 0175 29 79 23 2.