Der Begriff Projektmanagement bezeichnet das Initiieren, Planen, Steuern, Kontrollieren und Evaluieren von Projekten. Ziel eines professionellen Projektmanagements ist es, Projekte so zu planen und zu steuern, dass dessen Risiken begrenzt, die Chancen genutzt und die Projektziele in der angestrebten Qualität, termingerecht und im definierten Kostenrahmen erreicht werden.
Die DIN 69901 definiert Projektmanagement als Gesamtheit der (Führungs-)Aufgaben, -organisation, -techniken und -mittel für das Abwickeln eines Projekts. Das Project Management Institute (PMI) definiert im PMBOK das Projektmanagement allgemeiner als die Anwendung von Wissen, Fähigkeiten, Methoden und Techniken auf die Vorgänge innerhalb eines Projekts.
Vor der Herausforderung Projekte bzw. Vorhaben zu managen, um ihre Ziele zu erreichen, stehen (nicht nur) Unternehmen seit sie bestehen. Deshalb haben sich im Bereich Projektmanagement im Laufe der Jahrzehnte bzw. Jahrhunderte viele Begriffe und Verfahrensweisen etabliert. Dabei gilt es jedoch zu beachten, dass Projekte stets in einem Umfeld stattfinden. Deshalb werden zum Teil auch bewährte Verfahren, wenn sich die Rahmenbedingungen, ändern, obsolet. Deshalb stellen seit einigen Jahren in der von der rascher Veränderung und sinkender Planbarkeit geprägten VUKA-Welt, in der auch die Komplexität der Projekte steigt, das klassische Projektmanagement in Frage und sind auf der Suche nach neuen, meist agileren Formen des Projektmanagements.
Dem Wasserfall-Modell zufolge besteht ein Projekt aus genau definierten, aufeinander folgenden Phasen; ebenso ist dies beim V-Modell, einer Weiterentwicklung des Wasserfall-Modells.
Die wesentlichen Phasen im Wasserfall-Modell (zum Beispiel bei der Softwareentwicklung) sind:
In der Phase 1 „Analyse“ werden zunächst die Anforderungen vollständig dokumentiert, um daraus ein Lasten- oder Pflichtenheft zu entwickeln. Erst danach wird ein Projektplan erstellt und werden die wahrscheinlichen Aufwendungen ermittelt. Große Aufgaben werden im Zuge der Projektplanung in kleine Teilaufgaben gegliedert und alle Aufgaben bezüglich des Zeit- und Ergebnisverlaufs miteinander verbunden.
In der Design-Phase (Phase 2) wird das Lösungskonzept erarbeitet. Bei Software-Projekten sind dies die Architektur und das Systemdesign. Die Implementierungsphase (Phase 3) umfasst die gesamte Programmierung der Anforderungen auf Basis des Lastenhefts und im Rahmen des Projektplans. Das Ergebnis der Implementierungsphase ist ein Software-Produkt, das in der nachfolgenden Test-Phase (Phase 4) zum ersten Mal als Gesamtprodukt getestet wird (Alpha-Test). Dies geschieht in der Regel durch die Entwickler selbst. Als Beta-Version geht die Software danach an ausgewählte Endnutzer, und erst hier zeigt sich, ob das Produkt die zuvor definierten Anforderungen und Erwartungen der Anwender erfüllt. Nach dem erfolgreichen Abschluss der Testphase wird die Software für den Betrieb freigegeben bzw. ein Release erstellt. Mit dem Release beginnt der Einsatz der Software und die fünfte und letzte Phase des Modells (Betrieb). Auftretende Fehler werden behoben, notwendige Verbesserungen und Ergänzungen eingebaut.
Theoretisch soll das Wasserfall- bzw. V-Modell Projektrisiken sowohl kosten- als auch terminseitig vermeiden. Sinnvoll ist sein Einsatz daher bei Projekten, bei denen sich auf Sicht nichts ändert und bei denen es fast keine Anpassungen gibt. Ideal sind Projekte, die sich in Struktur und Aufgabenstellung wiederholen und einen überschaubaren Zeitraum dauern. Das sind oft regulierte Projekte,
Die Erfahrung zeigt jedoch, dass zum Beispiel nur wenige Software-Projekte diesen Parametern unterliegen. Deshalb birgt die Wasserfall-Methode bei der Softwareentwicklung viele Risiken. Ähnlich verhält es bei fast allen größeren Change- und Transformationsprojekten in Unternehmen. Dies ist ein Grund, warum viele Unternehmen nach anderen Projektmanagement-Ansätzen suchen. Ein weiterer ist: Die Komplexität der Anforderungen und die bestehenden Wechselwirkungen im System lassen es bei vielen Projekten kaum zu, klare Projektphasen zu planen. Hinzu kommt ein sich schnell wandelndes Umfeld, mit nicht planbaren neuen Erkenntnissen und Einflüssen. Ungeplante Verläufe und komplexe Strukturen führen beim klassischen Projektmanagement oft dazu, dass Projekte ausgerichtet werden müssen. Drastische Termin- und Kostenverschiebungen sind eine häufige Folge.
Das agile Projektmanagement bedient sich meist des SCRUM-Modells. Dieses steht im Gegensatz zum Wasserfall- bzw. V-Modell. Der wesentliche Unterschied ist: Das (Entwicklungs-)Projekt wird nicht von vorne bis hinten durchgeplant, vielmehr folgt das Vorgehen einer Vision. Dadurch entfallen detaillierte Lasten- und Pflichtenhefte. Zudem ist das Vorgehen
Im Mittelpunkt des Geschehens stehen bei SCRUM-Projekten die Stakeholder (Kunden/Anwender) und die User-Storys. Die User-Storys beschreiben die Anforderungen an das Endprodukt bzw. die Problemlösung aus der Perspektive eines Benutzers. Sie werden meist vom Product-Owner – also der Person, die letztlich für die Arbeit des Entwicklungsteams und die Qualität des Endprodukts verantwortlich ist – mit den Stakeholdern verfasst und parallel zur Entwicklung im fortlaufenden Prozess definiert.
Das Projekt selbst gliedert sich beim agilen Projektmanagement nicht in Phasen, sondern eine Abfolge circa drei- bis vierwöchiger Sprints. In ihnen werden die User-Storys den Entwicklungsteams zugewiesen und zwar jeweils so viele wie vom Team in dieser Zeit leistbar sind. Tägliche Kurzmeetings, Dailys genannt, dienen der Transparenz und Kommunikation innerhalb der SCRUM- bzw. Entwicklungsteams. Probleme werden dort angesprochen und gegebenenfalls sofort gelöst. Ist ein Sprint zu Ende, steht das entwickelte Produkt-Inkrement dem SCRUM-Team und den Stakeholdern zum Beispiel als lauffähige Software zur Verfügung. Der nächste Sprint kann gestartet werden.
Das SCRUM-Modell entstand aus der Erkenntnis, dass viele Software-und IT-Projekte heute sehr komplex sind und einer permanenten Veränderung im Projektverlauf unterliegen. Zudem sind zu Beginn die Vorgaben und Anforderungen oft unklar. Ein agiles Vorgehen ist jedoch keine Erfolgsgarantie. Das zeigen zahlreiche Projekte. Die wesentliche Schwachstelle bei SCRUM-Projekten ist die Abschätzung der Storys durch die Entwickler. Oft sind diese zu optimistisch. Deshalb werden die Ziele der Sprints nicht erreicht. Das erschwert es der Projektleitung, einen längeren Zeitraum zu planen und zu budgetieren. Eine gewisse Planungssicherheit besteht meist nur in einem, maximal zwei Sprint-Zyklen.
Ein zentraler Erfolgsfaktor bei agilen Projekten ist die Reife und Homogenität des Entwicklungsteams. Dieser Anforderung wird in der Praxis oft kaum Rechnung getragen; am wenigsten in Organisationen, die im Übergang von der traditionellen zur agilen Planung sind. Sie unterschätzen oft auch die damit verbundene kulturelle und organisatorische Herausforderung.
Die meisten Unternehmen sind heute als Gesamtorganisation weder agil, noch nicht agil. Denn sie sehen sich seit Jahren mit einer erhöhten Komplexität konfrontiert und suchen nach Möglichkeiten, flexibler auf neue Herausforderungen zu reagieren. Dabei wird das Einbeziehen der Mitarbeiter meist als Schlüssel zu mehr Flexibilität und einer höheren Performance gesehen. Und agile Vorgehensweisen werden „ausprobiert“ in der Hoffnung auf bessere und kundenspezifischere Lösungen.
Deshalb existieren in den Unternehmen beim Projektmanagement oft „Zwitter“: Neue Mitarbeiter werden an Bord geholt mit dem Versprechen einer agilen, selbstbestimmten Arbeitsweise. Zugleich „leben“ in der Organisation jedoch noch die alten Strukturen und das klassische Projektmanagement: Es existieren beim Projektmanagement sozusagen Parallelwelten. Diese sind im Stadium des Übergangs normal und müssen gemanagt werden. Das gilt insbesondere dann, wenn die Entscheidungsträger in der IT oder der Geschäftsführung einem agilen Projektmanagement eher kritisch bzw. abwartend skeptisch gegenüber stehen.
Beim Projektmanagement ist es nicht möglich, den berühmten Schalter umzulegen, um vom klassischen zum agilen Projektmanagement zu kommen. Hinzu kommt: Auch bei Agilen Projekte gibt es Probleme, jedoch andere aus bei Projekten, die klassisch gemanagt werden. Deshalb ist es wichtig, in Unternehmen klar zu kommunizieren, welche Projekte nach welchen Regeln durchgeführt werden.
Ein agiles Projektmanagement ist darauf ausgerichtet, die Kunden und Anwender direkt in den Entwicklungs- bzw. Problemlösungsprozess einzubinden und schnell sichtbare Zwischenergebnisse zu erzielen; das klassische Projektmanagement hingegen fokussiert auf eine umfassende Planung und Dokumentation vor dem Projektstart. Leistungsmindernder Irritationen entstehen in Unternehmen, wenn zum Beispiel neue Mitarbeiter mit dem Versprechen von Agilität „an Bord“ geholt werden, sich dann jedoch mit dem klassischen Projektmanagement-Ansatz konfrontiert sehen.
Da beide Vorgehensweisen ihre Berechtigung haben, stellt sich die Frage: Wann die eine, wann die andere? Um diese zu beantworten, ist eine eindeutige Kommunikation nötig; außerdem muss auf der Führungsebene ein Verständnis für ein „sowohl, als auch“ geschaffen werden. Dann kann undogmatisch und erfolgsorientiert entschieden werden, welches Prinzip bei welchem Projekt gilt. Erfahrene Projektleiter spielen ohnehin in beiden Segmenten.
Ein hybrides Projektmanagement hat zum Ziel, eine optimale Arbeitsumgebung für die Teams zu schaffen – ohne Dogmen. Deshalb werden in hybriden Projekten Methoden und Werkzeuge aus beiden Welten genutzt.
Am Anfang eines hybriden Projektmanagements steht die Analyse-Phase: jedoch nicht des Gesamtprojekts in der Tiefe, sondern in einer eher groben Granulierung. Diese Phase wird begleitet von einem generellen Systemdesign. Nun wird das Grobgranulare aufgeteilt in Projektschritte, und ab diesem Augenblick werden agile Methoden eingesetzt und sowohl Analyse, Design, Implementierung, Test als auch Alpha-Betrieb parallel gefahren. Regelmäßige Dailys sorgen dabei dafür, dass sich alle Beteiligten synchronisieren können.
Die Phasen des Wasserfalls werden beim hybriden Projektmanagement in Iterationen, also Sprints, aufgeteilt. Dabei können alle Phasen des klassischen Wasserfall-Modells in einem Sprint vorkommen. So kann zum Beispiel im Rahmen eines Sprints die Analyse detailliert werden, ebenso das Systemdesign. Daraus entstehen im laufenden Sprint dann die User-Stories für den nächsten Sprint. Dabei sind alle Methoden der agilen Vorgehensweise jedoch eingebettet in Wasserfall-Prinzipien.
Anstelle eines Statusmeetings endet der Sprint mit einem Review und der Retrospektive, bevor der nächste Sprint gestartet wird. Alle gesammelten Erfahrungen kommen hierbei auf den Tisch und werden auf das gesamte, noch folgende Projekt abgeglichen. Es kann sein, dass dadurch Termine verschoben, Ressourcen angepasst und Erwartungen verändert werden müssen. Aber das Wesentliche hierbei ist: Die Risiken des Projekts werden mit jeder Iteration kleiner und treten nicht erst gegen Ende des Projekts zutage.
Das Zusammenspiel agiler und konventioneller Projektmanagement-Methoden stellt beim Bestreben, die Agilität von Unternehmen zu erhöhen, einen natürlichen Entwicklungsschritt dar und damit einher geht ein Kultur- und Strukturwandel in der Organisation. Deshalb sollte dieser Prozess durch ein professionelles Change-Management bewusst und gezielt gesteuert werden. Die Aufgabe des Managements hierbei ist es, das Nebeneinander neuer und konventioneller Arbeitsweisen in Projekten zu ermöglichen und die erforderlichen Rahmenbedingungen hierfür zu schaffen.
Für viele „Anhänger“ der agilen Methode bzw. des klassischen Projektmanagements wurde es zur Glaubensfrage, welcher Ansatz in Projekten den Vorzug verdient. Diese Ist-Situation gilt es durch das Schaffen einer bereichs-, funktions- und hierarchieübergreifenden Kultur der Offenheit und Unvoreingenommenheit zu überwinden.
Die (Projekt-)Management-Beratung Kraus & Partner unterstützt Unternehmen, sofern gewünscht, beim Entwickeln einer Projektmanagement-Philosophie, die ihrem Bedarf entspricht; außerdem beim Planen, Durchführen und Steuern von (strategischen, auch bereichs- sowie standort- und unternehmensübergreifenden) Projekten. Zudem vermittelt sie ihren Mitarbeitern - u.a. in Trainings und Coachings - das Know-how und Können, das sie für ein professionelles Projektmanagement brauchen.
