- Alphadi Deutschland GmbH
- +49 561 949 189 0
- info@alphadi.org
Klassisches Projektmanagement (PMI) ist phasenorientiert und folgt festen Plänen, ideal für stabile Projekte. Agiles Management, wie SCRUM, arbeitet iterativ in kurzen Sprints und passt sich laufend an neue Anforderungen an. Während PMI auf Stabilität setzt, bietet SCRUM Flexibilität für dynamische Projekte.
„Nachfolgend ein Auszug aus unserem Blue Book, Seiten 60–73 (PMI) und 174–186 (SCRUM).“
Ein Projekt ist ein einmaliges, zeitlich begrenztes Vorhaben, um ein Produkt, eine Dienstleistung oder ein Ergebnis herzustellen. Für die Durchführung von Projekten gibt es verschiedene Projektmanagementmethoden. Diese können grob in agile und klassische Projektmanagementmethoden unterteilt werden.
Die Gründe zur Durchführung eines Projektes können sehr unterschiedlich sein. Ein Hauptzweck ist die Schaffung von geschäftlichem Wert. Ein Projekt wird durchgeführt, um eine Lücke (Gap) zu schließen. Diese Lücke könnten beispielsweise Qualitätsprobleme, Zeitprobleme oder neue Innovationen sein.
Man kann Projekte, die sich gegenseitig beeinflussen, als Programm managen und durch die gemeinsame Koordination Vorteile nutzen. Ein Programm besteht also aus mehreren Projekten, die zusammenhängen. Unter einem Portfolio versteht man eine Sammlung einzelner Projekte, Programme und Portfolios, die notwendig sind, um strategische Ziele zu erreichen. Die einzelnen Projekte und Programme in einem Portfolio müssen nicht zusammenhängen. Auch in einem Portfolio werden die Projekte, Programme und Portfolios gemeinsam gemanagt.
Ein Projekt kann durch eine einzelne Person durchgeführt werden, aber auch durch ein Team. Bei komplexen Projekten ist die Arbeit im Team unerlässlich, da mehr Teammitglieder mehr Fähigkeiten besitzen.
Der Projektmanager ist für die Erreichung der Projektziele und für die Führung des Teams verantwortlich. Eine Person wird von der Organisation zum Projektmanager ernannt. Der Projektmanager sollte Kompetenzen in den Bereichen Leadership, Projektmanagementmethoden und strategische bzw. geschäftliche Managementfähigkeiten besitzen.
Jede Person sollte neben Wissen, Soft und Hard Skills auch ein angemessenes Verhalten zeigen. Die wichtigsten Werte sind:
Nach PMI zertifizierte Projektmanager, die sich nicht an den Kodex halten, können gemeldet werden. Das Project Management Institute überprüft das Verhalten, indem die Personen ein Disziplinarverfahren durchlaufen.
Bei den Projektmanagementmethoden unterscheidet man grob zwischen klassischem und agilem Projektmanagement. Das klassische Projektmanagement teilt die Projektvorgänge in mehrere Phasen auf, die aufeinander aufbauen, sprich, ist die erste Phase fertig, kann mit der nächsten Phase gestartet werden. Eine Phase ist eine Sammlung von mehreren Vorgängen, die logisch zueinander passen. Zwischen den Phasen finden in der Regel Phase Gates bzw. Gate Reviews statt. Dies ist eine Überprüfung der Ergebnisse am Ende einer Phase. Beim agilen Projektmanagement geht man iterativ vor, sprich, man führt mehrere Iterationsschleifen aus, in denen man dem Projektziel jedes Mal ein Stück näher kommt. Die Iterationen sollten voneinander unabhängig sein, sodass sie in einer anderen Reihenfolge durchgeführt werden könnten, sprich, man versucht, nach jeder Iteration ein nützliches Teilprodukt herzustellen.
Das magische Dreieck stellt dar, dass in einem Projekt der Scope (Anforderungen), die Ressourcen und die Zeit voneinander abhängen und dadurch aufeinander abgestimmt sein müssen. Bei klassischen Projekten wird davon gesprochen, dass der Scope fest ist und anhand dessen die Ressourcen und die Zeit bestimmt werden. Daraufhin würden die meisten Personen Einspruch erheben, denn oft werden das Budget und die Zeit für ein Projekt als Erstes festgelegt. Bei einer agilen Vorgehensweise ist der Scope variabel. Jetzt kann man diskutieren, wie das mit der Zeit und den Ressourcen ist: Die Zeit für einen Sprint ist fix. Dadurch, dass vorwiegend Personen als Ressourcen benötigt werden (Achtung: gilt vor allem in der Softwareentwicklung), sind diese ebenfalls fest. Oder man argumentiert, dass die Anzahl an Sprints nicht fest ist, also auch die Zeit nicht und die Kosten damit auch nicht. In klassischen Projekten wird der Projektumfang am Anfang fest definiert und in agilen Projekten nicht.
Projekte werden im Umfeld von Unternehmen durchgeführt. Da jedes Unternehmen verschieden ist, sollte sich das Projektmanagement an die eigenen Begebenheiten anpassen.
EEF steht für „Enterprise Environmental Factors“. Im Deutschen verwendet man den Begriff „Faktoren der Unternehmensumwelt“. Hierunter versteht man Bedingungen aus der internen und externen Umwelt, welche vom Projektteam nicht direkt beeinflusst werden können, sich aber umgekehrt auf das Projekt auswirken.
Beispiele für interne EEFs:
Beispiele für externe EEFs:
OPA steht für „Organizational Process Assets“, oder im Deutschen: das Prozessvermögen der Organisation. Das Prozessvermögen der Organisation beschreibt unternehmensspezifische Pläne, Prozesse, Richtlinien und Verfahren. Diese sollten bei der Durchführung von Projekten berücksichtigt werden.
Beispiele:
Das Projektmanagementbüro oder Project Management Office (PMO) ist eine Organisations-struktur, welche die Projektdurchführung im Hinblick auf Werkzeuge, Prozesse, Verfahren und Führung standardisiert. Das PMO kann eine Abteilung oder eine einzelne Person sein. Der Einfluss des PMO auf die Projektdurchführung kann unterschiedliche Ausprägungen haben. Das Projektmanagementbüro kann den Projektmanager unterstützen, steuern oder anweisen.
Offiziell startet ein Projekt in der Regel mit dem Projektauftrag. Bevor der Projektauftrag unterschrieben ist, werden schon die ersten Informationen wie Kosten und Nutzen des Projektes erarbeitet.
Das normale Ende eines Projektes ist das Erreichen des Projektziels, wie z.B. beim Hausbau das fertiggestellte Haus. Doch es gibt auch Projekte, die nie fertiggestellt werden, weil keine finanziellen Mittel mehr zur Verfügung stehen, das Ergebnis nicht mehr gebraucht wird, die Ressourcen fehlen oder weil das Projektziel rechtlich obsolet ist.
Man kann die notwendigen Schritte während eines Projektes in fünf Prozessgruppen unterteilen: die Initiierungsprozessgruppe, die Planungsprozessgruppe, die Ausführungsprozessgruppe, die Überwachungs- und Steuerungsprozessgruppe und die Abschlussprozessgruppe. Diese Prozessgruppen laufen nicht nacheinander ab, sondern parallel. Je nach Zeitpunkt im Projekt fallen mehr oder weniger Aufgaben in den einzelnen Prozessgruppen an.
Im Diagramm sieht man den Verlauf über die Zeit und die Größe des Aufwands zu verschiedenen Zeitpunkten. Zu Beginn eines Projektes gibt es sehr viele Aufgaben in der Initiierungsprozessgruppe und in der Planungsprozessgruppe. Im Folgenden werden die Prozessgruppen hintereinanderweg betrachtet, obwohl sie im Projekt oft parallel ausgeführt werden.
SCRUM ist eine agile Projektmanagementmethode. Der Ursprung von SCRUM liegt in der Softwareentwicklung. Die beiden Begründer Jeff Sutherland und Ken Schwaber stehen hinter SCRUM und dem SCRUM Guide, welcher beschreibt, was SCRUM genau ist. SCRUM wird kontinuierlich weiterentwickelt. Die Änderungen sieht man im neuen SCRUM Guide, welcher kostenlos im Internet zu finden ist.
SCRUM ist ein einfaches Rahmenwerk, welches auf folgenden Elementen aufgebaut ist:
Die Idee von SCRUM ist es, ein Produkt in mehreren Zeitschleifen (Iterationen oder Sprints) zu entwickeln. Hierfür werden zunächst die bekannten Anforderungen für das Produkt in einer Liste, dem Product Backlog, gesammelt. Aus der Liste werden die Einträge ausgewählt, die im kommenden Sprint bzw. in der kommenden Iteration geschafft werden können. Während des Sprints werden die Anforderungen umgesetzt, sodass am Ende ein Teilprodukt entsteht. Dieses wird untersucht, um Verbesserungen zu identifizieren. Der nächste Sprint startet dann wieder mit der Auswahl der Anforderungen.
Zwar hat SCRUM seinen Ursprung in der Softwareentwicklung, es kann jedoch auch gut in anderen Bereichen angewendet werden.
Ein SCRUM Team hat in der Regel eine Größe von höchstens zehn Personen oder weniger. In SCRUM werden drei Rollen mit unterschiedlichen Verantwortlichkeiten unterschieden: der SCRUM Master, der Product Owner und die Developer. In jedem SCRUM Team gibt es einen SCRUM Master, einen Product Owner und mehrere Developer. Es kann auch eine Doppelbesetzung geben, wie zum Beispiel, dass der SCRUM Master auch ein Developer ist. Empfehlenswert ist dies aber meistens nicht, da dies zu Rollenkonflikten führen kann.
Ein SCRUM-Projekt besteht aus mehreren Sprints. Die Anzahl an Sprints, die notwendig sind, um das Projekt fertigzustellen, ist oft zu Projektbeginn noch nicht bekannt. Dies hängt damit zusammen, dass in einigen Projekten die Anforderungen zu Beginn nicht vollständig bekannt sind. Nicht alle Anforderungen zu kennen, führt oft zu Problemen bei der Durchführung von Projekten mit klassischen Projektmanagementmethoden wie dem Wasserfallmodell. Hier bietet SCRUM eine Lösung.
In SCRUM gibt es fünf Ereignisse bzw. Events: den Sprint, das Sprint Planning, das Daily SCRUM, den Sprint Review und die Sprint Retrospektive. Der Sprint selbst ist ein Container und nimmt die anderen Events auf. Ein Sprint hat einen festgelegten Zeitraum von maximal 4 Wochen. Während des Sprints wird von den Developern ein fertiges Produktinkrement hergestellt. Ein Sprint startet mit dem Sprint Planning Meeting, in dem der gerade begonnene Sprint geplant wird. Nach der Planung erfolgt die Umsetzung, während dieser Phase findet täglich das Daily SCRUM statt. Kurz vor dem Ende des Sprints begutachtet man im Sprint Review das Produktinkrement, um Verbesserungen und fehlende Funktionen zu identifizieren. Nach dem Sprint Review findet die Sprint Retrospektive statt. Hier geht es darum, Potenzial zur Verbesserung der Zusammenarbeit und der Effizienz zu identifizieren. Der Sprint endet, wenn die Timebox abgelaufen ist. Dann startet der nächste Sprint.
Ein Sprint kann abgebrochen werden, wenn das Sprintziel obsolet wird. Der Sprintabbruch darf nur vom Product Owner durchgeführt werden.
In SCRUM sind alle Events zeitlich begrenzt (Timeboxed). Die maximale Dauer der Events ist für den Sprint auf 4 Wochen, für das Sprint Planning auf 8 Stunden (bei einem 4-wöchigen Sprint, sonst in der Regel kürzer), für das Daily SCRUM auf 15 Minuten (immer), für den Sprint Review auf 4 Stunden (bei einem 4-wöchigen Sprint, sonst in der Regel kürzer) und für die Sprint Retrospektive auf 3 Stunden (bei einem 4-wöchigen Sprint, sonst in der Regel kürzer) festgelegt. Bis auf den Sprint, dürfen alle anderen Events vorzeitig beendet werden, sofern sie ihren Zweck erfüllt haben. Die Dauer des Sprint Plannings, des Sprint Reviews und der Sprint Retrospektive wird in der Regel an die Sprintlänge angepasst.
Der Sprint startet mit dem Sprint Planning Meeting. Das Sprint Planning Meeting ist ein Meeting, bei dem sich das gesamte SCRUM Team trifft, um den gerade gestarteten Sprint zu planen. Für das Event steht bei einer Sprintlänge von 4 Wochen eine maximale Timebox von 8 Stunden zur Verfügung. Wählt man kürzere Sprints, wird die Zeit in der Regel reduziert. Pro Sprintwoche plant man ungefähr 2 Stunden für das Sprint Planning Meeting. Während dieses Events legt das Team gemeinsam das Sprintziel fest. Die Developer wählen die Einträge aus dem Product Backlog aus, die sie in diesem Sprint schaffen können und erstellen zu den ausgewählten Einträgen einen Umsetzungsplan.
Das Daily SCRUM findet täglich im Sprint statt. Es hat eine Timebox von 15 Minuten, unabhängig davon, wie viele Developer am Projekt arbeiten und welche Sprintlänge gewählt ist. Das Daily SCRUM findet immer am gleichen Ort zur gleichen Zeit statt und ist ein Meeting für die Developer. Der SCRUM Master und der Product Owner müssen nicht am Daily SCRUM teilnehmen. Während des Daily SCRUMs überprüfen die Developer, ob der Fortschritt im Sprint angemessen ist (z.B. mit dem Burn-Down-Chart) und besprechen die Aufgabenverteilung für die nächsten 24 Stunden. Hierbei wird das Sprint Backlog – auch SCRUM Board genannt – angepasst.
Das Sprint Review bietet eine formelle Gelegenheit, zu der sich das SCRUM Team mit den wichtigsten Stakeholdern trifft, um über das Produkt zu sprechen. Das Ziel ist nicht die Abnahme des Inkrements, sondern die Zusammenarbeit, um Verbesserungspotenzial für das Inkrement zu finden und dienächsten Schritte zu besprechen.
Die Sprint Retrospektive ist eine Lessons Learned für das gesamte SCRUM Team. Während des Meetings werden Verbesserungen für die Qualität und Geschwindigkeit des SCRUM Teams gesammelt, ausgewählt und wenn möglich sofort umgesetzt. Der Fokus bei der Retrospektive liegt auf der Zusammenarbeit im Team, der angewendeten Techniken und den verwendeten Dokumenten, wie die „Definition of Done“. Einen guten Hinweis auf Verbesserungen liefern die Probleme, die im letzten Sprint aufgetreten sind.
Mit mehr als 4.000 Projekten und Fallstudien ist die Firma Alphadi führend im Bereich Lean Six Sigma sowie Sales Process Engineering. Wir beraten Sie ganzheitlich, damit Ihre Ziele nachhaltig und langfristig erreicht werden.
2024 © All Rights Reserved.
