Projektmanagement für Projektmanager:

nach dem internationalen Standard ISO 21502

 

Vorwort

Willkommen zu “Projektmanagement für Projektmanager – nach dem internationalen Standard ISO 21502”. Dieses Buch wurde speziell entwickelt, um Projektmanager mit praktischen Einblicken in die Anwendung des globalen Standards für Projektmanagement zu stärken.

Im Zentrum dieser Reise stehen fünf wesentliche Prozesse – Initialisierung, Planung, Ausführung, Kontrolle und Abschluss. Diese Prozesse sind keine isolierten Einheiten; sie sind eng miteinander verbunden und bilden das Fundament für effektives Projektmanagement.

Im gesamten Buch finden Sie eine fortlaufende Fallstudie, die als praktische Veranschaulichung der besprochenen Konzepte dient. Dieser Ansatz verbessert Ihr Verständnis des Themas und dessen Anwendung in der Praxis.

Projektmanagement ist das Vehikel des Wandels, und dieses Buch ist Ihr Werkzeugkasten, um es zu meistern. Es stattet Sie mit globalen Best Practices aus und ermöglicht Ihnen, Projekte mit Präzision und Exzellenz zu steuern.

 

 

 

 

0.0 Einführung

The Das allgemeine Modell dieses Kurses orientiert sich an der Logik der Aktivitäten zur Initialisierung, Planung, Ausführung, Kontrolle und zum Abschluss eines Projekts und seiner Phasen. Dies führt zu Lieferobjekten und Ergebnissen, die an die Benutzer weitergegeben werden. Zudem entsteht Wissen, das an die beteiligten Organisationen und Personen übermittelt wird. Diese Ablauforganisation entspricht dem Anhang der Norm. Aber es betrifft nicht nur Projektarbeit: Alle Arten von Arbeit werden initialisiert, geplant, ausgeführt, kontrolliert und abgeschlossen, denn diese Managementfunktionen sind universell, und jeder Manager wendet sie in seiner täglichen Arbeit an.

Im Projektmanagement lautet die erste zu klärende Frage: Soll ein Projekt gestartet werden? Und falls ja: aus welchem Grund? Typische Gründe für die Initialisierung eines Projekts können eine bestehende Geschäftsmöglichkeit, ein zu lösendes Problem oder eine zu erfüllende Vorschrift sein.

Bei zeitlichen Einschränkungen für die benötigte Lösung kann es sinnvoll sein, die Arbeit als Projekt zu organisieren. Wenn der geplante Umfang ein einzelnes Projekt überfordert, beispielsweise wenn Vorteile erst nach der Lieferung der Lösung an die Endbenutzer sichtbar werden, könnte es ratsam sein, ein Programm aus verwandten Projekten zu organisieren. Ein weiterer Grund, die mit der Initiative verbundene Arbeit als Projekt, oder Programm zu strukturieren, liegt in der Disziplin des Projektmanagements Selbst. Sie bietet eine Vielzahl von Werkzeugen und Techniken, die speziell darauf ausgerichtet sind, Lösungen pünktlich, in der gewünschten Form, und innerhalb eines festgelegten Budgets zu liefern.

In der Vorprojektphase kommen Bewertungsmethoden zum Einsatz, wie beispielsweise die Erstellung eines Business Case oder einer Machbarkeitsstudie. Diese Methoden können Teil eines umfassenderen Prozesses sein, der von der Unternehmensleitung gesteuert wird und oft als “Portfoliomanagement” bezeichnet wird. Das Ziel dieses Managements ist es, zu entscheiden, welche Initiativen umgesetzt werden sollen. Fällt die Entscheidung in der Vorprojektphase positiv aus, so wird ein Projekt initialisiert. In diesem Stadium wird das Projekt noch nicht geplant, sondern lediglich initialisiert.

 

Projektinitialisierung.

In dieser Phase kann es vorkommen, dass der Projektmanager bereits informell bestimmt wurde. Eine offizielle Ernennung erfolgt jedoch meist als Ergebnis des Initialisierungsprozesses. Es ist empfehlenswert, den zukünftigen Projektmanager schon während der Initialisierung einzubinden, obwohl diese Phase in der Regel unter der Aufsicht des Initiators oder des Projektsponsors steht. Erst nachdem alle Initialisierungsaktivitäten abgeschlossen sind, wird die neue temporäre Organisation, also das neue Projekt, offiziell ins Leben gerufen. Dies beinhaltet auch die Festlegung des Namens und des Autoritätsgrades des ernannten Projektmanagers.

Ein sinnvoller erster Schritt bei den Aktivitäten zur Projektinitialisierung ist die Identifizierung der Schlüsselstakeholder. Gemeinsam mit ihnen legt der Projektmanager fest, welchen Aspekt des Problems oder der Geschäftsmöglichkeit das Projekt adressieren soll. Dabei werden auch der Zweck und das Hauptziel des Projekts definiert.

Der Projektsponsor spielt dabei eine zentrale Rolle. Zwei wesentliche Fragen stehen im Mittelpunkt: “Was wollen wir erreichen?” und “Warum wollen wir das erreichen?”. Das “Warum” ist der Zweck und das Was, ist das Hauptziel des Projekts.

Bei der Formulierung der Zweck- und Zielsetzungserklärung, ist es sehr hilfreich sich über die Geschäftsanforderungen des Projekts zu einigen. Geschäftsanforderungen sind die neuen Fähigkeiten, die die Organisation durch das Projekt erwerben möchte.

Sie dürfen nicht mit den funktionalen Anforderungen und Qualitätsattributen der Lösung verwechselt werden, die später während der Planung ermittelt werden.

Bevor funktionale Anforderungen an eine Lösung gestellt werden können, muss das Team die optimale Strategie zur Erreichung des Hauptziels identifizieren, analysieren und auswählen. Es existieren stets mehrere Wege ein Hauptziel zu erreichen. Das zentrale Lieferobjekt das das Projekt hervorbringen wird, nämlich die Lösung ist direkt von der gewählten Strategie abhängig.

Während der Initialisierung sollten die Erfolgskriterien des Projekts, die allgemeinen Risiken, die anfänglichen Annahmen und bestehenden Einschränkungen identifiziert werden. All diese Elemente der Projektdefinition müssen in einem Dokument festgehalten werden. Dieses Dokument wird üblicherweise als Projektauftrag bezeichnet. Mit dem Projektauftrag wird offiziell eine neue temporäre Organisation ins Leben gerufen, das neue Projekt das zuvor nicht existierte. Dieser Schritt erfordert die Genehmigung der Organisation und muss den Stakeholdern mitgeteilt werden.

Planungsaktivitäten.

Jede Aufgabe erfordert eine Planung, bevor sie umgesetzt wird. Selbst wenn diese Planung nur gedanklich erfolgt und nicht schriftlich festgehalten wird. Dies gilt ebenso, wenn die Arbeit in Form eines Projekts organisiert wird.

Das Projektmanagementteam beginnt damit, die Anforderungen der Schlüsselstakeholder in Bezug auf das Projektmanagement zu erheben. Zudem werden die Annahmen und Einschränkungen, die während der Projektinitialisierung getroffen wurden, erneut überprüft, um mögliche Änderungen zu identifizieren.

Nun ist es an der Zeit, präzise SMART-Unterziele zu definieren. Das bedeutet, dass diese Unterziele spezifisch, messbar, erreichbar, relevant und zeitlich begrenzt sein sollten. Sie sollten natürlich auch zum Hauptziel des Projekts führen, wie im Projektauftrag festgelegt.

Das Projektplanungsteam muss den Lebenszyklus oder Ansatz festlegen, der für die Lösungserstellung verwendet wird, und die kommenden Phasen oder Iterationen bestimmen.

Besonderes Augenmerk sollte auf die Ausarbeitung des Projektbasisplans gelegt werden. Dieser Plan beinhaltet den genehmigten Umfang, das Budget und den Zeitplan des Projekts. Er definiert, was das Projekt liefern wird, zu welchem Zeitpunkt und zu welchen Kosten.

Die Anforderungen für das Projektmanagement zeigen, wie das Projekt gesteuert werden soll.

Während der Planung wird das Team die Risiken identifizieren und analysieren, um die kritischsten herauszufiltern und entsprechende Reaktionsstrategien zu entwickeln.

Sind all diese Elemente sorgfältig abgestimmt und ausbalanciert, sollte die Zustimmung des Projektgovernancegremiums eingeholt werden. In den meisten Fällen setzt sich dieses Gremium aus dem Projektsponsor und dem Projektkunden zusammen, sofern diese beiden Rollen nicht von derselben Person ausgefüllt werden.

Abschließend informiert der Projektmanager die Stakeholder über den genehmigten Projektmanagementplan. Ein zweites Kick-off-Meeting kann organisiert werden, um alle Beteiligten über den finalen Plan aufzuklären und den Übergang von der Planung zur Ausführung zu vollziehen.

Ausführungsaktivitäten.

Jetzt gilt es, das Hauptlieferobjekt zu erstellen. Dies beginnt mit der Beschaffung von Personal und Material, wobei der Projektmanager den Ressourcenbeschaffungsprozess leitet oder aktiv daran teilnimmt.

Ein wesentlicher Bestandteil des Ausführungsmanagements ist die Genehmigung, Delegation, Überprüfung und Akzeptanz von Arbeitspaketen. Parallel dazu leitet, steuert und entwickelt der Projektmanager Teams, setzt Coaching-Techniken ein, koordiniert die Kommunikation und fördert das Engagement der Stakeholder.

Die Qualitätssicherung während der Projektausführung geht über die bloße Überprüfung der Einhaltung von Standards und Richtlinien hinaus. Sie konzentriert sich darauf, die notwendige Qualität während des gesamten Projektverlaufs sicherzustellen.

Das Implementieren von genehmigten Änderungen und Korrekturmaßnahmen, die aus den Kontrollaktivitäten resultieren, gehört ebenfalls zum Ausführungsmanagement. Dazu zählt auch die Umsetzung von Reaktionsstrategien auf identifizierte Risiken.

Abschließend stellt der Projektmanager während der Projektausführung sicher, dass das Team vorhandenes Wissen nutzt und eine förderliche Umgebung für die Generierung neuen Wissens schafft. Dies beinhaltet auch Prozessverbesserungen, die aus den Erkenntnissen der Team-Retrospektiven gewonnen werden.

Kontrollaktivitäten.

Der Zweck der Projektkontrolle besteht darin, den aktuellen Zustand zu verstehen, den zukünftigen Zustand mittels Kosten- und Zeitplanprognosen zu diagnostizieren und Korrektur- sowie Vorbeugungsmaßnahmen einzuleiten.

Die Kontrollprozesse berücksichtigen alle Aspekte des Projektmanagementplans, einschließlich des Projektbasisplans, aber auch Risiken, die Effektivität der Kommunikation, das Engagement der Stakeholder, materielle Ressourcen und Beschaffungen.

Ein Teil der Kontrollarbeit bezieht sich auf die Bewältigung von Problemen und Änderungsbedarfen, die während der Projektausführung auftreten. Hierbei werden Problemlösungstechniken und andere Methoden angewendet, um die bestmögliche Lösung zu bewerten, Entscheidungen zu treffen und die entsprechenden Korrekturmaßnahmen und Änderungen einzuleiten, die die Planungs- und Ausführungsprozesse beeinflussen.

Da die meisten Projekte phasenweise strukturiert sind, müssen auch die Übergänge zwischen diesen Phasen kontrolliert werden. Diese Kontrolle umfasst die Bewertung der endenden Phase, aber auch die Entscheidung darüber, ob das Projekt zur nächsten Phase übergehen soll. Dafür stellt der Projektmanager dem oberen Leitungsgremium des Projekts die für diese Entscheidung relevanten Informationen zur Verfügung, einschließlich der Planung der nachfolgenden Phase und aktualisierten Prognosen zum Projektende.

Die Kontrolle der Phasentore umfasst auch die Sicherstellung, dass Abschlussaktivitäten der vorherigen Phase durchgeführt wurden. Dazu gehören die Übergabe der Phasenlieferobjekte, die Freigabe nicht mehr benötigter Ressourcen und spezifische administrative Abschlusstätigkeiten der Phase, wie das Aktualisieren von Aufzeichnungen, das Sammeln von Erkenntnissen und mehr.

Abschließen.

Abschlussaktivitäten werden am Ende jeder Phase durchgeführt. Jedoch, am Ende der letzten Phase, die zugleich das Projektende markiert, werden viele dieser Aktivitäten mit den Aktivitäten des Projektabschlusses kombiniert.

Es ist wichtig sicherzustellen, dass die Lieferobjekte bewertet, akzeptiert und übergeben worden sind.

Außerdem soll die Leistung der Teammitglieder und der Lieferanten sowie die Zufriedenheit der Stakeholder bewertet werden.

Dies schließt die zuvor erwähnten administrativen Abschlusstätigkeiten ein. Hinzu kommen spezifische Abschlussaktivitäten für das gesamte Projekt, wie die Bewertung des Projekterfolgs basierend auf den im Projektauftrag festgelegten Erfolgskriterien. Selbstverständlich gehört auch die Erstellung eines Projektabschlussberichts zu diesen Aktivitäten.

Ein abschließender Hinweis zur Anwendbarkeit der internationalen Norm ISO 21502: Die darin enthaltene Anleitung ist für jede Organisation, Projektart oder Ausführungsansatz geeignet.

Wenn das vom Projekt zu erstellende Produkt zu Beginn mit einem hohen Grad an Sicherheit festgelegt werden kann, eignet sich ein prädiktiver Entwicklungsansatz. Ist das Endprodukt jedoch unklar oder der Kunde unsicher in seinen Anforderungen, sodass die Ausführung des Projekts einer Entdeckungsexpedition gleicht, dann ist es sinnvoll, die Anforderungen schrittweise zu entwickeln. Hierbei können inkrementelle Ansätze zum Einsatz kommen. Dabei werden Funktionen in Teilschritten geliefert oder man verwendet iterative Ansätze, bei denen bereits erstellte Funktionen schrittweise verbessert werden. Oft werden beide Ansätze kombiniert. Dies ist der Agile Ansatz. Er beinhaltet verschiedene wertvolle Praktiken, die von diversen Agile-Methoden detailliert beschrieben werden, und die Durchführung bestimmter Rituale vorsehen.

In vielen Organisationen ist es üblich, im Voraus ein Budget und eine Frist festzulegen, um eine Initiative zu genehmigen. Dies gilt auch dann, wenn Teile der Lösung einen signifikanten unbekannten Faktor aufweisen und mittels agiler Ansätze entwickelt werden müssen. Eine Methode, um dieses Dilemma zu bewältigen, besteht darin, das Unvorhersehbare im Voraus zu antizipieren und mit Annahmen zu arbeiten. Das führt oft dazu, dass viele Änderungsanfragen bearbeitet werden müssen. Denn Änderungen sind in Projekten unvermeidlich, insbesondere wenn sie Neuland betreten.

Oftmals sind Projekte hybrid gestaltet, wobei einige Abschnitte vorhersehbarer sind als andere. Einige Komponenten der Gesamtlösung können überwiegend agil gestaltet sein. Lieferanten, die solche Komponenten mit einem agilen Ansatz entwickeln, betrachten oft ihren Beitrag als “das Projekt”. Und in der Tat ist es aus ihrer Perspektive “ihr Projekt”, obwohl es nur eine Komponente eines größeren Ganzen ist. Für den Endkunden stellt dieses agile “Projekt” des Lieferanten tatsächlich ein Arbeitspaket dar, eine Komponente einer Gesamtlösung, die möglicherweise nicht in Gänze agil gesteuert wird.

Ungeachtet des gewählten Entwicklungsansatzes oder der Managementphilosophie müssen alle Arbeiten initialisiert, geplant, durchgeführt, kontrolliert und abgeschlossen werden. Die ISO-Norm für das Projektmanagement bietet hierfür eine wertvolle Anleitung.

 

0.1 Standards für Projektmanagement

Dieser Abschnitt erklärt die Vorteile der Verwendung eines anerkannten Standards für das Projektmanagement.

Methoden des Projektmanagements gibt es schon seit Hunderten von Jahren. Denken Sie an Projekte wie die Golden Gate Bridge, den Eiffelturm und sogar die Erfindung von Smartphones. Projektmanagementtechniken können auch für weniger bekannte, aber wichtige Dinge verwendet werden, wie den Bau oder die Renovierung eines Hauses.

Ob es sich um große oder kleine Projekte handelt, mit der Etablierung des Berufs des Projektmanagers hat auch die Notwendigkeit zugenommen, eine dokumentierte Anleitung für die Ausübung des Berufs zu haben.

Aus diesem Bedarf heraus entstanden ab 1995 Leitfäden von Berufsverbänden, wie der PMBOK des Instituts für Projektmanagement der Vereinigten Staaten, der ICB der IPMA-Verbandskonföderation und der Prince2 der britischen Regierung, um die wichtigsten zu nennen.

Bei der Suche nach einem geeigneten konzeptuellen Rahmen für diesen Kurs entschied sich der Autor dazu, die im Dezember 2020 veröffentlichte internationale Norm ISO 21 502 als Grundlage zu verwenden. Die Internationale Organisation für Normung, kurz ISO ist für internationale Standards verantwortlich und sie ist insbesondere durch die Normenfamilie ISO 9000, bekannt geworden. So kennt und erkennt jeder die Autorität der ISO-Institution. Dies vermeidet die Unwägbarkeiten privater Verbände. Darüber hinaus waren alle zuvor genannten Institutionen an der Erstellung der ISO 21502 beteiligt, ebenso wie die Vertreter der nationalen Normungsstellen zahlreicher Staaten. Daher können wir sagen, dass die ISO 21502 die gemeinsame Grundlage aller anerkannten Rahmenwerke im Projektmanagement ist.

Um das Verständnis zu erleichtern, haben wir die Praktiken, die die ISO 21502 beschreibt, entsprechend den Prozessgruppen organisiert, die die Norm in ihrem Anhang A vorschlägt. Diese Prozessgruppen beziehen sich auf die Aktivitäten der Initialisierung, Planung, Ausführung, Kontrolle und des Abschlusses, und wir werden sie im Laufe des Kurses ausführlich erklären.

Was ist die Bedeutung der Verwendung eines weltweit anerkannten Standards?

Zunächst kann eine internationale Norm von jeder Organisation verwendet werden, sei es öffentlich oder privat, mit oder ohne Gewinnabsicht, sowie für jede Art von Projekt, unabhängig von seiner Komplexität, Größe, Kosten, Dauer oder Ansatz, einschließlich sowohl prädiktiver als auch iterativer und inkrementeller Ansätze oder beider gleichzeitig, d.h. der Agile Ansatz.

Wenn Sie ein kleines Projekt steuern, werden Sie den Standard in vereinfachter Form verwenden und nur einige der dort beschriebenen Praktiken anwenden.

Andererseits, wenn Sie eine Brücke bauen, werden Sie wahrscheinlich alle oder die meisten der in der Norm beschriebenen Praktiken befolgen. Projektmanager, die mit dem Standard vertraut sind, können ihren Managementprozess an die Bedürfnisse des jeweiligen Projektes anpassen. Es gibt ein altes Sprichwort: “Um die Regeln zu brechen, müssen Sie sie zuerst kennen”. Wenn Projektmanager sich die Zeit nehmen, die Regeln zu lernen, erkennen sie auch, welche Praktiken sie an die Bedürfnisse der Organisation und des spezifischen Projekts anpassen können.

Ein weiterer Vorteil der Verwendung eines anerkannten Standards für Ihr Projekt ist, dass er es ermöglicht, das standardisierte Vokabular der Disziplin zu verwenden, was das Verständnis für andere Beteiligte erleichtert.

Wie bei jedem anerkannten Standard ermöglicht es Unternehmen, die Praktiken in allen Abteilungen zu standardisieren. Das bedeutet, dass die Projekte in der Entwicklungsabteilung, ähnlich wie jene im Vertrieb gesteuert werden.

Es kann auch den Projektmanagern helfen, über ihre eigene Organisation hinaus zu kooperieren. Wenn Sie für Unternehmen A arbeiten und mit Unternehmen B und C kooperieren, zum Beispiel Ihre Lieferanten, können Sie besser zusammenarbeiten, wenn ähnliche Managementpraktiken angewendet werden.

Zusammenfassend können wir sagen, dass die Verwendung eines anerkannten Standards für Ihr Projekt, es Ihnen ermöglichen wird, bestehende Techniken und Erkenntnisse zu nutzen; ein gemeinsames Vokabular zu verwenden, das von Ihren Kollegen verstanden werden kann; und die Praktiken in verschiedenen Abteilungen Ihrer Organisation, oder sogar zwischen verschiedenen Organisationen oder Unternehmen, zu standardisieren.

 

0.2 Was ist ein Projekt?

Dieser Abschnitt wird Ihnen helfen zu verstehen, was ein Projekt ist und wie es sich von anderen Arten von Arbeit unterscheidet. Bevor wir darüber sprechen, wie man Projekte leitet, stellen wir sicher, dass wir das gleiche Verständnis davon haben, was ein Projekt ist. Hier ist eine Definition: Ein Projekt ist ein zeitlich begrenztes Unterfangen, um ein Ziel zu erreichen und hat in der Regel ein Budget. Aber was bedeutet das wirklich?

Lassen Sie uns den Aspekt der zeitlichen Begrenzung genauer betrachten. Im Gegensatz zur sogenannten operativen Arbeit hat ein Projekt einen klaren Anfang und ein Ende. Wenn ein Projekt zum Ziel hat, ein neues System zu implementieren, wird das Projekt abgeschlossen sein, wenn das System erfolgreich an die Menschen übergeben wird, die in der operativen Arbeit tätig sind. Warum scheinen einige Projekte kein Ende zu haben? Es könnte daran liegen, dass nicht klar definiert wurde, was erreicht werden soll.

Dies führt uns zum Projektziel. Ein Projekt liefert ein einzigartiges Ergebnis, das ein Produkt, einen Service, eine Fähigkeit oder ein anderes Ergebnis sein kann. Nehmen wir zum Beispiel eine Autowerkstatt, die ein neues Terminplanungssystem einführt. Viele Organisationen implementieren Terminplanungssysteme, aber jede hat ihre eigenen Probleme, Ziele, Zielsetzungen und Einschränkungen. Vielleicht hat die Werkstatt Probleme mit Personalmangel. Oder vielleicht besteht das Problem darin, die Planung von technischer Ausrüstung gleichzeitig mit qualifiziertem Personal und geeigneten Räumen zu koordinieren, da nur die Kombination dieser drei Elemente die ordnungsgemäße Reparatur der Fahrzeuge gewährleistet. Oder vielleicht ist der Grund für die Aktualisierung des Planungssystems die Verbesserung der wirtschaftlichen Ergebnisse oder des Serviceniveaus der Werkstatt.

Lassen Sie uns nun den Aspekt des Budgets betrachten. Normalerweise denkt man bei dem Wort “Budget” an Geld, was auch richtig ist. Aber Projekte haben auch andere Einschränkungen wie die Menge oder Art der verfügbaren Arbeitskräfte. Arbeit am Projekt ist nicht dasselbe wie operative Arbeit. Letztere bezieht sich auf Arbeit, die Tag für Tag ähnliche Ergebnisse produziert. Die Annahme von Fahrzeugen zur Reparatur in der Autowerkstatt ist operative Arbeit.

Es ist zwar wahr, dass die Kunden unterschiedliche Probleme mit ihren Fahrzeugen haben, aber die Mitarbeiter, die ihre Termine planen müssen, folgen einem bestimmten Standardverfahren und verwenden dieselben Formulare zur Aufnahme. Die Terminplanung für Fahrzeugreparaturen ist operative Arbeit.

Im Gegensatz dazu ist die Einführung eines neuen Terminplanungssystems für Fahrzeugreparaturen ein Projekt. Es hat einen klaren Anfang und endet, wenn das System die Ressourcen der Werkstatt plant. Es hat ein Ziel, nämlich die Probleme bei der Terminplanung in der Werkstatt zu lösen, und es hat ein Budget, sowohl in Geld als auch in anderen Ressourcen: Personal, Material und Zeit.

Im Laufe Ihres Lebens haben Sie wahrscheinlich an vielen Projekten gearbeitet, sowohl beruflich als auch privat. Erinnern Sie sich daran, dass ein Projekt ein zeitlich begrenztes Unterfangen ist, um ein Ziel zu erreichen und das in der Regel ein Budget hat. Verwenden Sie diese Merkmale und denken Sie über Themen nach, an denen Sie in den letzten Jahren gearbeitet haben.

 

 

 

 

0.3 Was ist Projektmanagement?

Dieser Abschnitt wird Ihnen helfen zu verstehen, was Projektmanagement ist.

Viele Projektmanager werden ausgewählt, weil sie Experten in Bezug auf das Produkt sind, das erstellt werden soll. Aber Projektmanagement erfordert mehr als nur technische Fähigkeiten in der jeweiligen Branche. Es bedeutet, Wissen, Fähigkeiten, Werkzeuge und Techniken einzusetzen, um die Ziele des Projekts zu definieren und zu erreichen. Projektmanagement kann in einfacher Form verstanden werden, indem wir einige grundlegende Fragen beantworten.

Die erste Frage, die wir beantworten müssen, lautet: Welches Problem möchten wir lösen? Eine klare Definition dessen, was das Projekt erreichen soll, ist ein großer Schritt zum Erfolg. Wenn wir nicht wissen, wohin wir gehen, werden wir die Kosten tragen und Zeit verschwenden, um irgendwo anzukommen, aber es ist möglicherweise nicht der richtige Ort, an dem wir sein sollten.

Die zweite Frage ist: Wie werden wir dieses Problem lösen? Ob wir ein Problem lösen oder eine Geschäftsmöglichkeit nutzen möchten, wir müssen möglicherweise zwischen verschiedenen Strategien wählen.

Sobald wir eine Strategie ausgewählt haben, ist es an der Zeit, die Lösung zu entwickeln, die dieser Strategie zugrunde liegt, indem wir Anforderungen sammeln, Lieferobjekte identifizieren und den Umfang des Projekts festlegen.

Die nächste Frage lautet: Was ist der Plan? Ein wichtiger Teil des Projektmanagements befasst sich mit Planungsaktivitäten. Wir müssen die auszuführende Arbeit identifizieren. Wie lange wird es dauern, welche Art und Menge an Ressourcen werden benötigt und wie viel wird es kosten? Mit diesen Informationen können wir einen Zeitplan für die Durchführung der verschiedenen Arbeitspakete erstellen und ein Budget erstellen. Es muss auch festgelegt werden, wie bestimmte Dinge gehandhabt werden, wie beispielsweise Kommunikation, Änderungen, Risiken, Probleme, Einbindung der Stakeholder und Beschaffungen.

Einige Projekte scheinen endlos zu dauern, aber irgendwann wird jemand den Stecker ziehen, der die Ressourcen bereitstellt. Deshalb müssen wir auch die Frage beantworten: Wie wissen wir, dass wir fertig sind?

Klar festgelegte Ziele, Anforderungen und Ergebnisse können dabei helfen, diese Frage zu beantworten. Aber um die Unsicherheit weiter zu reduzieren, kann man Erfolgskriterien festlegen, die konkrete und messbare Ergebnisse definieren. Diese Kriterien legen die notwendigen Bedingungen fest, um das Projekt als abgeschlossen und zufriedenstellend zu betrachten. Zum Beispiel gesteigerte Produktivitätsmessungen nach der Implementierung eines Systems.

Am Ende des Projekts, wenn alles abgeschlossen ist, ist es Zeit, die letzte Frage zu stellen: Wie gut lief es? Dieser entscheidende Schritt wird oft übersehen, da alle eilig zur nächsten Aufgabe übergehen wollen. Dennoch ist es wichtig, sich etwas Zeit zu nehmen, um zu reflektieren, was in jeder Phase gelernt wurde. Was hat gut funktioniert, was nicht, und warum? Gibt es Möglichkeiten, es beim nächsten Mal besser zu machen?

Zusammengefasst geht es beim Projektmanagement darum, verschiedene Fragen zu klären, wie zum Beispiel: Was ist das Problem, das wir lösen möchten? Wie werden wir es lösen? Was ist unser Plan, um das Projekt umzusetzen? Wie führen wir es durch? Wie erkennen wir, dass es abgeschlossen ist? Und wie erfolgreich waren wir dabei?

 

 

 

 

0.4 Die organisatorische Umgebung von Projekten

Dieser Abschnitt wird Ihnen helfen zu verstehen, wie verschiedene Arten von Organisationsumgebungen Projekte beeinflussen.

Wie bei jedem Unterfangen muss ein Projekt klären, wer an wen berichtet und welches Maß an Autorität der Projektleiter hat. Es gibt drei verschiedene Modelle:

• Die klassische funktionale Organisation, bei der jede Person, die an einem Projekt beteiligt ist, an ihren funktionalen Vorgesetzten berichtet.
• Die Matrixorganisation, die die hierarchische Beziehung jedes Beteiligten im Projekt sowohl zum jeweiligen funktionalen Vorgesetzten als auch zum Projektleiter kombiniert.
• Schließlich die projektorientierte Organisation, bei der die Beteiligten ausschließlich an den Projektleiter berichten.

 

Natürlich hat jede dieser Arten der Hierarchiegestaltung unterschiedliche Auswirkungen auf die Art und Weise, wie Projekte durchgeführt werden.

Ein Projekt gilt als funktional organisiert, wenn die ausführende Einheit die übliche hierarchische Struktur für operative Arbeit auch für die Arbeiten im betreffenden Projekt verwendet. In diesem Fall gibt es tatsächlich keinen Projektleiter, zumindest nicht getrennt vom funktionalen Manager. Projekte werden von funktionalen Managern geleitet, die die Hierarchievorgesetzten ihrer funktionalen Untergebenen sind. Diese Art der Organisation funktioniert gut für Projekte, die nur eine funktionale Abteilung betreffen. Der funktionale Vorgesetzte hat ein hohes Maß an Kontrolle über die Arbeit der Teammitglieder im Projekt, da es sich um seine funktionalen Untergebenen handelt, die wiederum daran gewöhnt sind, an diesen Vorgesetzten zu berichten. Der Projektleiter und der Abteilungsleiter sind dieselbe Person. Das Kommunikations- und Berichtssystem ist üblich. Der Hauptnachteil ergibt sich aus der querschnittlichen Natur vieler Projekte, die in der Regel mehrere Abteilungen in einer Organisation betreffen. In solchen Fällen neigt die funktionale Organisation dazu, langsam zu sein. Darüber hinaus kann die Verfügbarkeit spezieller Ressourcen zu einem Problem werden. Aufgrund ihrer Natur ist jede Abteilung auf bestimmte Arten von funktionaler Arbeit spezialisiert, und andere Arten von Ressourcen, die für die einzigartige Arbeit eines Projekts erforderlich sind, stehen möglicherweise nicht zur Verfügung.

Der zweite Typ der Arbeitsorganisation eines Projekts, die Matrixorganisation, bleibt in ihrer Grundlage eine funktionale Hierarchie, unterstützt jedoch eher die Durchführung von Projekten als die rein funktionalen Hierarchien. Diese Matrixorganisationen werden oft als schwach, ausgewogen oder stark eingestuft, je nachdem, wie stark sie den Projekten den Schwerpunkt geben. In einer Matrixorganisation haben Projektleiter bestimmte Befugnisse zur Entscheidungsfindung im Zusammenhang mit dem Projekt, insbesondere in einer starken Matrixorganisation. Aber die den Projekten zugewiesenen Mitarbeiter berichten an zwei Manager, den funktionalen Manager und den Projektleiter. Diese Art der Organisation eignet sich gut zur Koordinierung von Projektarbeit, die mehrere Abteilungen betrifft und eine bestimmte Größenordnung nicht überschreitet, was es bestimmten Ressourcen ermöglicht, sowohl teilzeitlich am Projekt als auch teilzeitlich an ihrer üblichen operativen Arbeit zu arbeiten. Die Hauptherausforderung der Matrixorganisation besteht in der Existenz von zwei Vorgesetzten, an die gleichzeitig berichtet werden muss, und in möglichen Prioritätskonflikten zwischen den funktionalen Managern und dem Projektleiter.

Daher ist es unerlässlich, dass Projektleiter, die in Matrixumgebungen arbeiten, über gute Verhandlungsfähigkeiten verfügen, um diese potenziell konfliktträchtige Situation angemessen zu bewältigen.

Wir sprechen von projektorientierten Organisationen, wenn die gesamte Arbeit im Zusammenhang mit Projekten steht. Die Teammitglieder berichten ausschließlich an den Projektleiter und arbeiten Vollzeit an diesem Projekt. Projektleiter haben ein hohes Maß an Autorität und Verantwortung für ihre Projekte, einschließlich der Budgetverantwortung. Die Hauptherausforderung besteht darin, wie mit den Teammitgliedern umzugehen ist, wenn das Projekt abgeschlossen ist, da sie in der Regel Vollzeit an dem Projekt gearbeitet haben und in der funktionalen Organisation oft kein freier Arbeitsplatz zur Verfügung steht, zu dem sie zurückkehren können.

Es sei daran erinnert, dass diese drei Arten von Organisationen nur Modelle sind. In der realen Welt finden wir oft hybride Situationen, bei denen einige Projekte innerhalb einer Abteilung nach funktionaler Organisation durchgeführt werden. Andere mittelgroße Projekte, die querschnittlich mehrere Abteilungen betreffen, werden mit einer Matrixorganisation organisiert. Und schließlich gibt es größere strategische Initiativen, ausgestattet mit Vollzeitressourcen, die mit einer projektorientierten Organisation geleitet werden. Die Kombination dieser drei Arten von Organisation kann auch innerhalb eines einzigen Großprojekts auftreten, das Vollzeit- und Teilzeitressourcen sowie die Einbindung von externen Lieferanten verwendet.

Zusammenfassend: Die organisatorische Umgebung, in der ein Projekt eingebettet ist, kann konzeptuell als funktional, matrixartig oder projektorientiert betrachtet werden. In der realen Welt sind oft hybride Situationen anzutreffen. Die Organisationsstruktur hat einen erheblichen Einfluss darauf, wie Projekte durchgeführt werden, wie viel Autorität der Projektleiter hat und wie erfolgreich das Projekt sein kann.

 

 

 

 

 

0.5 Die kulturelle Umgebung von Projekten

Dieser Abschnitt wird Ihnen helfen, zu verstehen, wie verschiedene Aspekte der Organisationskultur Projekte beeinflussen.

Die Organisationskultur ist eine Reihe von Faktoren, die das Verhalten und die Entscheidungen der Menschen innerhalb einer Organisation lenken. Es handelt sich um immaterielle Dinge wie geteilte Werte, Überzeugungen, Annahmen, Gewohnheiten und die Sprache. Sprechen wir darüber, wie die Organisationskultur Projekte beeinflusst.

Die Mission und Vision der Organisation prägen die Kultur der Organisation. Projekte, die die Mission des Unternehmens unterstützen, erhalten wahrscheinlich mehr Aufmerksamkeit und Ressourcen. Wenn Sie während eines Projekts vor einer komplizierten Entscheidung stehen, kann die Konsultation der Mission und Vision der Organisation eine gute allgemeine Richtlinie sein, um die beste Vorgehensweise zu bestimmen.

Der Führungsstil und wie die Autorität ausgeübt wird, sind ebenfalls ein wichtiger Teil der Organisationskultur. Wenn die Führung regelmäßig klare Ziele setzt und dann die Verantwortung für die Umsetzung an die Mitarbeiter delegiert, wird dieser Ansatz auch in Ihren Projekten funktionieren. Aber wenn normalerweise wenig Autorität delegiert wird, wird diese Gewohnheit der funktionalen Organisation auf die Projekte übertragen, und Sie müssen sich gleichzeitig daran anpassen und versuchen, Vertrauen aufzubauen.

Ein weiterer Aspekt der Kultur ist die Arbeitsumgebung in der Organisation. Wenn die Atmosphäre positiv ist, werden die Menschen motiviert sein, Dinge zu tun. Das Sammeln von gewonnenen Erkenntnissen wird auch einfacher sein, da die Mitarbeiter daran gewöhnt sind, frei ihre Meinungen einzubringen und sich für Verbesserungen einzusetzen. In einer negativen Umgebung müssen Sie wahrscheinlich viel Zeit auf das Management Ihres Teams verwenden.

Einige Kulturen legen großen Wert darauf, Regeln um jeden Preis einzuhalten, während andere auf Innovation setzen und erwarten, dass Mitarbeiter neue Ansätze ausprobieren, etablierte Vorgehensweisen in Frage stellen und verbesserte Methoden vorschlagen. Es ist nicht notwendig, in einer regelbasierten Kultur alle Regeln zu befolgen, aber wenn Sie daran denken, Regeln zu brechen, ist es wichtig zu wissen, welche Regeln Sie brechen können. Und vergessen Sie nicht zu überlegen, was Sie tun werden, wenn Ihr nicht standardmäßiger Ansatz nicht funktioniert. Stellt Ihre Organisation Ergebnisse über Verfahren oder umgekehrt? Das bedeutet, ist es besser, die Regeln zu befolgen, auch wenn das Ziel nicht erreicht wird, oder können Sie alles tun, was erforderlich ist, solange Sie die gewünschten Ergebnisse liefern? Natürlich muss jedes Projekt sein Oberziel erreichen, indem es seine Unterziele erreicht. Aber es ist wichtig zu wissen, welche Grenzen einzuhalten sind, um Dinge geschehen zu lassen.

Das Change-Management kann von der Organisationskultur beeinflusst werden. Wenn die Organisation risikoavers ist, kann das Change-Management zahlreiche Überprüfungsrunden und die Zustimmung vieler Personen erfordern. Andererseits, wenn Veränderungen im Bereich der Projekte als etwas Natürliches angesehen werden, kann das Change-Management einfacher und weniger traumatisch sein.

Bei Personen, die an verschiedenen Standorten arbeiten, sei es im eigenen Land oder sogar in anderen Ländern weltweit, müssen auch die kulturellen Unterschiede berücksichtigt werden. Menschen neigen dazu, in verschiedenen Kulturen sehr unterschiedlich zu kommunizieren und zu reagieren, selbst in denselben Situationen, je nach den Normen ihrer jeweiligen Kulturen. Zum Beispiel wird Menschen in einigen Kulturen beigebracht, keine Schwächen zu zeigen, und dieses Verhalten kann von Menschen aus anderen Kulturen als arrogant interpretiert werden. Und umgekehrt. Ein Leader, der seine Fehler anerkennt und offen über einige seiner Schwächen spricht, kann in bestimmten Kulturen als “sehr zugänglich” oder “sehr menschlich” angesehen werden, aber in anderen als “schwach”.

Zusammenfassend sei daran erinnert, dass die Kultur einen enormen Einfluss darauf hat, wie die Dinge in einem Projekt ablaufen und wie Entscheidungen getroffen werden. Um unsere Erfolgschancen zu erhöhen, sollten wir den kulturellen Faktoren große Aufmerksamkeit schenken.

 

 

0.6 Die Rolle des Projektmanagers

In diesem Abschnitt erfahren Sie, was einen erfolgreichen Projektmanager ausmacht.

Projektmanager gelten gemeinhin als strukturierte Persönlichkeiten mit dem nötigen Antrieb, Aufgaben zu bewältigen. Doch für den erfolgreichen Abschluss von Projekten bedarf es eines umfangreicheren Wissens und einer Vielzahl an Fähigkeiten und Kompetenzen.

Im Bereich des Projektmanagements sind natürlich spezielle technische Fähigkeiten erforderlich. Dazu gehören das Anfertigen und Anpassen von Zeitplänen, die Erstellung und Kontrolle von Geldbudgets, das Entwickeln von Projektstrukturplänen, die Anwendung des kritischen Pfads, die Leistungsmessung und vieles mehr.

Um Ihrem Projekt einen echten Mehrwert zu verleihen, genügt es nicht, nur Ihr Unternehmen zu kennen. Ein tiefgehendes Verständnis für die gesamte Branche ist ebenso essentiell. Es ist von Bedeutung, das Geschäftsfeld Ihrer Organisation zu verstehen, die zentralen Themen zu identifizieren und zu begreifen, was als besonders wichtig erachtet wird. Nur mit diesem Wissen können Sie Entscheidungen treffen, die gewährleisten, dass Ihr Projekt optimal in diesen Rahmen passt – ein entscheidender Faktor für den Projekterfolg.

Die Fähigkeit zur Problemlösung ist von entscheidender Bedeutung. Oftmals entwickeln sich Projekte anders als ursprünglich geplant. Für einen Projektmanager ist es daher zentral, kreative Lösungen zu finden, um die Projektziele zu realisieren. Dabei gilt es, Zeit und Budget stets im Auge zu behalten und gleichzeitig aufkommende Herausforderungen zu meistern.

Zweifellos zählen zwischenmenschliche Kompetenzen zu den Kernfähigkeiten eines Projektmanagers. Projekte vereinen oft Menschen aus unterschiedlichen Bereichen – sei es aus verschiedenen Abteilungen eines Unternehmens oder sogar aus unterschiedlichen Firmen. Es liegt am Projektmanager, zum Anführer dieser speziell für das Projekt zusammengestellten Gruppe zu werden. Diese Führungsqualität entwickelt sich nicht von selbst, ist jedoch unverzichtbar. Denn aus dieser vielfältigen Gruppe muss ein echtes Team geformt werden, um den Projekterfolg zu gewährleisten. Und genau diese Aufgabe, ein Team aus verschiedenen Akteuren zu formen, obliegt dem Projektmanager.

Somit gehört die Führungsfähigkeit zu den prägenden Merkmalen eines erfolgreichen Projektmanagers. Er hat die Aufgabe, sein Team zu inspirieren, beim Aufbau eines starken Teams zu unterstützen, zu leiten, zur Verantwortung zu ermutigen und zu motivieren – alles mit dem Ziel, das Beste aus jedem Einzelnen und dem gesamten Team herauszuholen.

In Anbetracht dessen sollten Sie sich fragen: Ist Projektmanagement etwas, das Sie reizt? Wenn Sie von der Idee begeistert sind, Projekte zu leiten und möglicherweise sogar andere Projektmanager zu führen, könnte dies ein prägender Abschnitt Ihrer beruflichen Laufbahn werden.

 

 

 

 

0.7 Softwareoptionen für das Projektmanagement

In diesem Abschnitt geben wir einen kurzen Überblick über verschiedene Softwareoptionen, die im Projektmanagement hilfreich sind – von einfachen bis zu fortgeschrittenen Lösungen.

Zu den Basiswerkzeugen gehört ein Softwarepaket, das Textverarbeitung, Kalkulationen, Präsentationserstellung und E-Mail-Kommunikation ermöglicht. Solche Funktionen sind in vielen Bürojobs Standard und somit auch im Projektmanagement unerlässlich. Ein gängiges Beispiel hierfür ist Microsoft Office oder die Open-Source-Alternative Open Office.

Oftmals ist eine spezialisierte Software erforderlich, um Projektzeitpläne effizient zu erstellen und zu verwalten. Während man mit einer Tabellenkalkulation ein Gantt-Diagramm erstellen kann, benötigt man für komplexere Aufgaben, wie das Verknüpfen von Aktivitäten oder das Darstellen von Verzögerungseffekten, spezialisierte Tools. Hierzu zählen Programme wie Microsoft Project, Oracle Primavera, Monday, Smartsheet und andere. Viele dieser Lösungen sind cloudbasiert, was die Teamarbeit erheblich erleichtert.

Für Teams, die eng zusammenarbeiten, sind Collaboration-Tools unverzichtbar. Microsoft Teams, Basecamp, Asana und Wrike sind Beispiele für cloudbasierte Tools, die Chats, Dateifreigabe, Aufgabenmanagement und gemeinsame Kalender bieten. Besonders hervorzuheben ist Microsoft Teams mit seinen Videokonferenzfunktionen und einer Vielzahl an Zusatzanwendungen. Es ist zudem Teil des weit verbreiteten Office 365-Pakets.

Für Organisationen, die viele umfangreiche Projekte parallel durchführen, sind umfassendere Softwarelösungen für das Management von Projekten, Programmen und Portfolios empfehlenswert.

Diese Art von Werkzeugen ermöglicht es, verfügbare Ressourcen mit den erforderlichen Fähigkeiten in großen Organisationen zu erkennen, in denen nicht alle potenziell verfügbaren Ressourcen dem Projektmanager bekannt sind. Sie ermöglichen es, eine Initiative von ihrer Entstehung als Business Case bis zu ihrem Abschluss mit dem Nutzenmanagement zu verwalten, wobei einzelne Projekte als Komponenten von größeren Aggregaten wie Programmen und Portfolios betrachtet werden. Ihre Implementierung ist oft eine mühsame und manchmal schmerzhafte Arbeit und erfordert eine erhebliche Investition. Bekannte Beispiele hierfür sind Microsoft Portfolio Management, Primavera Enterprise, Clarity, Planview und andere.

Abschließend sei erwähnt, dass bei der Softwareauswahl nicht nur die Funktionen im Vordergrund stehen sollten. Auch Unternehmenskultur, Arbeitsumfeld, Budget und die Anzahl und Komplexität der Projekte spielen eine entscheidende Rolle. Ebenso sind der Aufwand und die Zeit, die für die Einführung des Tools benötigt werden, wichtige Faktoren bei der Entscheidungsfindung.

 

 

 

1.0 Warum ein Projekt?

In diesem Abschnitt betrachten wir, wie das Veränderungsbedürfnis Projekte vorantreibt.

Um zu überleben und Erfolg zu haben, müssen Organisationen zwei konkurrierende Imperative gleichzeitig ausbalancieren.

Das erste Imperativ ist, den laufenden Geschäftsbetrieb fortzuführen, denn hier fließt das Geld. Durch Produktion und Verkauf bestehender Produkte und Dienstleistungen an aktuelle Kunden generiert die Organisation Wert und sichert die notwendigen Einnahmen, um im Geschäft zu bleiben.

In einem konkurrenzstarken Markt reicht es nicht aus, immer wieder die gleichen Produkte an die gleichen Kunden zu verkaufen und sie stets auf die gleiche Weise zu produzieren. Wenn wir uns nicht weiterentwickeln, werden Wettbewerber an uns vorbeiziehen.

Deshalb besteht das zweite Imperativ darin, den laufenden Betrieb kontinuierlich zu verändern und die Wertschöpfungsfähigkeiten zu steigern, um langfristig wettbewerbsfähig zu bleiben.

Wie erreichen wir das? Projekte sind das traditionelle Werkzeug, um die Elemente und Bedingungen zu schaffen, die diese notwendigen Veränderungen herbeiführen.

• Veränderungen sind nötig, um aktuelle oder zukünftige Herausforderungen zu bewältigen, wie die Optimierung von Produktionsverfahren, Kosteneinsparungen oder die Steigerung der Servicequalität.
• Manchmal sind Anpassungen erforderlich, um Geschäftschancen zu ergreifen und zu wachsen, etwa durch das Betreten neuer geografischer Märkte oder anderer Marktsegmente.
• Es gibt auch Fälle, in denen Veränderungen aufgrund neuer gesetzlicher Vorgaben unumgänglich sind, unabhängig davon, ob sie uns gefallen, wie eine neue Arbeitsrichtlinie oder Umweltauflagen.

Unabhängig vom Auslöser für den Veränderungsbedarf, um eine Organisation vom jetzigen zum gewünschten Zustand zu führen, brauchen wir Neuerungen wie Prozesse, Fähigkeiten, Dienstleistungen, Produkte oder sogar Aspekte wie Einstellungen, Überzeugungen und Verhaltensweisen.

Um diese speziellen Elemente für die Veränderung zu schaffen, initiieren wir temporäre Strukturen, die als Projekte bezeichnet werden. Sie sind temporär, denn sobald das angestrebte Ergebnis oder Produkt an die Organisation geliefert wurde, endet das Projekt und seine Mitglieder widmen sich anderen Aufgaben.

Ein Business Case legt die Begründung für ein Projekt dar. Er versorgt die Unternehmensleitung mit allen essenziellen Informationen, um zu entscheiden, ob ein Projekt realisierbar, sinnvoll und erreichbar ist. Auf dieser Grundlage wird über eine Investition entschieden. Eine tiefergehende Analyse des Business Case wird in einer künftigen Lektion behandelt.

Zusammenfassend:

• Wir führen Projekte durch, um Probleme zu lösen, Geschäftsmöglichkeiten zu nutzen oder verpflichtende Vorschriften einzuhalten.
• Projekte sind die Vehikel des Wandels.
• Projekte erstellen Lieferobjekte, die sich von den Ergebnissen der regulären Organisation unterscheiden. Daher benötigen wir spezielle, temporäre Einheiten namens Projekte, die nach Erfüllung ihrer Aufgabe enden.

Ein Business Case ist ein Dokument, das der Organisationsleitung die nötigen Informationen bietet, um über eine Projektinvestition zu entscheiden.

 

 

 

1.2 Projektselektion 1: Überblick über das Portfoliomanagement

Dieser Abschnitt hilft Ihnen zu erkennen, wie die Wahl eines Projekts in den größeren Rahmen des Portfoliomanagements passt und wie es mit der Strategie einer Organisation in Verbindung steht.

Beginnen wir mit der Klärung: Was ist ein Projekt- und Programmportfolio?

Manche sehen ein Projektportfolio schlichtweg als die von der Organisation bestätigten Projekte und Programme. Nehmen wir an, alle IT-Projekte und -Programme eines Jahres. Das trifft zwar zu, greift aber zu kurz.

Ein Projekt- und Programmportfolio sollte nicht willkürlich zusammengestellt sein. Es hat das Potenzial, das Hauptinstrument zu sein, mit dem eine Organisation ihre strategischen Oberziele erreicht.

Nehmen wir an, die IT-Abteilung hat dieses Jahr das Ziel, Kosten zu reduzieren, die Sicherheit zu verstärken und Systemausfälle zu minimieren. In diesem Fall sollten die IT-Leiter ein Portfolio von Projekten und Programmen erstellen, das genau diese Oberziele umsetzen kann.

Die Strategie der Organisation mit den Projekten verbinden.

Organisationen erfüllen ihre Oberziele, indem sie ihre täglichen Geschäftsabläufe sinnvoll mit verändernden Aktivitäten verknüpfen.

Für ein effektives Portfolio, das die nötigen Veränderungen für die Erreichung der Organisationsziele sicherstellt und das im richtigen Takt mit den täglichen Abläufen synchronisiert ist, müssen potenzielle Projekte und Programme sorgfältig ausgewählt werden.

In diesem Auswahlverfahren erhalten einige Projekte grünes Licht, andere werden zurückgestellt oder sogar gestrichen. Der Grund dafür ist klar: Es gibt stets mehr zu tun, als man bewältigen kann. Daher ist es entscheidend, Prioritäten zu setzen.

Zudem sollte das Portfolio regelmäßig ins Auge gefasst werden. Wenn ein Projekt nicht wie geplant verläuft, kann es gestoppt und aus dem Portfolio genommen werden. Die dafür vorgesehenen Ressourcen könnten dann anderen Projekten zugewiesen oder für neue Vorhaben verwendet werden. Dies passt das Portfolio an die Unternehmensziele an.

Es wird also deutlich, dass das Management von Projekt- und Programmportfolios aktiv und kontinuierlich sein muss. Es bedarf regelmäßiger Überprüfungen und Anpassungen, um sicherzustellen, dass die enthaltenen Projekte wirklich die Unternehmensziele unterstützen.

Wie viele Projekt- und Programmportfolios gibt es in einer Organisation?

Ein Unternehmen verändert ständig verschiedene Facetten seiner Prozesse durch Projekte. Einige dieser Projekte unterstützen die übergeordneten Oberziele der Organisation und gehören zum sogenannten strategischen Portfolio.

Doch nicht nur das gesamte Unternehmen hat Oberziele. Jede Abteilung verfolgt eigene Oberziele und Vorgaben. Denn jede Abteilung oder jeder Bereich ist im Grunde eine eigene Organisation, auch wenn sie Teil eines größeren Ganzen, des Unternehmens, ist. Daher gibt es auch Projekte, die speziell auf die Oberziele einer Abteilung abzielen und innerhalb dieser Abteilung eigenständig verwaltet werden.

Ein Unternehmen hat daher oft mehrere Projektportfolios. Zum Beispiel ein IT-Portfolio, das die IT-Oberziele unterstützt, ein Marketing-Portfolio für Marketing-Aktivitäten und so weiter.

Jede Abteilung stellt Ressourcen für die Projekte des strategischen Portfolios bereit, die das gesamte Unternehmen betreffen – meist als höchste Priorität. Gleichzeitig führt sie ihr eigenes Portfolio mit den verbleibenden Ressourcen aus. Und das alles, während der normale Betrieb weiterläuft, der der nötige Geldfluss generiert.

Wie man sieht, wird es schnell komplex, und Ressourcenkonflikte sind vorprogrammiert. Daher ist es hilfreich, eine Instanz zu haben, die der Geschäftsleitung bei der Portfolioverwaltung unterstützt.

Kurz gesagt: Ein effizientes Management von Projektportfolios ist entscheidend, um die Unternehmensstrategie mit der tatsächlichen Umsetzung durch eine ausgewogene Mischung aus operativen Aktivitäten, Projekten und Programmen zu verbinden. Oberziel ist es, sicherzustellen, dass das Unternehmen die richtigen Aufgaben zur richtigen Zeit und auf die richtige Art und Weise erledigt, um die gesetzten Oberziele zu erreichen.

Komponenten des Managements eines Projekt- und Programmportfolios.

Das Management von Projekt- und Programmportfolios ist ein facettenreicher unternehmerischer Ansatz, der aus sieben Schlüsselkomponenten besteht:

Die erste Komponente ist die Ideen-Generierung und -Erfassung: Hier werden Vorschläge für potenzielle Projekte gesammelt, die von verschiedenen Unternehmensbereichen als relevant angesehen werden. Es geht darum, Ideen aus der gesamten Organisation zu sammeln und die vielversprechendsten für eine genauere Betrachtung herauszufiltern.

Die zweite Komponente ist die Erstellung von Business Cases: Für die in der ersten Phase ausgewählten Vorschläge werden Business Cases erstellt. Dies ermöglicht eine tiefere Analyse und Vergleichbarkeit der Vorschläge, basierend auf groben Kostenschätzungen und erwarteten Nutzen.

Die dritte Komponente ist die Bewertung und Modellierung von Fähigkeiten: Hier werden die Projekte hinsichtlich ihrer Durchführbarkeit bewertet. Es wird geprüft, ob die notwendigen Ressourcen und Fähigkeiten vorhanden sind oder beschafft werden können. Denn es ist eine Tatsache, dass die Organisation über eine bestimmte Anzahl von Mitarbeitern und anderen Ressourcen verfügt und dass die laufenden Geschäftstätigkeiten nicht eingestellt werden können.

Die vierte Komponente ist die Auswahl und Priorisierung: Die Ergebnisse der ersten drei Stufen werden in dieser Phase genutzt. Andere Faktoren helfen, ein harmonisches Portfolio zu erstellen. Es gibt viele Auswahlkriterien. Einige beziehen sich auf das Risiko jeder Aktion. Andere auf positive und negative Geldströme und deren Entstehungszeitpunkt. Eine Firma hat oft eigene Kriterien für ihre Entscheidungen. Manchmal werden profitable Projekte zurückgestellt. Andere Projekte könnten bevorzugt werden, weil sie einfacher oder weniger riskant sind. Die Auswahl basiert auf bestimmten Kriterien. Das Hauptziel ist ein ausgewogenes Portfolio und ein klarer Auswahlprozess. So entstehen keine Konflikte zwischen den Abteilungen mit unterschiedlichen Oberzielen.

Die fünfte Komponente betrifft die Strategieumsetzung. Hierbei werden Projekte und Programme im Portfolio durchgeführt. Das alles geschieht neben dem normalen Geschäftsbetrieb. In einem Projektmanagementkurs wird dieser Portfolio-Teil genau behandelt. Dort lernt man die besten Methoden, um Projekte zu leiten.

Es ist wichtig zu wissen, dass ein Projekt im Portfolio nicht fest steht. Prioritäten können sich von heute auf morgen ändern. Auch können Projekte anders laufen als gedacht. Wenn ein Projekt anders verläuft als geplant, kann es neu geplant werden müssen. Zum Beispiel: Ein Projekt sollte eine Million kosten und 15 Monate dauern. Wenn es sich später herausstellt, dass es zwei Millionen kostet und 30 Monate dauert, könnte es im Portfolio geändert oder entfernt werden.

Die sechste Komponente ist das Change Management. Es zieht sich durch den ganzen Portfolio-Management-Zyklus. Change Management ist kompliziert, besonders weil es menschliches Verhalten betrifft. Es schaut sich an, was Veränderungen unterstützt oder behindert. Das können Dinge wie Kultur, Werte und Stil sein. Je nachdem, welches Change-Management-Modell man nimmt, gibt es verschiedene Elemente. Dazu gehören die Bereitschaft zur Veränderung, wie gut Ergebnisse angenommen werden, und ob Nutzen erzielt werden. Auf Organisationsebene geht es darum, Hindernisse für den Wandel zu finden und zu entfernen. Gleichzeitig will man Dinge fördern, die den Wandel unterstützen. Das macht man durch Kommunikation und Beratung. So kann man den Wandel gut gestalten und die Unterstützung von allen Beteiligten bekommen.

Die siebte Komponente befasst sich mit Nutzenrealisierung und Abweichungsmanagement: Hier wird überprüft, ob die erwarteten Nutzen tatsächlich erzielt wurden. Bei Abweichungen wird Feedback in den Portfolio-Management-Zyklus zurückgespeist, um Lücken zu schließen.

Zusammengefasst ist das Management von Projekt- und Programmportfolios ein dynamischer Prozess, der darauf abzielt, die Unternehmensstrategie effektiv umzusetzen und dabei stets die aktuellen Bedürfnisse und Ressourcen des Unternehmens im Blick zu behalten.

Lieferobjekte, Ergebnisse, Nutzenrealisierung und Oberziele. Drei integrierte Perspektiven im Management von Portfolios, Programmen und Projekten.

Wenn ein Unternehmen ein neues Produkt oder System auf den Markt bringt, steht nicht das Produkt selbst im Vordergrund, sondern die Vorteile, die es mit sich bringt. Ein neues Produkt kann beispielsweise dazu beitragen, den Umsatz zu steigern, neue Kunden zu gewinnen und auf einem Markt präsent zu sein. Das Endziel ist jedoch die Steigerung von Einnahmen und Gewinn. Aber “Steigerung des Unternehmensgewinns” als solches ist oft zu weit gefasst für ein einzelnes Projekt oder Programm.

Die Lösung? Ein integrierter Ansatz, der Projekte, Programme und Portfolios miteinander verknüpft.

Projekte liefern konkrete Produkte. Wenn man jedoch die Generierung von Ergebnissen in den Projektumfang aufnimmt, muss man sicherstellen, dass am Ende des Projekts eine Überprüfung der erzielten Ergebnisse durch die Nutzung des Produkts erfolgt.

In jüngerer Zeit hat die Projektmanagement-Disziplin den Fokus auf die Ergebnisse gelegt, die durch das gelieferte Produkt erzielt werden sollen. Ein neues System könnte beispielsweise darauf abzielen, die Anzahl der Transaktionen pro Arbeitsstunde zu erhöhen.

Durch diesen integrierten Ansatz wird sichergestellt, dass die Projekte nicht nur Produkte liefern, sondern auch die gewünschten Ergebnisse erzielen, die letztlich zur Erreichung der übergeordneten Unternehmensziele beitragen.

Programme bieten einen umfassenden Ansatz, der über einzelne Projekte hinausgeht. Sie kombinieren verschiedene Projekte und betriebliche Tätigkeiten, um gemeinsame Nutzen zu erzielen.

Nehmen wir das Beispiel der Erhöhung der Transaktionsanzahl pro Stunde. Ein neues System allein reicht möglicherweise nicht aus, um die Kundenzufriedenheit zu steigern. Es sind zusätzliche Maßnahmen erforderlich, um dieses Oberziel zu erreichen.

Logistische Anpassungen könnten notwendig sein, um den Anstieg der Transaktionen zu bewältigen. Dies könnte die Optimierung von Lagerbeständen oder Lieferketten beinhalten. Ein Marketingprojekt könnte helfen, die Vorteile des neuen Systems zu kommunizieren. Es könnte Kunden darüber informieren, dass sie nun schneller bedient werden, was ihre Zufriedenheit erhöht.

Zudem müssen betriebliche Aktivitäten angepasst werden, um das neue System zu integrieren. Dies könnte Schulungen für Mitarbeiter oder die Anpassung von Geschäftsprozessen beinhalten.

Das Programmmanagement stellt sicher, dass alle diese Elemente koordiniert werden. So wird gewährleistet, dass sie zusammenarbeiten und die gewünschten Vorteile erzielen. Es geht nicht nur darum, Projekte zu managen, sondern auch darum, sicherzustellen, dass die Ergebnisse dieser Projekte effektiv in den betrieblichen Alltag integriert werden.

Das Portfolio-Management geht über einzelne Projekte hinaus. Es zielt darauf ab, die großen Oberziele der Organisation zu erreichen. Wenn alles gut läuft, spiegeln diese Oberziele die positiven Auswirkungen der erzielten Vorteile wider. Nehmen wir ein Beispiel: Wenn die Kundenzufriedenheit steigt, erwartet das Unternehmen, dass bestehende Kunden mehr kaufen und neue Kunden hinzukommen. Das Ergebnis? Ein besseres wirtschaftliches Ergebnis für das Unternehmen. Das Portfolio-Management sorgt dafür, dass alles, was die Programme tun, genau darauf ausgerichtet ist.

Ein ambitioniertes Ziel, wie die Erhöhung des ROI von 18% auf 21%, kann nicht allein durch ein Programm erreicht werden, wie das in unserem Beispiel. Um solch ein Oberziel zu erreichen, braucht es mehrere Programme, die verschiedene Bereiche abdecken. Das kann bedeuten, Lieferanten zu wechseln, das Unternehmen umzustrukturieren oder Produktionsmethoden zu ändern. Jede dieser Initiativen kann dazu beitragen, die Rentabilität des Unternehmens zu steigern, besonders wenn das eines der Hauptziele der Organisation ist.

Das Management von Projekt- und Programmportfolios bietet einen ganzheitlichen Blick auf die Organisation. Es geht über das einfache Leiten eines Projekts oder eines Programms hinaus. Es verbindet Projekte, Programme und Portfolios miteinander und betrachtet sie als ein zusammenhängendes Ganzes.

Stellen Sie sich vor, die Organisation startet zu viele Projekte gleichzeitig. Wenn diese Projekte dann nicht die nötigen Ressourcen bekommen, weil die Organisation an ihre Grenzen stößt, dann liegt das Problem nicht unbedingt bei den Projekten selbst. Es könnte ein Zeichen dafür sein, dass das Projektportfolio nicht richtig geplant wurde. Und obwohl die Projektleiter die Hauptlast dieser Probleme tragen, ist die eigentliche Ursache ein Portfolio, das nicht gut durchdacht wurde.

Zusammenfassung

• Der Zweck eines Portfolios von Projekten und Programmen besteht darin, die Ziele einer Organisation zu erreichen.
• Die Zusammensetzung des Portfolios ändert sich durch die Ergebnisse der Projekte und durch veränderte Geschäftsprioritäten. Das Portfolio wird auch beeinflusst durch neue Chancen und Herausforderungen und die daraus resultierenden Anpassungen der strategischen Planung der Organisation.
• Das Management eines Portfolios von Projekten und Programmen umfasst das Sammeln von Ideen, deren Analyse, Auswahl und Priorisierung, Durchführung, Nutzenrealisierung, Change Management und Feedback. Jedes dieser Elemente ist entscheidend, um die Leistung einer Organisation zu verbessern. Zusammen sind sie ein Sprungbrett zur strategischen Exzellenz.
• Und das Wichtigste: die Leitung von Projekten, Programmen und Portfolios muss integriert sein.

 

 

 

 

 

 

1.3 Projektauswahl 2 – Business Case

In diesem Abschnitt erfahren Sie mehr über das Konzept des Business Case, auf Deutsch Geschäftsszenarios und wie es dazu dient, einen Projektvorschlag zu untermauern.

Was genau meinen wir mit einem Geschäftsszenario? Ganz einfach: Stellen Sie sich ein Geschäftsszenario als einen Vorschlag vor, der aufzeigt, welche Auswirkungen eine Genehmigung oder Ablehnung des vorgeschlagenen Projekts auf das Unternehmen haben wird. Dabei geht es vor allem darum, sicherzustellen, dass die Organisation nicht unnötig Ressourcen in wenig versprechende Projekte steckt und nur die besten Projektvorschläge weiterverfolgt werden.

Die Erstellung von Geschäftsszenarien greift auf die Liste von Ideen zurück, die im ersten Schritt des Portfoliomanagements generiert und erfasst wurden. Jetzt geht es darum, dass die Initiatoren von diesen Ideen ein Geschäftsszenario für die von ihnen vorgeschlagenen Ideen erstellen. Dieser Schritt dient als erste Überprüfung, denn wenn jemand nicht die Zeit findet, seine Idee in Form eines Geschäftsszenarios mit allen Kosten, Nutzen, Risiken und möglichen Alternativen darzulegen, dann deutet das darauf hin, dass diese Idee vielleicht nicht die nötige Priorität genießt – nicht einmal für denjenigen, der sie vorgeschlagen hat.

Welche Elemente können oder sollten in einem Geschäftsszenario enthalten sein? Es gibt keine Einheitslösung, aber einige Aspekte können den Inhalt beeinflussen: die internen Richtlinien einer Organisation, die Höhe der geplanten Investition oder der verfügbare Zeitrahmen. Im Folgenden werden wir ein detailliertes Geschäftsszenario vorstellen, das je nach Bedarf angepasst werden kann.

Ein sinnvoller Startpunkt für jedes Projekt ist eine klare Begründung seiner Notwendigkeit. Dabei wird erörtert, welches Problem adressiert oder welche Geschäftsmöglichkeit ergriffen werden soll. Was genau ist das Problem, das wir mit diesem Projekt lösen möchten? Was sind seine Ursachen und welche Auswirkungen hat es? Handelt es sich hingegen um eine Geschäftsmöglichkeit, wollen wir die sich eröffnenden Chancen und das damit verbundene Potenzial klären.

Es geht darum, zu verdeutlichen, warum wir der Meinung sind, dass dieses Projekt unternommen werden muss.

Bei der Konfrontation mit einem Problem gilt es zu entscheiden, ob wir die Ursachen direkt angehen möchten. Sollen alle Ursachen adressiert werden oder nur ausgewählte? Und wenn ja, welche? Es steht auch zur Debatte, ob wir uns auf die Behebung der dringlichsten Auswirkungen konzentrieren sollten. Welche Auswirkungen wären das? Nehmen wir das Beispiel einer Arthrose mit starken Knieschmerzen, verursacht durch ein abgenutztes Gelenk. Eine mögliche Lösung wäre der Einsatz eines künstlichen Gelenks, um die Ursache direkt zu behandeln. Gleichzeitig könnten die Schmerzen mit Medikamenten gelindert werden, was eine sofortige Milderung der Symptome bewirkt. Alternativ könnten wir uns entscheiden, die Ursache vorerst zu tolerieren und lediglich die Symptome zu behandeln. Diese Überlegungen müssen auch im Geschäftskontext angestellt werden: Was ist das zugrundeliegende Problem, seine Ursachen und Auswirkungen, und welchen Teil davon möchten wir mit unserem Projekt angehen?

Ähnlich wie bei der Lösung eines Problems, wo wir entscheiden müssen, ob und welche Ursachen wir angehen und ob wir uns auf die dringlichsten Auswirkungen konzentrieren, erfordert die Identifizierung einer Geschäftsmöglichkeit eine sorgfältige Auswahl. Bei einer sich öffnenden Chance, wie der Deregulierung des japanischen Marktes, ist zu bestimmen, welche Aspekte des Potenzials wir mit unserem Projekt erschließen möchten. Sollen wir eine breite Strategie verfolgen, die das gesamte Spektrum der Möglichkeiten abdeckt, oder eine fokussierte Herangehensweise wählen, die sich auf die Bereiche mit dem höchsten Potenzial konzentriert? Darüber hinaus müssen wir abwägen, ob es vorteilhafter ist, die sofort greifbaren Chancen zu nutzen, die eine schnelle Realisierung versprechen. Diese strategischen Entscheidungen sind von entscheidender Bedeutung, um festzulegen, welchen Teil der Geschäftsmöglichkeit wir durch unser Projekt realisieren wollen.

Nachdem festgelegt wurde, welcher Teil des Problems oder der Geschäftsmöglichkeit vom Einzelprojekt adressiert werden soll, präsentiert das Projektteam eine sorgfältige Bewertung verschiedener Alternativen. Es wird überzeugend erläutert, warum die ausgewählte Lösungsoption den anderen vorzuziehen ist. Die Alternativenliste umfasst zwei Extreme: Zum einen die umfassendste Lösung und zum anderen die Option des Nicht-Handelns, also die Entscheidung gegen die Durchführung des Projekts. Zwischen diesen Extremen befinden sich Ansätze mit mittlerer bis geringer Wirkung, die darauf abzielen, negative Auswirkungen zu mildern oder umgehend einige Vorteile der Geschäftsmöglichkeit zu realisieren.

Als nächstes folgt die wirtschaftlich-finanzielle Analyse, in der eine ungefähre Schätzung der Kosten, des Nutzens und des Zeitrahmens vorgenommen wird.

Eine klare Darstellung der Risiken, der zugrundeliegenden Annahmen für Schätzungen und möglicher Einschränkungen ist ebenfalls ein wesentlicher Bestandteil eines Geschäftsszenarios. Die Identifikation und Analyse dieser Faktoren sind unerlässlich. Eine Vertiefung in die Risikoanalysetechniken und die Differenzierung zwischen Risiken und Annahmen sprengt jedoch den Rahmen dieser Lektion. Dieser Abschnitt ist bereits umfangreich; eine weitere Ausdehnung würde ihn überladen. Für detaillierte Informationen zu Risiken wird auf die entsprechenden Lektionen verwiesen, die sich mit den Initialisierungs- und Planungsprozessen befassen und in denen solche Analysen behandelt werden.

Schätzungen.

Im Zuge der Erstellung von Geschäftsszenarien sind Schätzungen erforderlich, die auf Erfahrungen und Annahmen fußen. Sie helfen dabei, den finanziellen Bedarf, den Einsatz von Personal und weiteren Ressourcen, die Projektdauer sowie den Nutzen und den Zeitpunkt seiner Realisierung zu ermitteln.

Bitte beachten Sie, dass es bei der Erstellung von Geschäftsszenarien um grobe Schätzungen geht. Diese erkennen die inhärente Unsicherheit jedes Projekts an und reflektieren, dass sie nicht aus einer detaillierten Planung resultieren, sondern vielmehr eine initiale Annäherung darstellen. Deshalb sollten sie stets einen signifikanten Spielraum für mögliche Abweichungen einbeziehen.

Diese Schätzungen sollten daher nicht als definitives Projektbudget herangezogen werden, sollte das Projekt genehmigt werden. In dieser Phase ist es passender, sich auf das zu stützen, was als “ungefähre Größenordnung” (englisch “Rough Order of Magnitude”, ROM) bekannt ist. Diese Art von Schätzung kann eine Variationsbreite aufweisen, die je nach den zugrunde liegenden Annahmen und Szenarien auch über 100% hinausgehen kann.

Je weniger vertraut das Wesen des Projekts und die Anforderungen des zu realisierenden Vorhabens sind, desto umfangreicher muss der geschätzte Variationsbereich ausfallen, um der Vielzahl an unbekannten Variablen Rechnung zu tragen.

Beachten Sie, dass das Geschäftsszenario nicht der Projektplanung gleichkommt. Wir befinden uns noch nicht in dieser Phase. Zu diesem Zeitpunkt steht noch nicht fest, ob das Projekt in die Initialisierungs- und Planungsphase übergehen wird. Es gibt noch kein Planungsteam und es wurde noch kein Projektmanager bestimmt. Der Initiator, der wahrscheinlich der zukünftige Sponsor sein wird, trägt die Verantwortung für die Ausarbeitung des Geschäftsszenarios, das er der Organisation unterbreiten möchte.

Möchte der Initiator eine eingehende Untersuchung der Idee vornehmen, sollte er der Organisation die Durchführung einer Machbarkeitsstudie empfehlen, die an sich bereits ein Projekt darstellt. Bei Genehmigung dieses Vorhabens durch die Organisation, eine Machbarkeitsstudie zu erstellen, wird ein Team mit deren Ausführung beauftragt. Dies ist insbesondere bei umfangreichen Projekten gängige Praxis, die technische, ökologische, wirtschaftlich-finanzielle und weitere Studien zur Machbarkeit erfordern. Solche Vorprojekte werden oft als separate Projekte behandelt. Nach ihrem Abschluss und bei positivem Ausgang bilden sie eine sehr solide Basis für den Start des Hauptprojekts, gestützt auf die zuvor durchgeführten Studien. Diese Vorgehensweise ist typisch für große Investitionsprojekte. Bei den meisten Projekten jedoch ist ein Geschäftsszenario ausreichend. In vielen Fällen wird bei kleineren Projekten das Geschäftsszenario auf eine narrative Begründung von einigen wenigen Absätzen beschränkt.

Parameter für die wirtschaftliche und nicht-wirtschaftliche Analyse.

Im Rahmen der Projektanalyse nutzen Entscheidungsträger typischerweise zwei Arten von Parametern: ökonomische für die quantitative Bewertung und nicht-ökonomische für die qualitative Einschätzung. Die quantitative Bewertung konzentriert sich auf die finanzielle Rentabilität und ist oft entscheidend für die Beurteilung des Projekts, besonders in gewinnorientierten Organisationen. Zu den ökonomischen Parametern, die zur Berechnung der Rentabilität eines Projekts herangezogen werden, zählen Kosten, der erwartete Nutzen und die Zeitspannen, in denen diese anfallen.

Die qualitative Analyse befasst sich mit den nicht-finanziellen Faktoren wie sozialen, ökologischen und kulturellen Effekten, die sich nicht direkt in monetären Größen ausdrücken lassen. Diese ‘weichen’ Bewertungskriterien erfordern ein subjektives Urteil und sind oft schwer zu erfassen und zu quantifizieren. Um diese Herausforderung zu meistern, werden wir Methoden vorstellen, die es erlauben, qualitative Daten in eine Multikriterien-Entscheidungsmatrix zu integrieren. Dies ermöglicht es uns, eine ganzheitliche Bewertung vorzunehmen, bei der die stärksten Vorschläge aus der optimalen Kombination aller relevanten Faktoren hervorgehen.

Die Investitionsrendite verstehen.

Beginnen wir mit der wirtschaftlich-finanziellen Analyse und betrachten eine der zentralen Kennzahlen zur finanziellen Projektbewertung: den Return on Investment (ROI). Der ROI dient dazu, die Rentabilität des in ein Projekt investierten Kapitals über einen bestimmten Zeitraum zu messen. Er ist ein entscheidendes Instrument, um die Vorteilhaftigkeit einer Investition zu beurteilen und ermöglicht den direkten wirtschaftlich-finanziellen Vergleich verschiedener Projekte, unabhängig von deren Lieferobjekt. In der Regel erhalten Investitionen mit dem höchsten ROI die höchste Priorität.

In einer verfeinerten Analyse berücksichtigt die ROI-Berechnung auch die zukünftigen Cashflows, abgezinst auf ihren heutigen Wert. Dies ermöglicht es, die Rentabilität von Projekten mit unterschiedlichen Laufzeiten objektiv zu vergleichen. Nehmen wir an, ein Projekt verspricht eine Rendite von 100.000 Euro in drei Jahren, während ein anderes 120.000 Euro in vier Jahren erwirtschaften soll. Auf den ersten Blick ist nicht klar, welches Projekt vorteilhafter ist. Durch die Diskontierung der zukünftigen Cashflows auf ihren Gegenwartswert können jedoch beide Projekte auf einer gemeinsamen Basis bewertet werden.

Die zugrundeliegende Mathematik der Berechnung mag auf den ersten Blick komplex erscheinen, doch ein einfaches Beispiel verdeutlicht das Prinzip: Was würden Sie vorziehen: 1000 Euro heute zu erhalten oder in einem Jahr? Die Antwort liegt auf der Hand: Je früher das Geld verfügbar ist, desto besser. Dies spiegelt sich auch in der Berechnung wider: Der heutige Wert von 1000 Euro, die erst in einem Jahr ausgezahlt werden, ist geringer als der Wert derselben Summe, die sofort verfügbar ist.

Lassen Sie uns die ROI-Berechnung anhand eines praxisnahen Beispiels veranschaulichen: Stellen Sie sich vor, Sie planen, in neue Technologien zur Modernisierung des Produktionssystems einer Fabrik zu investieren. Die Anschaffungs- und Installationskosten der benötigten technischen Ausrüstung belaufen sich auf 100.000 Euro. Bis zur vollständigen Einsatzbereitschaft vergeht ein Jahr. Nach Inbetriebnahme wird erwartet, dass die Ausrüstung die Betriebskosten jährlich um 45.000 Euro senkt. Für die Berechnung der Investitionsrendite legen wir einen Zeitraum von fünf Jahren zugrunde: ein Jahr für die Implementierung des Projekts und vier weitere Jahre, in denen die Produktion von den Kosteneinsparungen profitiert.

Wie beurteilen Sie diese Investition – lohnenswert oder nicht? Lassen Sie uns dies analysieren, indem wir die Investitionsrendite, den ROI, kalkulieren. Sie investieren 100.000 Euro. Diese Investition wird sich auszahlen, indem sie Ihre Kosten jährlich um 45.000 Euro über die kommenden vier Jahre senkt.

Das bedeutet, dass diese Investition über den Zeitraum von fünf Jahren einen Bruttogewinn von 180.000 € generieren wird. Zieht man die anfängliche Investition von 100.000 € vom Bruttogewinn ab, ergibt sich ein Nettogewinn von 80.000 €. Um die durchschnittliche jährliche Nettorendite zu berechnen, teilt man den Nettogewinn von 80.000 € durch die fünf Jahre.

Indem man die jährliche Nettorendite von 16.000 € durch die anfängliche Investition von 100.000 € teilt, ergibt sich der Renditeprozentsatz in Bezug auf die Investition, welcher 16% beträgt. Dieser Wert repräsentiert den ROI. Mit anderen Worten, die Investition in die Ausrüstung steigert den Wert der eingesetzten 100.000 € jährlich um 16%. Generell gilt: Je höher der ROI, desto vorteilhafter erscheint die Investition.

Ob 16% eine gute Investitionsrendite (ROI) darstellen, hängt von den verfügbaren Alternativen und den von der Organisation festgelegten Parametern ab. Könnten die Ressourcen der Organisation in andere Projekte investiert eine höhere Rendite erzielen? Unternehmen, die einen Mindest-ROI definieren, verwerfen Projekte, die diese Schwelle in der frühen Auswahlphase nicht überschreiten. Wenn also der berechnete ROI nicht nur den geforderten Mindestwert übersteigt, sondern auch höher als der ROI vergleichbarer Projekte ist, dann kann man aus dieser Bewertungsperspektive von einer guten Investition sprechen.

Damit schließen wir die kompakte Darlegung zur Investitionsrendite, dem ROI, und seiner Berechnungsweise ab.

Nicht-ökonomische Analyse.

Kommen wir jetzt zur nicht-ökonomischen Analyse, die manchmal auch als qualitative Analyse bezeichnet wird. Hierbei betrachten wir Faktoren jenseits der finanziellen Zahlen, zum Beispiel wie eine Investition das Markenimage beeinflussen kann, wenn sie etwa zur Dekarbonisierung beiträgt oder barrierefrei für Menschen mit körperlichen Behinderungen ist. Wenn unsere Ausrüstung mit künstlicher Intelligenz arbeitet, verbessert dies unser fortschrittliches Unternehmensimage, das bisher vielleicht als zu traditionell wahrgenommen wurde. Zudem prüfen wir, wie die Investition zur Erreichung strategischer Unternehmensziele beiträgt. Wie bewerten wir also ein Projekt mit 16% Rendite im Vergleich zu einem anderen mit 20%, wenn das erstere stärker zu qualitativen Zielen beiträgt? Für solche Fälle nutzen wir eine Multikriterien-Entscheidungsmatrix, die im Abschnitt zur Strategiebewertung detaillierter beschrieben wird. Hier schon mal ein kleiner Ausblick darauf.

		Projekt 1 (ROI 16%)		Projekt 2 (ROI 20%)
	Gewicht	Erfüllung (Skala 1 bis 10)	Gewicht	Erfüllung (kcala1 bis 10)	Wert
ROI	50	8	400	10	500
Risiko	20	8	160	5	100
CO2	5	10	50	0	0
Sozial	10	7	70	0	0
Image	15	10	150	4	60
Beitrag zum strategischen Ziel X	50	8	400	5	250
			1230		910

Der erste Schritt ist die Festlegung der Gewichtungen für jeden Parameter. Angenommen, wir legen fest, dass der ROI eine Bedeutung von 50 Punkten in unserem Bewertungsschema hat. Das Risikolevel bekommt 20 Punkte, der Beitrag zum Unternehmensimage durch Dekarbonisierung 5 Punkte, der soziale Faktor 10 Punkte und der Einsatz künstlicher Intelligenz 15 Punkte. Dem Beitrag zu strategischem Ziel X messen wir dieselbe Bedeutung bei wie dem ROI, also ebenfalls 50 Punkte. Beachten Sie, dass die Gesamtsumme dieser Gewichtungen nicht zwingend 100 ergeben muss.

Anschließend passen wir die Renditeraten an eine Bewertungsskala von 1 bis 10 an, wobei dem Projekt mit 16% ROI eine 8 und dem Projekt mit 20% ROI eine 10 zugeordnet wird. Das gleiche Verfahren wenden wir auf das Risikoniveau an, wobei das weniger riskante erste Projekt eine 8 erhält, während das riskantere zweite Projekt mit einer 5 bewertet wird. Diese Methode wenden wir auch auf die übrigen Parameter an. Durch die Multiplikation der Gewichtung mit der erreichten Punktzahl jedes Parameters generieren wir vergleichbare Werte für jeden Parameter in beiden Projekten. Addiert man diese Werte, ergibt sich ein Gesamtbild für beide Optionen. In unserem Beispiel erzielt Projekt 1 trotz der geringeren ROI aufgrund seiner besseren Bewertungen in den anderen Parametern eine höhere Gesamtbewertung als Projekt 2. Projekt 1 ist weniger riskant und leistet einen größeren Beitrag zu den zusätzlichen Parametern, die wir in unserer Multikriterien-Entscheidungsmatrix bewerten.

Dank der Technik der Multikriterien-Entscheidungsmatrix ist es uns möglich, schwer vergleichbare Parameter nebeneinanderzustellen und zu bewerten. Dies schließt solche mit einem subjektiven Charakter, wie die Risikoeinschätzung, bis hin zu jenen mit einem hohen Maß an Subjektivität, wie die Aufwertung des Unternehmensimages durch soziales Engagement und Beitrag zur Dekarbonisierung, ein. Um die Subjektivität zu mindern, könnte die Beurteilung der Erfüllung der nicht-finanziellen Parameter etwa auf einem Durchschnitt der Einschätzungen beruhen, die von einem Gremium verschiedener Personen vorgenommen wurden.

Die Multikriterien-Entscheidungsmatrix kommt auch im vierten Schritt des Portfoliomanagementprozesses zum Einsatz. Hierbei geht es um die Auswahl und Priorisierung von Projekten, die bereits frühere Filter passiert haben, mit dem Ziel, ein ausgewogenes Portfolio zu schaffen. Dies geschieht unter Einbeziehung verschiedener Parameter, wie im Abschnitt zur Gesamtbetrachtung des Projekt- und Programmportfoliomanagements dargelegt.

Neben dem ROI ist die Risikobewertung der zweite klassische Bestandteil aus dem Geschäftsszenario, der bei der Erstellung eines ausgewogenen Portfolios verwendet wird.

Ein anderes Beispiel für einen nicht-finanziellen oder qualitativen Parameter wäre das Bestreben, eine spezielle Technologie voranzutreiben, von der angenommen oder bekannt ist, dass sie künftig für den Geschäftserfolg entscheidend sein könnte.

Das Berücksichtigen nicht-finanzieller Bewertungskriterien kann das strategische Profil einer Organisation potenziell umgestalten und zu radikal innovativen Produkten und Dienstleistungen führen. Es ist für Unternehmen ratsam, einen Budgetanteil in solche Vorhaben zu investieren, selbst wenn bekannt ist, dass es sich um Projekte mit hohem Risiko handeln könnte, ähnlich der Expedition über den Atlantik nach Indien, die letztendlich zur Entdeckung Amerikas führte.

Zusammenfassend und als Empfehlung für ein überzeugendes Gesamtkonzept:

Wir sind die Bestandteile durchgegangen, die in einer detaillierten und breit gefächerten Ausarbeitung eines Geschäftsszenarios enthalten sein könnten, inklusive:

• Der Projektbegründung, die unterschiedliche Lösungswege für das vorhandene Problem oder die Nutzung der gegebenen Chance darlegt.
• Der ökonomisch-finanziellen Analyse, die Kosten, Nutzen und Zeitrahmen einschließt.
• Den zugrunde liegenden Annahmen und potenziell vorhandenen Beschränkungen.
• Den zum aktuellen Zeitpunkt erkennbaren Risiken.
• Sowie gegebenenfalls den qualitativen Entscheidungskriterien in einer Multikriterienmatrix.

Sollte das Ergebnis – wie zu erwarten, wenn alle genannten Elemente berücksichtigt werden – umfangreich ausfallen, ist es ratsam, zwei weitere Aspekte hinzuzufügen, die den Entscheidungsprozess der Führungskräfte vereinfachen: eine Managementzusammenfassung sowie konkrete Empfehlungen.

Zusammenfassung:

Ein Geschäftsszenario ist ein Dokument, das darlegt, welche Auswirkungen auf das Geschäft zu erwarten sind, sowohl wenn das in Aussicht gestellte Projekt grünes Licht erhält, als auch wenn es nicht genehmigt wird.

Ein Geschäftsszenario umfasst: die Begründung für das Projekt, mögliche Alternativen, Kostenvoranschläge, erwarteten Nutzen und Zeitpläne, Risikoanalysen, zugrunde liegende Annahmen und identifizierte Einschränkungen, sowie eine Managementzusammenfassung und Handlungsempfehlungen.

Geschäftsszenarien basieren auf groben Schätzungen, deren Variationsbereich weit genug gefasst ist, um das Unsicherheitsniveau des jeweiligen Projekts adäquat widerzuspiegeln.

Ein Geschäftsszenario ist kein Projektplan, sondern ein vorgelagerter Schritt, der dazu dient zu beurteilen, ob es sich lohnt, Ressourcen für den Anstoß und die Planung des Projekts aufzuwenden.

Die Berechnung des Return on Investment, kurz ROI, quantifiziert die Rendite des in ein Vorhaben investierten Kapitals als jährlichen Prozentsatz. Ein höherer ROI steht für eine bessere Kapitalrendite.

Neben der ökonomisch-finanziellen Bewertung eines Projektvorschlags lassen sich qualitative Kriterien heranziehen, die in einer Multikriterien-Entscheidungsmatrix zusammengeführt werden können.

 

 

 

 

1.4 Projektinitialierung – Überblick

This Dieser Abschnitt gibt Ihnen einen Überblick über die Aktivitäten, die mit der Initiierung eines Projekts verbunden sind, und erklärt, dass dies nicht dasselbe ist wie die Planung.

Ein Projekt zu initiieren bedeutet, ein neues Projekt oder eine neue Phase eines bestehenden Projekts zu definieren und die Genehmigung für den Start des Projekts oder der Phase zu erhalten. Das Ziel der Initiierung ist es, die neue temporäre Organisation “Projekt x” zu schaffen; die Erwartungen der Schlüsselbeteiligten in Bezug auf Zweck und Ziel abzugleichen; und zu besprechen, wie ihre Beteiligung am Projekt oder an der Phase dazu beitragen wird, ihre Erwartungen zu erfüllen.

Während des Initiierungsprozesses wird der anfängliche Umfang definiert und anfängliche finanzielle Ressourcen werden reserviert. Es handelt sich nicht um ein Budget, da das Budget aus den Planungsprozessen resultieren wird, die wir noch nicht durchgeführt haben. Es geht darum, Mittel für den Fall zu reservieren, dass das Projekt am Ende des Initiierungsprozesses genehmigt wird, oder Mittel zu dokumentieren, die für das Projekt nach seiner Auswahl auf der Grundlage eines Geschäftsszenarios, auch Business Case genannt im Rahmen des Portfoliomanagements reserviert wurden.

Während der Initiierung werden die Stakeholder bestimmt, mit ihnen wird geklärt und vereinbart, welchen Teil des Problems oder der Geschäftsmöglichkeit das Projekt angehen wird, sein Zweck und sein Leitziel werden definiert, es wird erklärt, warum die gewählte Strategie die am besten geeignete ist, um das Leitziel zu erreichen, die wichtigsten Liefergegenstände, die aus der gewählten Strategie resultieren, werden bestimmt, allgemeine Risiken und bestehende Einschränkungen werden identifiziert, und es werden auch explizit Annahmen formuliert, um mit unbekannten Elementen zu arbeiten. Wenn zuvor ein Geschäftsszenario, durchgeführt wurde, werden viele dieser Elemente bereit sein, konsultiert und gegebenenfalls überarbeitet und aktualisiert zu werden. Schließlich wird der Projektmanager offiziell ernannt.

All diese Informationen werden im Projektauftrag festgehalten, und es wird auch ein Stakeholder-Register erstellt.

Die Unterzeichnung des Projektauftrags repräsentiert den formellen Gründungsakt der neuen temporären Organisation namens “Projekt x”. Der im Dokument ernannte Projektmanager wird dadurch berechtigt, Ressourcen der Organisation für die Projektaktivitäten gemäß dem im Dokument gewährten Autoritätsniveau zu verwenden. Der Projektauftrag muss vom Sponsor und gegebenenfalls von anderen Personen der ausführenden und/oder begünstigten Organisation unterzeichnet werden.

Der Projektmanager wird normalerweise zu Beginn oder während des Initiierungsprozesses ernannt, damit er den Rest der Initiierungsarbeiten leiten kann. Manchmal wird der Projektmanager jedoch nach der Genehmigung des Projektauftrags ernannt. In dieser Situation muss sich der Projektmanager überprüfen, was während der Initiierung getan wurde, und eventuell weggelassene oder unvollständige Aktivitäten vervollständigt, die Teil der Initiierung sind.

In den folgenden Abschnitten werden wir die Schlüsselelemente zur Definition eines Projekts, den Inhalt des Projektauftrags und des Stakeholder-Registers im Detail erläutern.

 

 

1.5 Die Projektstakeholder Identifizieren, analysieren und klassifizieren

Dieser Abschnitt hilft Ihnen zu verstehen, wer die Projektstakeholder sind und wie man sie analysiert und klassifiziert.

Die Projektstakeholder identifizieren.

Als Projektleiter müssen Sie wissen, wer ein Interesse an der Durchführung und/oder am Ergebnis des Projekts hat. Diese Personen oder Gruppen werden als “Beteiligte” oder auf Englisch “Stakeholder” bezeichnet. Dazu gehören unter anderem der Kunde, der Projektsponsor, die am Projekt beteiligten Abteilungen und die Personen, die an den Projektaktivitäten arbeiten.

Es ist von entscheidender Bedeutung zu wissen, wer welche Rolle spielt, die Bedeutung jedes Einzelnen zu verstehen, seinen Einfluss und sein Interessensniveau sowie seine Erwartungen und den Beitrag, den sie leisten können. Auf dieser Grundlage können wir angemessen mit einflussreichen Beteiligten umgehen, sei es, um einen günstigen Einfluss zu nutzen, wenn der Beteiligte einflussreich, positiv eingestellt und dem Projekt verpflichtet ist, oder um zu bestimmen, wie man im Gegenteil handeln sollte, da wir mit einem gewichtigen Gegner zu tun haben und vorbereitet sein müssen.

Beginnen wir mit der Identifizierung der Projektrollen, die verschiedene Beteiligte spielen.

Der Projekt-Kunde ist die Person oder Gruppe, die ein Problem zu lösen hat. Der Kunde des Projekts bringt drei entscheidende Dinge in ein Projekt ein. Erstens finanziert der Kunde das Projekt. Zweitens hat der Kunde viel über das zu sagen, was das Projekt schaffen wird. Drittens genehmigt der Kunde die Liefergegenstände von Anfang bis Ende.

Die nächste Rolle ist die des Projektsponsors. Es ist möglich, dass Kunde und Sponsor dieselbe Person sind, insbesondere bei einem internen Projekt. Der Sponsor ist jemand, der möchte, dass das Projekt erfolgreich ist und in der ausführenden Organisation genügend formelle Autorität hat, um diesen Erfolg zu ermöglichen. Zum Beispiel eine leitende Führungskraft, die an das Projekt glaubt. Der Sponsor kann helfen, Ziele zu priorisieren, andere wichtige Beteiligte zu beeinflussen, die nicht genügend Unterstützung bieten, und kann Änderungen am Projektmanagementplan vorschlagen oder anordnen. Agile Methoden, die wir in späteren Abschnitten sehen werden, verwenden für diese Rolle den Begriff “Produkteigentümer” oder auf Englisch “Product Owner”.

Die dritte Gruppe von Beteiligten sind die funktionalen oder Linienmanager. Funktionale Manager leiten Abteilungen und sind dafür verantwortlich, die Ziele und Vorgaben der Abteilung, die sie leiten, zu erreichen. Sie sind auch die Vorgesetzten des Personals ihrer Abteilungen, das oft die Personen sind, die der Projektmanager benötigt. Daher ist es entscheidend, ihre Unterstützung für das Schicksal des Projekts zu erhalten.

Einige Organisationen haben eine spezielle Art von Abteilung namens Projektmanagementbüro, PMO, manchmal auch Projektbüro oder ähnliches genannt. Die Hauptfunktion einer solchen Abteilung ist es, den Projektmanager zu helfen. Zum Beispiel durch die Entwicklung einer Projektmanagementmethode der Organisation, damit die Projekte der Organisation gemäß diesen Regeln durchgeführt werden. Sie bieten auch Services an zur Schulung und Beratung der Projektmanager aber auch zum Audits der Projekte. Wenn Ihre Organisation ein Projektbüro hat, ist es natürlich auch ein Beteiligter.

Teammitglieder sind ebenfalls Beteiligte. Obwohl sie ihrem Projekt zugewiesen sind und Projektaufgaben durchführen, ist es nicht ungewöhnlich, dass sie weiterhin parallel dazu verpflichtet sind, ihre betrieblichen Aufgaben zu erfüllen. Vieles hängt davon ab, wie gut sie beide Funktionen kombinieren können.

Generell kann man sagen, dass die Beteiligten die Personen oder Gruppen sind, die das Projekt beeinflussen und/oder von ihm betroffen sind. Dies sowohl als Folge der Durchführung des Projekts als auch durch sein Ergebnis. Alle sind Beteiligte am Projekt, und einige von ihnen sind entscheidend für seinen Erfolg oder Misserfolg.

Der erste Schritt besteht darin, herauszufinden, wer sie sind.

Die Projektstakeholder analysieren und klassifizieren.

Es kann mühsam sein, herauszufinden, wer die Beteiligten sind, wie wichtig sie für das Projekt sind und wie man am besten mit jedem von ihnen arbeitet. Um diese Arbeit zu erleichtern, erstellen wir ein Stakeholder-Analyse-Dokument, in dem wir Informationen speichern, während wir den Identifikations- und Analyseprozess durchlaufen. Denn die Identifikation und Analyse von Beteiligten, ihren Interessen, Beiträgen und ihrer Einstellung zum Projekt ist ein Prozess, der während der Projektdefinition und auch zu Beginn jeder Phase stattfindet. Denn in verschiedenen Projektphasen ändern sich oft einige der Beteiligten, und bestehende Beteiligte können unterschiedliche Interessen, Beiträge, Einstellungen und Bedeutungen haben.

Zunächst müssen wir wissen, wie die verschiedenen Beteiligten mit dem Projekt verbunden sind und was sie antreibt. Wir beginnen damit, den Namen, die Abteilung, die Geschäftseinheit und/oder das Unternehmen, zu dem jeder gehört, und seine Position in der jeweiligen Organisation aufzulisten.

Als nächstes bestimmen wir, wer Einfluss auf jeden hat. Dies kann uns helfen, mit dem betreffenden Beteiligten umzugehen.

Durch Gespräche mit jedem Beteiligten oder Vertretern von Gruppen identifizieren wir ihre Ziele, Anforderungen und Prioritäten in Bezug auf das Projekt. So wissen wir, wen ein Problem mit einem bestimmten Ziel oder einer bestimmten Anforderung betrifft.

Anschließend kategorisieren wir die Beteiligten nach ihrem Einfluss und Interesse am Projekt, was es uns ermöglicht, Schlüsselbeteiligte zu priorisieren.

Wir können auch die Beiträge der Beteiligten zum Projekt dokumentieren, um uns daran zu erinnern, an wen wir uns wenden müssen, wenn wir Dinge benötigen.

Das Erreichen des Engagements und der Zufriedenheit der Beteiligten ist eine schwierige Aufgabe, aber unmöglich, wenn man nicht weiß, wer sie sind, was sie wollen und welche Einstellung sie zum Projekt haben. Deshalb ist es wichtig, die Beteiligten während der Projektinitiierung und deren Phasen zu identifizieren, zu analysieren und zu klassifizieren.

 

 

 

 

1.6 Identifizieren, welcher Teil des Problems oder der Geschäftsmöglichkeit das Projekt angehen wird

Dieser Abschnitt erklärt die Bedeutung des Aufteilens großer Herausforderungen in kleinere, handhabbare Einheiten, die durch Projekte bewältigt werden können. Zudem wird erläutert, wie eine Kombination aus Projekten und laufenden Betriebsabläufen genutzt werden kann, um anspruchsvollere Ziele zu erreichen.

Große Probleme.

Ein Hauptgrund für das Scheitern von Projekten, insbesondere Megaprojekten, liegt oft in einem zu umfangreichen Projektumfang, gekennzeichnet durch hohe Komplexität und erheblichen Zeitaufwand. Oft steht eine Organisation vor großen Herausforderungen oder Geschäftsmöglichkeiten, die die Annahme nahelegen, dass auch das Projekt entsprechend groß sein muss. Jedoch gilt für die Bewältigung großer Aufgaben das Prinzip des ‘Elefanten-Essens’: Man bewältigt sie Stück für Stück.

Organisationsziele können als ‘Elefanten’ betrachtet werden, deren Erreichung die Kapazitäten eines einzelnen Projekts überschreitet. Stattdessen liegt der Schlüssel zum Erfolg in der Strukturierung von Portfolios, die eine Kombination aus verschiedenen Projekten und Programmen umfassen. Diese sind so konzipiert, dass sie gemeinsam und schrittweise das übergeordnete Unternehmensziel erreichen.

Der Schlüssel zur Vermeidung von endlosen Projekten befindet sich auf der Programmebene: einer Gruppe von miteinander verbundenen Projekten und operativen Betriebsabläufen. Die Projekte im Programm liefern die notwendigen Elemente für die Veränderung der operativen Geschäftsabläufe. Diese Betriebsabläufe im selben Programm nutzen diese Elemente, was die angestrebte Veränderung bewirkt. War das Programm gut definiert, sollte die durchgeführte Änderung der Betriebsabläufe den im Geschäftsszenario formulierten erwarteten Nutzen bringen. Wird dieser Nutzen nicht erreicht, müssen Änderungen in der Portfoliozusammensetzung vorgenommen werden, um die Abweichung zu korrigieren. Dafür sind neue oder modifizierte Projekte und Programme erforderlich, um die Lücke zwischen dem erwarteten und dem tatsächlich erzielten Nutzen zu schließen.

In dem bereits formulierten Beispiels einer neuen Ausrüstung, die 100.000 € kostet und die Betriebskosten um 45.000 € pro Jahr senkt, könnte man ein 5-Jahres-Projekt formulieren, das erst am Ende des fünften Jahres zeigt, ob es erfolgreich war oder nicht. Oder, stattdessen, könnten wir ein Programm aus einem einjährigen Projekt bis zur Inbetriebnahme der neuen Ausrüstung und 4 Jahre operative Nutzung der Ausrüstung formulieren. Die vier Jahren operative Nutzung der Ausrüstung lägen außerhalb des Investitionsprojekts aber innerhalb des Programms. Dadurch entstünde der im Geschäftsszenario vorgesehene Nutzen im Rahmen des Programms. Das einzelne Projekt zur Installation der Ausrüstung würde Erfolgskriterien auf Projektebene benötigen, z.B. dass es rechtzeitig, mit dem erforderlichen Umfang, der erforderlichen Qualität und gemäß dem definierten Budget geliefert wurde. D.h. man würde klassische Erfolgskriterien auf Projektebene definieren. Zusätzlich könnte man diese Erfolgskriterien durch modernere Metriken wie die Kundenzufriedenheit mit der Leistung des Projektteams oder das Ausmaß der Störung der laufenden Betriebsabläufe im Laufe des Projekts ergänzen.

Große Probleme. Mehrere Probleme.

Um die Herausforderung großer und vielschichtiger Probleme besser zu verstehen, betrachten wir ein komplexeres Beispiel. Ziel ist es, zu illustrieren, wie wichtig es ist zu definieren, welcher Teil des Problems von einem einzelnen Projekt gelöst werden kann.

Angenommen, eine Organisation zielt darauf ab, ihre Kundenbindungsrate in drei Jahren zu verdoppeln, ein direktes Ergebnis der Analyse eines Rentabilitätsproblems. Anstatt das umfassende Problem auf einmal anzugehen, ist es zielführender, sich auf die spezifischen Hauptursachen für die niedrige Kundenbindungsrate zu konzentrieren.

Das Rentabilitätsproblem lässt sich auf zwei Hauptkomponenten reduzieren: unzureichende Einnahmen, übermäßige Kosten oder eine Kombination aus beidem. Wir konzentrieren uns nun ausschließlich auf den Einnahmenaspekt und lassen die Kostenseite außer Acht.

Bei den Betriebseinnahmen können die Ursachen in den verkauften Mengen oder den erzielten Preisen liegen. In diesem Beispiel vernachlässigen wir den Preisaspekt und fokussieren uns auf die verkauften Mengen. Aber selbst das ist noch zu umfangreich für ein einzelnes Projekt. Daher müssen wir weiter aufschlüsseln: Haben wir Probleme, genügend neue Kunden zu gewinnen, oder kaufen unsere bestehenden Kunden nicht genug? In diesem Fall entscheiden wir uns, uns auf die bestehenden Kunden zu konzentrieren.

Stellen Sie sich vor, unsere Analysen im Bereich Kundenbindung haben ein signifikantes Problem aufgezeigt: Neue Kunden, deren Akquisition teuer ist, tätigen nur wenige Käufe und verlassen uns dann. Die Hauptursache hierfür ist nicht die Qualität oder der Preis unserer Produkte, sondern die Unzufriedenheit mit unserer Kundenbetreuung.

Als Reaktion darauf hat die Organisation strategische Ziele für die nächsten drei Jahre gesetzt: Erhöhung der Kundenbindungsrate von aktuell 35% auf 50% im ersten Jahr und auf 85% in drei Jahren.

Unsere Problemanalyse zeigt weiterhin, dass die Kunden unzufrieden sind mit der Zeit, die es dauert, die bestellte Ware zu erhalten. Sie sind auch unzufrieden mit dem Mangel an Transparenz über die Schritte, die nach einer Bestellung erfolgen. Sie haben das Gefühl, nie zu wissen, wann sie die bestellte Ware erhalten werden.

Ein weiterer Punkt ist die Behandlung des Kunden durch unseren Kundendienst: Die Telefone sind immer besetzt, und wenn der Kunde endlich jemanden an die Leitung bekommt, stellt der Operator viele unnötige Fragen, um den Kunden zu identifizieren und den Status der entsprechenden Bestellung zu verfolgen. Darüber hinaus sind die Antworten, die nach Beschwerden über Probleme erhalten werden, aus Sicht des Kunden oft defensiv und manchmal sogar etwas unfreundlich. Schließlich bestehen auch erhebliche Inkonsistenzen bei den ausstehenden Forderungen, die auf Fehlern in der Rechnungserstellung zurückgehen.

Wie man sieht, ist die aktuelle Kundenbindungsrate von 35% eigentlich der kumulative Effekt mehrerer Ursachen in verschiedenen Bereichen. Vorausgesetzt, wir identifizieren die Hauptursachen korrekt, können wir erwarten, dass die Behebung dieser spezifischen Ursachen zum gewünschten Ergebnis führt: einer höheren Kundenzufriedenheit. Diese gesteigerte Zufriedenheit sollte zu einer höheren Kundenbindung führen, was wiederum zur Rentabilitätssteigerung beiträgt – dem strategischen Ziel der Organisation.

Neben diesen Maßnahmen sind wahrscheinlich weitere Projekte und Programme auf anderen Ebenen der Organisation erforderlich, um die Rentabilität zu erhöhen. Diese anderen Projekte würden sich mit Kosten, Verkaufspreisen und der Neukundengewinnung befassen, welche wir in dieser Betrachtung zunächst ausgeklammert haben.

 

Zeitbeschränkungen für die Fähigkeit zur Führung und Verwaltung.

Eine letzte Überlegung zur Definition von handhabbaren Einzelprojekten ist angebracht. Bedenken Sie, dass das Leiten und Verwalten eines Projekts Zeit beansprucht und dass ein Projektmanager, wenn er in Vollzeit arbeitet, nur 2000 Arbeitsstunden im Jahr zur Verfügung hat (das entspricht 50 Wochen à 40 Stunden pro Woche). Wie viel Arbeit kann er also managen, wenn ihm 2000 Stunden im Jahr zur Verfügung stehen?

Die Antwort auf diese Frage folgt einer Formel, die sich seit den Zeiten des Römischen Reiches, oder vielleicht sogar früher, kaum verändert hat: Es handelt sich etwa um das Verhältnis 1 zu 6. Alle Arten von Organisationen setzen so etwas wie 1 Manager oder Koordinator für je 6 FTE, Vollzeitäquivalente, zur Koordination ein. Sechs Vollzeitkräfte zur Koordination, jede mit 2000 Stunden pro Jahr, erbringen zusammen eine Gesamtleistung von etwa 12.000 Stunden.

Wenn ein Projekt mehr als 12.000 Arbeitsstunden im Jahr erfordert, benötigt der Projektmanager zusätzliche Unterstützung, um es zu leiten.

Diese Unterstützung könnte in Form von Lieferanten erfolgen, die nicht nur ihre technischen Teams, sondern auch deren Teamleiter mit einbringen. Dies ist besonders bei ausgelagerten Komponenten üblich. Das Prinzip gilt aber auch für interne Lieferanten. Dabei ist vorausgesetzt, dass der Projektmanager von den operationalen Abteilungen nicht nur technische Experten, sondern auch Teamleiter erhält, um die verschiedenen Arbeitspakete des Projekts zu leiten.

Die zugrundeliegende Idee ist, dass es eine Kapazitätsgrenze für den Projektmanager gibt, die erreicht wird, wenn es darum geht, pro Jahr etwa 12.000 Stunden Arbeit anderer zu managen. Wenn der Projektmanager jedoch sechs Teamleiter führt und jeder dieser Teamleiter wiederum ein Unter-Team von sechs Personen leitet und managt, dann hätte der Projektmanager die Kapazität, 6 mal 12.000 Arbeitsstunden, also insgesamt 72.000 Arbeitsstunden, zu koordinieren. Dies entspricht der Arbeitsleistung von 36 Vollzeitmitarbeitern.

Die Kernidee hinter dieser Berechnung ist zu zeigen, dass es eine natürliche Kapazitätsgrenze für die Menge an Arbeit gibt, die ein einzelner Projektmanager leiten und verwalten kann.

Zusammenfassend ist bei der Entscheidung, welcher Aspekt eines umfangreichen Problems von einem Projekt adressiert werden soll, stets die Verfügbarkeit von Ressourcen und die Einschränkungen ihrer Kapazität zu berücksichtigen. Weitere entscheidende Faktoren in diesem Zusammenhang sind:

• Die Zerlegung großer Probleme in kleinere Komponenten.
• Die Erstellung einzelner, handhabbarer Projekte zur Bewältigung dieser kleineren Komponenten.
• Die Kombination dieser Projekte in Programmen, um ein koordiniertes Management zu ermöglichen, das auf das Erreichen von Nutzen ausgerichtet ist.

 

 

 

 

 

1.7 Den Zweck und das Ziel des Projekts definieren

In diesem Abschnitt erläutern wir, wie die Zweckserklärung formuliert und das Projektziel auf Basis der Problemstellung oder der Beschreibung der Geschäftsmöglichkeit definiert wird, was zu Beginn jedes Projekts unerlässlich ist.

Der erste Schritt zum Erfolg eines Projekts besteht darin, zunächst klar zu definieren und zu vereinbaren, was und warum etwas erreicht werden soll. Obwohl dies offensichtlich erscheinen mag, starten viele Projekte mit der Entwicklung technischer Lösungen, bevor sie eindeutig festlegen und übereinstimmen, was ihre Ziele sind und aus welchen Gründen sie verfolgt werden.

Die Antworten auf die Frage ‘Warum?’ definieren den Zweck eines Projekts. ‘Was wir erreichen wollen’, bildet das Leitziel. Operative Ziele, auch Unterziele genannt, sind konkreter als das Leitziel und werden in einem späteren Stadium formuliert. Dies geschieht nach der Auswahl einer Strategie zur Erreichung des Leitziels. Da es in der Regel mehrere Wege gibt, ein Ziel zu erreichen, existieren verschiedene mögliche Strategien. Jede dieser Strategien wird durch eigene Liefergegenstände und spezifische Unterziele umgesetzt.

Lassen Sie uns zunächst auf den Zweck und das Leitziel konzentrieren. Beide leiten sich aus der Problemstellung oder der Beschreibung der Geschäftsmöglichkeit ab, welche den ersten Schritt darstellen. Wir streben ein bestimmtes Ziel an oder müssen es erreichen, WEIL es ein Problem zu lösen oder eine Geschäftsmöglichkeit zu nutzen gibt. Daher beginnen wir mit der Formulierung einer Problemstellung oder der Beschreibung einer Geschäftsmöglichkeit, unterteilt in zwei Abschnitte.

Der erste Abschnitt beschreibt den aktuellen Zustand, einschließlich der von den Stakeholdern identifizierten Problempunkte und deren Konsequenzen in Bereichen wie Finanzen, Zeit, Produktivität oder Wettbewerbsvorteil. Diese Beschreibung dient der Formulierung der Zweckserklärung, also der Klärung, warum die Organisation ein Projekt durchführen sollte. Dies kann der Fall sein, weil die identifizierten Probleme zu Kosten in Form von finanziellem Aufwand, Zeitverlust oder verminderter Produktivität führen, oder weil die Geschäftsmöglichkeit potenzielle Vorteile bietet.

Der zweite Abschnitt beschreibt den angestrebten zukünftigen Zustand, der verdeutlicht, wie die Situation aussieht, wenn eine Lösung erfolgreich implementiert worden ist. Diese Darstellung hilft uns, das zu erreichende Leitziel präzise zu formulieren.

Das Formulieren einer Problemstellung stellt oft eine Herausforderung dar, da Menschen dazu neigen, schnell zu Lösungsansätzen überzugehen. Doch das ist voreilig. In dieser Phase geht es darum, das zu lösende Problem genau zu verstehen und einen Konsens darüber zu finden, wie die Situation aussehen sollte, wenn das Problem gelöst ist.

Der Prozess der Problembeschreibung erfolgt normalerweise in einer Gruppenaktivität. Er beginnt mit einem Treffen der Stakeholder, um die problematischen Aspekte, die verbessert werden sollen, herauszuarbeiten. Eine sehr effektive Technik hierbei ist das Stellen wiederholter ‘Warum’-Fragen, bekannt als die ‘5 Warums’-Methode. Diese Technik hilft dabei, tiefer in die Ursachen des Problems einzudringen und zu erkennen, dass viele der wahrgenommenen Probleme oft nur Symptome eines tiefer liegenden Kernproblems sind.

Bei der Analyse des Problems der geringen Rentabilität haben wir mithilfe der ‘5 Warums’-Methode die niedrige Kundenbindungsrate auf ihre grundlegenden Ursachen zurückgeführt. Wir haben festgestellt, dass die Haupttreiber des Problems lange Lieferzeiten, mangelnde Transparenz bezüglich des Transaktionsstatus, Ineffizienz und Unfreundlichkeit im Kundendienst sowie Fehler bei der Berechnung der ausstehenden Forderungen sind.

Vertiefen wir das Problem ‘Mangel an Transparenz des Transaktionsstatus’ mit einer weiteren ‘Warum’-Runde, könnten die Antworten beispielsweise lauten: ‘Kunden werden nicht über den Status ihrer Bestellungen informiert, da die relevanten Informationen über verschiedene Systeme verteilt und die Arbeitsabläufe für Produkte je nach beteiligtem Lieferanten nicht einheitlich sind.’ Diese Art von Antwort führt uns zu spezifischeren Zielen, die auf die Erhöhung der Transparenz abzielen. Sie weist auf konkrete Lösungsansätze hin, wie die Konsolidierung der Informationen in einem System und die Definition klarer Arbeitsabläufe, einschließlich der Einbeziehung der Lieferanten – Aufgaben, die das bevorstehende Projekt angehen muss.

Derzeit konzentrieren wir uns darauf, den Zweck und das Leitziel zu definieren, basierend auf der umfassenden Problemstellung. Diese umfasst zwei Schlüsselelemente: Erstens, die Analyse des aktuellen Zustands mit seinen Ursachen und Konsequenzen, aus denen wir den Projektzweck ableiten. Zweitens, die Vision des gewünschten zukünftigen Zustands, aus der wir das Leitziel formulieren. Unser Bestreben ist es, ein grundlegendes Verständnis für das Hauptziel des Projekts zu entwickeln, ohne uns vorzeitig auf die Definition spezifischer Unterziele zu konzentrieren.

Ein Projekt zur Verbesserung des ‘Mangels an Transparenz des Transaktionsstatus’ könnte seine Zweckserklärung wie folgt formulieren: „Wir müssen in der Lage sein, einen genauen Status der Kunden-Transaktionen bereitzustellen, weil der aktuelle Mangel an Transparenz dazu führt, dass wir Kunden verlieren, die mit erheblichem Aufwand gewonnen wurden, und uns das jährlich einen Betrag von [x] kostet“.

Dies ist die Antwort auf die Frage des Zwecks, das “Warum” wir das Projekt machen. Die Zweckserklärung kann äußerst nützlich sein, um Orientierung zu bieten, wenn unangenehme Entscheidungen getroffen werden müssen, und allen Stakeholdern in Erinnerung zu rufen, warum wir das Projekt machen, einschließlich der Konsequenzen, wenn wir es nicht tun.

Nach der Formulierung der Zweckserklärung können wir uns der Definition des Leitziels zuwenden. Dafür beziehen wir uns auf den zweiten Teil der Problemstellung, der den gewünschten zukünftigen Zustand beschreibt. Dieser Zustand bildet das erwartete Ergebnis unseres bevorstehenden Projekts. Kurz gesagt, das ‘Was das Projekt erreichen soll’ wird definiert, indem es direkt mit der Lösung einer spezifischen Situation verknüpft wird – dem Zweck, der das Projekt motiviert.

Das Leitziel unseres Projekts könnte folgendermaßen definiert werden: “Sicherstellung einer durchgehenden Transparenz über den Status aller Transaktionen im Verlauf des Arbeitsprozesses”.

Zum Schluss ein Wort zum Unterschied zwischen Leitziel (englisch: ‘Goal’) und Unterzielen (englisch: ‘Objectives’). Oft werden beide Begriffe undifferenziert als ‘Ziel’ verwendet. Wir möchten sie jedoch unterscheiden und zwar aus einem guten Grund: Das Leitziel ist das Endergebnis, das wir erreichen möchten, während Unterziele spezifische Aktionenbündel sind, die uns zum Leitziel führen. Während wir das Leitziel unmittelbar aus der Problemstellung ableiten können, können die Unterziele erst nach der Wahl einer spezifischen Strategie zur Problemlösung definiert werden, da es gewöhnlich mehrere Optionen gibt, um ein Leitziel zu erreichen.

In unserem Beispiel besteht das Leitziel darin, „eine durchgehende Transparenz über den Status aller Transaktionen im Verlauf des Arbeitsprozesses sicherzustellen“. Unterziele, die zur Erreichung dieses Leitziels führen, könnten (abhängig von der auszuwählenden Strategie) lauten: „Konsolidierung der Informationen in einem System“ sowie „Definition und Implementierung der Arbeitsabläufe für alle Produkte, einschließlich der Beteiligung von Lieferanten“.

Durch die Konsolidierung der Informationen in einem System und die Definition sowie Implementierung der Arbeitsabläufe für alle Produkte, einschließlich der Lieferantenbeteiligung, erwarten wir, das Leitziel der Transparenz über den Status aller Transaktionen im gesamten Arbeitsablauf zu erreichen. Es ist jedoch möglich, dass weitere Unterziele definiert werden müssen, um das Leitziel der Transparenz vollständig zu realisieren.

Im Rahmen des Projektmanagementprozesses, den wir in diesem Kurs erläutern, konzentrieren wir uns derzeit noch nicht darauf, zeitbasierte spezifische Unterziele zu definieren. Dies liegt daran, dass wir uns immer noch auf einer allgemeineren Ebene befinden, während wir die Aktivitäten der Projektinitialisierung behandeln. In dieser Phase sollten der Projektzweck (englisch: purpose) und sein Leitziel (englisch: goal) formuliert werden. Wir sind der Ansicht, dass die Definition der Unterziele (englisch: objectives) zu einem späteren Zeitpunkt erfolgen sollte. Dies geschieht, da die Unterziele konkrete Aktionen sind, die zum Erreichen des Leitziels führen und von der ausgewählten Strategie abhängen. In der Regel gibt es mehrere mögliche Optionen, um ein Leitziel zu erreichen, und jede dieser Optionen hat eigene Zwischenschritte, d.h. eigene Unterziele. Daher ist es sinnvoll, die Unterziele erst nach der Festlegung der Strategie zu definieren.

In unserem Beispielprojekt, das das Leitziel der „Sicherstellung einer durchgehenden Transparenz über den Status aller Transaktionen im Verlauf des Arbeitsprozesses“ hat, könnten wir theoretisch entscheiden, zehn neue Verwaltungsmitarbeiter einzustellen, um manuell Informationen aus verschiedenen Systemen ohne klaren Arbeitsablauf zu sammeln. Dadurch würden wir das Leitziel der Transparenz des Transaktionsstatus  erreichen. Dennoch wären die erforderlichen Maßnahmen und Liefergegenstände, also die Unterziele, völlig unterschiedlich, wenn wir uns für eine Strategie entscheiden, die die Einstellung und Schulung von zehn neuen Mitarbeiter vorsieht, im Vergleich zu einer anderen Strategie, die auf die automatisierte Konsolidierung von Informationen in einem System und der Definition der Arbeitsabläufe abzielt, einschließlich der Beteiligung der Lieferanten. Unterschiedliche Strategien zur Erreichung eines Leitziels führen zu unterschiedlichen Unterzielen.

Zusammenfassend lässt sich sagen, dass der beste Weg, ein Projekt zu starten, darin besteht, zu wissen, was man erreichen will und warum.

Dies wird mit den erklärten Techniken erreicht, ist aber auch eine “Kunst” und, wie jede Kunst, erfordert sie Übung, um sie zu beherrschen.

1.8 Geschäftsanforderungen erfassen

In diesem Abschnitt geht es um die Erfassung von Geschäftsanforderungen während der Projektinitialisierung.

Laut dem Internationalen Institut für Geschäftsanalyse ist eine Anforderung die dokumentierte Darstellung eines Zustands oder einer Fähigkeit, die jeweils von einer Organisation oder einem Individuum benötigt oder gewünscht werden.

Es gibt Geschäfts- und Funktionsanforderungen. Geschäftsanforderungen definieren die neuen Fähigkeiten, die das Unternehmen durch das Projekt erlangen soll. Funktionsanforderungen hingegen beschreiben, wie die Lösung diese Geschäftsanforderungen umsetzen wird. Sie werden durch Planungsprozesse definiert, sobald ein Expertenteam verfügbar ist. Aktuell beschreiben wir die Initialisierungsprozesse, die den Planungsprozessen vorausgehen.

Im Rahmen der Initialisierungsaktivitäten konzentrieren wir uns auf Geschäftsanforderungen und bleiben auf diesem allgemeinen Niveau, weil wir zu diesem Zeitpunkt noch nicht die Funktionen und weiteren Details einer spezifischen Lösung beschreiben können und sollen.

Wir erinnern uns an das bereits besprochene Beispiel des Projekts zur Verbesserung der Transparenz des Status aller Transaktionen. Nun nehmen wir jetzt an, dass wir uns für eine Online-Lösung entschieden haben, eine Entscheidung, die in den früheren Lektionen noch offen war.

Welche neuen Fähigkeiten will das Unternehmen durch Erreichen dieses Ziels mit dieser Lösung erlangen?

Im Hinblick auf unser Projekt könnten die neuen Fähigkeiten beispielsweise folgende sein:

• Kunden ermöglichen, Bestellungen online zu tätigen, zu verfolgen und zu ändern, ohne Eingriff des Kundendienstes.
• Dem Unternehmen ermöglichen, Kunden ohne menschliches Eingreifen des Buchhaltungsdienstes zu fakturieren.
• Kunden und Unternehmen ermöglichen, eine Übersicht und Kenntnis über den Status aller Bestellungen und Rechnungen zu haben, einschließlich aller in der Vergangenheit getätigten Transaktionen.
• Kunden und Unternehmen ermöglichen, alle vergangenen Kommunikationen zwischen dem Kunden und dem Unternehmen zur Hand zu haben.
• Dem Kundendienst ermöglichen, während Telefongesprächen den anrufenden Kunden sofort zu identifizieren und alle notwendigen und wesentlichen Informationen zur Hand zu haben.

Diese Geschäftsanforderungen sind Ergebnisse des Projekts. Es handelt sich um neue Fähigkeiten, die die Organisation und die Kunden erlangen werden. Sie werden aktiviert  sobald die Lieferobjekte des Projekts in den laufenden Betrieb des Unternehmens übertragen werden. Diese Projektergebnisse sind jedoch noch nicht der Nutzen, da ein Großteil des Nutzens erst im Laufe der Zeit aus der neuen Situation entstehen werden, welche die gelieferten Projektergebnisse schaffen wird.

In unserem Beispiel ist der wesentliche postprojektive Nutzen, den wir anstreben, eine erhöhte Kundenbindungsrate. Wir erhoffen, diese durch die gesteigerte Transparenz bei Transaktionen zu erreichen, die das Gesamtergebnis der neu erworbenen Fähigkeiten des Projekts darstellt.

Wir haben in der Problemanalyse erkannt, dass allein die Transparenz der Transaktionen nicht genügt, um die Bindungsrate zu erhöhen, da es weitere Quellen der Kundenzufriedenheit gibt. Daher sollten die Ergebnisse unseres Transparenzprojekts mit den Ergebnissen anderer Projekte kombiniert werden, die sich auf die übrigen Ursachen der Unzufriedenheit konzentrieren. Unser Fallbeispiel verdeutlicht, dass Kundenzufriedenheit mehrere tiefer liegende Ursachen hat. Eine davon ist der Mangel an Transparenz bei Transaktionen, aber es gibt auch andere Gründe für Unzufriedenheit. Zum Beispiel, Fehler in Rechnungen, lange Telefonwarteschlangen, unfreundliche Gesprächsannahme und lange Lieferzeiten. Es ist daher wichtig, diese Themen in einem integrierten Projektprogramm zu adressieren, das mehrere Projekte umfasst.

Während der Meetings zur Erfassung der hochrangigen Geschäftsanforderungen, wie sie in der Initialisierungsphase üblich sind, ist es wichtig, sich auf die Einigung über die neuen Fähigkeiten zu konzentrieren, die das Unternehmen nach Implementierung des Hauptlieferobjekts erreichen möchte. In dieser Phase sollten wir nicht versuchen, die technische Umsetzung dieser Fähigkeiten zu beschreiben. Daher sind Anforderungen, die Details zu Dateien, Datenströmen, Tabellen, Indikatoren und Architektur enthalten, eher lösungsorientierte Funktionsanforderungen. Sie stellen nicht die neuen, angestrebten Unternehmensfähigkeiten dar und gelten somit nicht als Geschäftsanforderungen.

Zusammenfassend sind hochrangige Geschäftsanforderungen nicht gleichzusetzen mit technischen Funktionsanforderungen. Stattdessen repräsentieren sie die neuen Fähigkeiten, die das Unternehmen durch das Projekt für sich oder die Nutzer erwerben möchte. Diese Geschäftsanforderungen sind ein wesentlicher Teil der Definitionsaufgaben und werden in den Projektauftrag integriert.

 

 

 

 

 

 

1.9 Identifizieren, bewerten und auswählen von Strategien

In diesem Abschnitt wird erklärt, wie man potenzielle Strategien identifiziert, bewertet und die beste Option auswählt, um das Projektziel zu erreichen.

In der Regel gibt es mehrere Möglichkeiten, ein Ziel zu erreichen. Diese verschiedenen Wege zur Zielerreichung sind unterschiedliche Strategien.

Lassen Sie uns betrachten, wie wir diese potenziell verfügbaren Strategien bewerten und die beste Alternative auswählen können. Zuerst sollten Sie eine kleine Gruppe von Personen zusammenstellen, die mit dem Projekt vertraut sind, um Ideen auszutauschen. Als Gruppe sollten Sie die Problemstellung, den Zweck und das Ziel des Projekts genau studieren. Dann sollten Sie eine Brainstorming-Sitzung durchführen, um mögliche Strategien zu generieren. Die Brainstorming-Sitzung sollte ein freier Fluss von Ideen sein. Der Zweck dieser Sitzung ist es, so viele Ideen wie möglich zu sammeln, bevor Sie mit der Bewertung beginnen.

Sobald die möglichen Strategien identifiziert sind, sollten Sie mit ihrer Bewertung beginnen. Eine Entscheidungsmatrix kann hilfreich sein, um die Optionen zu vergleichen und zu bewerten, wie gut jede Alternative die festgelegten Bewertungskriterien erfüllt.

Fahren wir mit unserem Beispiel fort, bei dem das Ziel darin besteht, die Transparenz der Transaktionen für alle Produkte entlang ihrer Arbeitsabläufe zu erhöhen. Stellen wir uns vor, die Gruppe hat drei mögliche alternative Strategien identifiziert:

• Ein Online-System mit automatischer Synchronisierung.
• Ein Online-System mit Stapelverarbeitung über Nacht.
• Ein manueller Prozess mit mehr administrativem Personal.

Um diese potenziellen Strategien zu bewerten, müssen wir die Auswahlkriterien festlegen. Angenommen, die Gruppe hat die folgenden Auswahlkriterien festgelegt:

• Geschwindigkeit und Genauigkeit der von der Lösung generierten Informationen.
• Das Niveau der anfänglichen Investition.
• Die jährlichen Kosten der Lösung.
• Wie schnell die Lösung verfügbar wäre.
• Die Fähigkeit, sie mit internen Ressourcen umzusetzen.

Der nächste Schritt ist die Gewichtung der Bedeutung jedes Kriteriums. Wenn einige Kriterien wichtiger sind als andere, sollten Sie ihre Gewichtung erhöhen. Zum Beispiel ist 1 das niedrigste Gewicht für die Bedeutung, während 5 das Höchste ist.

Sie müssen auch den Maßstab festlegen, der verwendet wird, um den Grad zu bewerten, in dem ein Kriterium erfüllt wurde. Angenommen, die Gruppe entscheidet sich für eine Skala von 1 bis 5, wobei 1 das niedrigste Niveau der Erfüllung eines Kriteriums ist und 5 das höchste.

Dann setzen Sie die Alternativen, die Bewertungskriterien und die Bedeutung jedes Kriteriums in eine Matrix. Angenommen, die Kriterien “Geschwindigkeit und Genauigkeit der Informationen” und “Schnelligkeit der Lösungsverfügbarkeit” sind die wichtigsten und erhalten daher eine Höchstbewertung von 5. Das Kriterium “Jahreskosten” erhält eine Gewichtung von 4. Das Kriterium “Anfangsinvestition” erhält eine Gewichtung von 3. Und schließlich erhält das Kriterium “Fähigkeit zur Umsetzung mit internen Ressourcen” eine Gewichtung von 2.

Kriterium	Gewicht	Automatisierte Synchronisierung		Stapelverarbeitung über Nacht		Manuell
		Erfüllung	Wert	Erfüllung	Wert	Erfüllung	Wert
Geschwindigkeit und Genauigkeit der Informationen	5
Anfangsinvestition	3
Jahreskosten	4
Schnelligkeit der Lösungsverfügbarkeit	5
Fähigkeit zur Umsetzung mit internen Ressourcen	2

Dann geht das Team zur numerischen Bewertung der Erfüllung jedes Kriteriums für jede Alternative über. Das Ergebnis könnte wie folgt aussehen.

In diesem Beispiel erhält die Lösung zur Stapelverarbeitung über Nacht die höchste Punktzahl von 69. Obwohl sie im Kriterium “Geschwindigkeit und Genauigkeit der Informationen” eine niedrigere Punktzahl als die Alternative mit automatischer Synchronisierung erzielt, wird dies durch andere Kriterien überkompensiert. Zum Beispiel ist die anfängliche Investition geringer (Punktzahl von 9 für die Lösung zur Stapelverarbeitung über Nacht im Vergleich zu einer Punktzahl von 3 für die Alternative mit automatischer Synchronisierung).

Kriterium	Gewicht	Automatisierte Synchronisierung		Stapelverarbeitung über Nacht		Manuell
		Erfüllung	Wert	Erfüllung	Wert	Erfüllung	Wert
Geschwindigkeit und Genauigkeit der Informationen	5	5	25	4	20	2	10
Anfangsinvestition	3	1	3	3	9	3	9
Jahreskosten	4	5	20	4	16	1	2
Schnelligkeit der Lösungsverfügbarkeit	5	2	10	4	20	4	20
Fähigkeit zur Umsetzung mit internen Ressourcen	2	1	2	2	4	4	8
			60		69		51

Und vor allem hinsichtlich der Verfügbarkeitsgeschwindigkeit erzielt die Lösung zur Stapelverarbeitung über Nacht die doppelte Punktzahl der Alternative mit automatischer Synchronisierung.

Durch eine ähnliche Logik könnten auch für die anderen Kriterien genauere und messbare Werte festgelegt werden.

Zum Beispiel könnten wir messbare Werte für jedes Niveau von Geschwindigkeit und Genauigkeit der Informationen festlegen. Hier ist ein Beispiel. Die höchste Punktzahl von 5 wird Antworten zugeschrieben, die als sehr genau und sehr schnell angesehen werden. Und wir verteilen abnehmende Punktzahlen, je ungenauer und langsamer die Antwort des Systems ist. Wir weisen eine niedrige Punktzahl von 1 jeder Antwort zu, die als ungenau angesehen wird, unabhängig von ihrer Geschwindigkeit. Die Zwischenwerte werden mit einer angemessenen Verteilung in den Zwischenbereichen zugewiesen. Hier ist das Ergebnis der Punktzahlen, die wir erhalten werden.

	Genauigkeitsniveau der Antwort
	Ungenau 1				Präzise 5
1-5 Sekunden	1	3	4	5	5
6-10 Sekunden	1	3	4	4	5
11-15 Sekunden	1	2	3	4	4
16-20 Sekunden	1	2	2	3	3
21-25 Sekunden	1	2	2	3	3

Mit einer ähnlichen Logik könnten wir auch für die anderen Kriterien präzisere und messbare Werte definieren. Zum Beispiel, um die Punktzahlen für das Kriterium “erforderliche Anfangsinvestition” genauer zu definieren, weisen wir einen Wert von 5 einer Investition von zwischen 10.000 und 20.000 zu. Einen Wert von 4, einer Investition von zwischen 21.000 und 50.000. Und einen Wert von 1, einer Investition von zwischen 200.000 und 500.000. Das heißt: Je höher die erforderliche Investition, desto weniger Punkte erhält die Alternative.

Anfängliche Investition	200 ~ 500 k	101 ~ 200 k	51 ~ 100 k	21 ~ 50 k	10 ~ 20 k
	1	2	3	4	5
Jährlichen Kosten	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Geschwindigkeit der Lösungsverfügbarkeit	18 bis 24 Monate	12 bis 18 Monate	7 bis 12 Monate	4 bis 6 Monate	1 bis 3 Monate
	1	2	3	4	5
Umsetzung mit internen Ressourcen	Sehr unwahrscheinlich	Ziemlich unwahrscheinlich	Eher wahrscheinlich	Wahrscheinlich	So gut wie sicher
	1	2	3	4	5

Und wir fahren mit derselben Logik fort, indem wir numerisch die verschiedenen Leistungsbereiche definieren, für die Kosten pro Jahr (je höher die Kosten, desto weniger Punkte erhält die Alternative). Die Verfügbarkeitsgeschwindigkeit der Alternative (je schneller sie verfügbar ist, desto mehr Punkte erhält die Alternative). Und die Wahrscheinlichkeit der Implementierung mit internen Ressourcen (je wahrscheinlicher sie ist, desto mehr Punkte erhält die Alternative). Das Ergebnis könnte wie folgt aussehen:

Ein jährliches Betriebskostenniveau von 10.000 bis 20.000 erhält den höchsten Wert von 5. Währenddessen erhalten die Betriebskosten von 200.000 bis 500.000 einen Wert von 1. Die anderen möglichen Betriebskosten pro Jahr in den Zwischenbereichen erhalten Werte zwischen 1 und 5.

Anfängliche Investition	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Jährlichen Kosten	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Geschwindigkeit der Lösungsverfügbarkeit	18 bis 24 Monate	12 bis 18 Monate	7 bis 12 Monate	4 bis 6 Monate	1 bis 3 Monate
	1	2	3	4	5
Umsetzung mit internen Ressourcen	Sehr unwahrscheinlich	Ziemlich unwahrscheinlich	Eher wahrscheinlich	Wahrscheinlich	So gut wie sicher
	1	2	3	4	5

Dasselbe gilt für die Verfügbarkeit der Lösungsgeschwindigkeit. Wir könnten festlegen, dass eine Lösung, die innerhalb von 1 bis 3 Monaten verfügbar wäre, den Höchstwert von 5 erhält. Und eine Lösung, die 18 bis 24 Monate für die Implementierung benötigt, erhält eine niedrige Punktzahl von 1. Andere Zwischenzeiträume würden Werte zwischen dem Höchst- und dem Mindestwert erhalten.

Anfängliche Investition	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Jährlichen Kosten	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Geschwindigkeit der Lösungsverfügbarkeit	18 bis 24 Monate	12 bis 18 Monate	7 bis 12 Monate	4 bis 6 Monate	1 bis 3 Monate
	1	2	3	4	5
Umsetzung mit internen Ressourcen	Sehr unwahrscheinlich	Ziemlich unwahrscheinlich	Eher wahrscheinlich	Wahrscheinlich	So gut wie sicher
	1	2	3	4	5

Und die Wahrscheinlichkeit der Implementierung mit internen Ressourcen (je wahrscheinlicher, desto mehr Punkte erhält die Alternative).

Anfängliche Investition	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Jährlichen Kosten	200 bis 500 Tausend	101 bis 200 Tausend	51 bis 100 Tausend	21 bis 50 Tausend	10 bis 20 Tausend
	1	2	3	4	5
Geschwindigkeit der Lösungsverfügbarkeit	18 bis 24 Monate	12 bis 18 Monate	7 bis 12 Monate	4 bis 6 Monate	1 bis 3 Monate
	1	2	3	4	5
Umsetzung mit internen Ressourcen	Sehr unwahrscheinlich	Ziemlich unwahrscheinlich	Eher wahrscheinlich	Wahrscheinlich	So gut wie sicher
	1	2	3	4	5

Es ist möglich, dass die Gruppe, wenn sie präzisere Werte verwendet, um jedes Kriterium zu definieren, zu unterschiedlichen Punktzahlen gelangt, und vor allem mit weniger Diskussionen darüber, ob eine Alternative für ein bestimmtes Kriterium eine 5 oder eine 3 verdient.

Nehmen wir an, dass die Gruppe nun unter Verwendung numerisch definierter Bereiche für jedes Kriterium zu einer anderen Punktzahl gelangt, indem sie der Alternative, nächtliche Batchverarbeitung, eine 3 für die jährlichen Kosten und eine weitere 3 für die Verfügbarkeitsgeschwindigkeit der Lösung zuweist, da wir nun präzisere Werte haben, um jede Alternative zu bewerten.

Kriterium	Gewicht	Automatisierte Synchronisierung		Stapelverarbeitung über Nacht		Manuell
		Erfüllung	Wert	Erfüllung	Wert	Erfüllung	Wert
Geschwindigkeit und Genauigkeit der Informationen	5	5	25	4	20	2	10
Anfangsinvestition	3	1	3	3	9	5	15
Jahreskosten	4	5	20	3	12	1	4
Schnelligkeit der Lösungsverfügbarkeit	5	2	10	3	15	4	20
Fähigkeit zur Umsetzung mit internen Ressourcen	2	1	2	2	4	4	8
			60		60		51

In diesem Beispiel erhalten die Alternative mit automatischer Synchronisierung und die Alternative mit Stapelverarbeitung über Nacht jeweils eine Punktzahl von 60.

Das Team könnte die relativen Gewichtungen, die jedem Kriterium zugewiesen werden, neu bewerten und überlegen, ob das Kriterium “Geschwindigkeit und Genauigkeit der Informationen”, das das maximale Gewicht von 5 hat, tatsächlich so wichtig ist wie das Kriterium “Verfügbarkeitsgeschwindigkeit der Lösung”. Nehmen wir an, das Team entscheidet letztendlich, dass das Kriterium “Verfügbarkeitsgeschwindigkeit der Lösung” wichtiger ist als das Kriterium “Geschwindigkeit und Genauigkeit der Informationen”, weil eine schnellere Implementierung einer Lösung mit nächtlicher Batchverarbeitung einen früheren Wertbeitrag ermöglichen würde. Das Team denkt, dass ein nachfolgendes Projekt auf der Basis der nächtlichen Batchverarbeitungslösung aufbauen und sie in eine automatisierte Synchronisationslösung umwandeln könnte.

Dafür ändert die Gruppe das Gewicht des Kriteriums “Geschwindigkeit und Genauigkeit der Informationen”, das nun eine Wichtigkeit von 4 statt 5 erhält. Jetzt ist das wichtigste Kriterium die Verfügbarkeitsgeschwindigkeit der Lösung, mit einem Gewicht von 5.

Das Ergebnis zeigt, dass die beste Strategie darin besteht, zuerst eine Lösung mit Stapelverarbeitung über Nacht zu implementieren.

Kriterium	Gewicht	Automatisierte Synchronisierung		Stapelverarbeitung über Nacht		Manuell
		Erfüllung	Wert	Erfüllung	Wert	Erfüllung	Wert
Geschwindigkeit und Genauigkeit der Informationen	4	5	20	4	16	2	8
Anfangsinvestition	3	1	3	3	9	5	15
Jahreskosten	4	5	20	3	12	1	4
Schnelligkeit der Lösungsverfügbarkeit	5	2	10	3	15	4	20
Fähigkeit zur Umsetzung mit internen Ressourcen	2	1	2	2	4	4	8
			55		56		51

Die Strategie mit der höchsten Gesamtbewertung ist wahrscheinlich die geeignetste.

Dies ist eine Gruppenübung, die vor der detaillierten Planung einer Lösung durchgeführt werden sollte, um sicherzustellen, dass nicht nur gute Arbeit geleistet wird, sondern auch die richtige Arbeit. Andere Kriterien wie das Risikoniveau oder die Durchführbarkeit der Alternativen könnten ebenfalls in die Matrix aufgenommen werden. Zum Beispiel könnten Strategien, die neue Technologien oder unerprobte Methoden verwenden, in diesem Kriterium eine niedrigere Punktzahl erhalten. Oder wenn die Durchführbarkeit der besten Alternative in Frage zu stehen scheint, könnte das Team beschließen, eine Machbarkeitsstudie durchzuführen, um zu bestimmen, ob die Strategie genügend Chancen hat, ohne zu viel Zeit oder Geld zu binden. Dies entspricht dem, was Agile Entwicklungsmethoden als “Spike” bezeichnen, um eine Idee zu untersuchen oder zu experimentieren, bevor sie weiterentwickelt wird, um Spekulationen über eine mögliche Lösung im leeren Raum zu vermeiden.

Abhängig von der Art der Alternativen könnte auch ein Kriterium sein, ob die Strategie zur Unternehmenskultur passt. Denn der Versuch, eine Strategie durchzusetzen, die nicht zur Kultur passt, könnte zu einem schweren Kampf führen. Dies würde möglicherweise die Definition eines Projektprogramms einschließen, das ein Projekt zur Änderung der Unternehmenskultur in dieser Hinsicht enthält. Dies ist zwar keine unmögliche Aufgabe, aber sie kommt ihr nahe. In Bezug auf die kulturelle Akzeptanz einer Veränderung können wir sicherlich sagen, dass ohne die feste Verpflichtung des Managements und der Teammitglieder, Probleme auftreten können.

Zusammenfassend lässt sich sagen, dass die Bewertung alternativer Strategien uns hilft, die am besten geeignete Lösung für das Projekt auszuwählen. Dies ist eine Gruppenübung, die vor dem Einstieg in die detaillierte Planung jeder Lösung durchgeführt werden sollte, um sicherzustellen, dass wir uns nicht nur darauf konzentrieren, unsere Arbeit gut zu machen, sondern auch die richtige Arbeit zu erledigen.

 

 

1.10 Identifizierung der Schlüsselliefergegenstände

Dieser Abschnitt befasst sich mit der Identifizierung der Schlüsselliefergegenstände.

Ein Liefergegenstand ist alles, was als Ergebnis eines Prozesses produziert oder bereitgestellt wird. Um Ziele zu erreichen, müssen wir Liefergegenstände produzieren. Wenn das Projekt abgeschlossen ist, muss der Schlüsselliefergegenstand produziert und vom Kunden validiert und akzeptiert worden sein.

Der Schlüsselliefergegenstand, sei er greifbar oder nicht greifbar, ist das Element, das das Ziel des Projekts erfüllt oder erfüllen sollte. Wahrscheinlich gibt es auch Zwischenliefergegenstände, die notwendig sind, um die Unterziele zu erreichen, die zum Leitziel führen oder um das Projekt zu managen.

Die Liefergegenstände eines Projekts variieren stark von Projekt zu Projekt und von Unternehmen zu Unternehmen.

Liefergegenstände können groß oder klein sein: ein Produkt, ein Prototyp, die Fähigkeit, einen Beratungsdienst anzubieten, eine Computeranwendung, bestimmte Testergebnisse, einen Vertrag usw.

Sie können greifbar sein, wie eine Zeitschrift oder ein Telefon, oder nicht greifbar, wie eine kulturelle Veränderung oder die Verringerung von Fehlern in einem Prozess.

Normalerweise hängen die Liefergegenstände von der Fertigstellung anderer Liefergegenstände ab. Zum Beispiel werden Häuser für externe Kunden entwickelt und gebaut. Das Haus ist der Schlüsselliefergegenstand eines Wohnungsbauprojekts. Der architektonische Entwurf, um das Haus zu bauen, wird von einem Architekten erstellt und ist ein Zwischenliefergegenstand, der den Bauarbeitern hilft, ihre Bauarbeit zu leisten. Dieser architektonische Entwurf ist nicht der Schlüsselliefergegenstand aus Sicht des Endkunden oder des Projektmanagers für den Bau. Aus ihrer Sicht ist der architektonische Entwurf ein Zwischenliefergegenstand, ein Ermöglicher für einen anderen Liefergegenstand. Aber aus der Sicht des Architekten, der für den Entwurf verantwortlich ist, ist dies sein Schlüsselliefergegenstand; es ist das komplette und endgültige Produkt dessen, was für ihn ein Projekt ist, „sein Projekt“ des Entwurfs. Obwohl es aus der Sicht des Projektmanagers für den Wohnungsbau nur ein Zwischenliefergegenstand, das Produkt eines Teilprojekts oder einer Phase des Hauptprojekts ist.

In unserem Beispiel, mit dem Ziel, die Transparenz der Transaktionen entlang ihres Prozessflusses zu erhöhen, wäre der Schlüsselliefergegenstand das neue, funktionierende System sowie die damit verbundenen Prozesse und Fähigkeiten, es zu betreiben.

Die mit den Unterzielen verbundenen Zwischenliefergegenstände, die zum Leitziel führen könnten, wären zum Beispiel: ein transparenter Arbeitsablauf für jedes Produkt erstellen, ein integriertes Computersystem erstellen mit den zugehörigen Subsystemen, die Schulung für die Bediener und ein Betriebshandbuch. Es könnte auch die Erhöhung der Fähigkeiten von teilnehmenden Lieferanten und die Durchführung einer Marketingkampagne umfassen, um der Öffentlichkeit die neue Art der Verarbeitung von Transaktionen anzukündigen, sowie weitere Elemente, die noch identifiziert werden müssen, wenn die detaillierten Anforderungen während der Projektplanung gesammelt und der Umfang definiert werden. Aber es ist zu früh dafür in dieser Phase.

Wie im Modul über Zweck und Ziel erklärt, denken wir, dass die Initialisierung des Projekts zu früh für die Definition von Unterzielen ist, die spezifisch sein sollten und mit Zwischenliefergegenständen verbunden sind.

Vieles hängt davon ab, wie viel Arbeit in einem Vorprojekt geleistet wurde. Wenn die Auswahl des Projekts nicht nur eine oberflächliche finanzielle Bewertung, sondern auch eine gründliche Analyse der Alternativen und vielleicht eine Machbarkeitsstudie einer ausgewählten Alternative umfasste. In diesem Fall wäre das Projekt in zwei Projekte unterteilt: ein Vorprojekt und ein Hauptprojekt.

Das erste Projekt, also das Vorprojekt, hätte als Schlüsselliefergegenstand die ausgewählte Option, einschließlich einer technischen Studie ihrer Machbarkeit. Das zweite Projekt würde initiiert, um diese bereits ausgewählte Lösung zu implementieren, die aus einer detaillierten Arbeit resultiert, was es uns ermöglichen würde, wahrscheinlich während der Initialisierung nicht nur den Zweck und das Leitziel, sondern auch spezifische Unterziele zu definieren, die zum Leitziel führen und mit Zwischenliefergegenständen verbunden sind, die den Schlüsselliefergegenstand bilden.

Schließlich, wenn Sie der Projektmanager sind, würde Ihre Liste der Liefergegenstände auch einige Dokumente umfassen, die dem Management des Projekts helfen. Zum Beispiel ein Projektauftrag, ein Projektmanagementplan mit Nebenplänen, Vorlagen für Berichte usw. Diese Elemente sind auch Liefergegenstände, und zwar, notwendige Liefergegenstände für das Management. Neuerdings neigt man dazu, diese Art von Management-Liefergegenstände als „Artefakte“ zu bezeichnen, und nicht alle werden mit dem Endkunden geteilt.

Zusammenfassend lässt sich sagen, dass wir Liefergegenstände produzieren müssen, um das Leitziel und die Unterziele eines Projekts zu erreichen. Die Liefergegenstände können in Größe, Greifbarkeit und Umfang variieren, und ihre Fertigstellung hängt oft von der Fertigstellung anderer Zwischenliefergegenstände ab. Der Schlüsselliefergegenstand ist das Endprodukt, das das Leitziel des Projekts erfüllt. Dokumente und Pläne, die für das Management des Projekts notwendig sind, sind ebenfalls Liefergegenstände und können auch Artefakte bezeichnet werden. Viele davon sind für den internen Gebrauch des Managementteams bestimmt.

 

 

1.11 Definition der Erfolgskriterien des Projekts

In diesem Abschnitt erläutern wir die Erfolgskriterien eines Projekts, deren Definition sowie deren Zweck.

Ein wesentliches Problem bei der Bewertung des Projekterfolgs besteht darin, dass die Kriterien für diese Bewertung oftmals unklar bleiben. Diese Unklarheit erlaubt unterschiedliche Interpretationen aus verschiedenen Perspektiven, was eine ernsthafte Gefahr für Ihre Karriere darstellen kann. Der Erfolg der Projekte, deren Management uns anvertraut wurde, kann schließlich ein Sprungbrett für den beruflichen Aufstieg sein.

Aber gibt es eine eindeutige Definition für den Erfolg eines Projekts?

Im Laufe der Jahre haben sich die gängigen Definitionen des Projekterfolgs weiterentwickelt. Zu Beginn des Projektmanagements wurde der Projekterfolg ausschließlich in technischen Begriffen gemessen, basierend darauf, ob der Schlüsselliefergegenstand funktionierte oder nicht.

Später erweiterte sich diese Perspektive, um zusätzliche Aspekte wie die Fertigstellung des Projekts innerhalb des vorgegebenen Zeitplans, des Budgetrahmens und auf einem akzeptablen Qualitätsniveau zu berücksichtigen. Diese Elemente sind als die ‘Dreifach-Beschränkung’ bekannt. Diese erweiterte Definition des Projekterfolgs wurde und wird auch heute noch weitgehend als die vorherrschende Auffassung von Projekterfolg angesehen.

Neuere Interpretationen des Projekterfolgs vertreten eine noch umfassendere Sichtweise. Diese erweitert die Erfolgskriterien um Aspekte wie die Kundenzufriedenheit in Bezug auf die Zusammenarbeit mit dem Projektteam. Dabei werden Fragen berücksichtigt wie: Wie effektiv wurden Probleme gelöst? Und wie effizient gestaltete sich die Kommunikation?

In den letzten Jahren sind zusätzlich weitere sogenannte ‘weiche Kriterien’ in die Bewertung des Projekterfolgs eingeflossen. Dazu gehören Faktoren wie das Ausmaß der Störungen im betrieblichen Arbeitsablauf der Organisation sowie das Maß an kulturellem Stress, dem die Organisation im Zuge des Projekts ausgesetzt war.

Darüber hinaus hat die Entwicklung in den Disziplinen des Programm- und Portfoliomanagements neue Perspektiven auf die Beurteilung des Projekterfolgs eröffnet.

Im Rahmen des Programmmanagements liegt der Fokus auf der Realisierung des Nutzwerts. Dies spiegelt die spezifische Sichtweise des Programmmanagements wider. Aus der Perspektive des Portfoliomanagements wird der Projekterfolg hingegen daran gemessen, inwieweit die Ziele der Organisation erreicht werden. Diese Art von Erfolgskriterien basiert auf Ansätzen, die sich auf die Umsetzung der organisatorischen Strategie konzentrieren.

Man könnte also annehmen, dass es zunehmend schwieriger wird, Projekterfolg zu definieren. Und in der Tat, Sie liegen richtig. Aber wie definiert man nun den Erfolg eines Projekts?

Viele Menschen tendieren dazu, den Erfolg eines Projekts anhand der Realisierung seines Nutzwerts zu bewerten. Sie argumentieren, dass ein Projekt erfolgreich ist, wenn der erwartete Nutzwert realisiert wird. Wie wir jedoch gesehen haben, werden zumindest einige Aspekte dieses Nutzwerts aus Kundensicht erst erzielt, nachdem das Projekt die Lösung an den Endkunden übergeben hat und dieser sie in Gebrauch nimmt. Erst ab diesem Zeitpunkt beginnt das Projekt, diesen Teil des Nutzwerts an den Endkunden zu liefern. Diese Betrachtungsweise führt zu einer Definition von Erfolg, die erst nach Abschluss des Projekts vollständig bewertet werden kann. Solche Bewertungen sind post-mortem, also nach Projektabschluss.

Sollen wir wirklich zwei Jahre warten, nachdem die Online-Lösung zur Steigerung der Transparenz in Transaktionen implementiert wurde, um dann zu beurteilen, ob die Kundenbindung tatsächlich gestiegen ist? Ein solches Warten wäre für ein Projektteam, das sich nach der Übergabe der Lösung an die Betriebsabteilung auflöst, zu spät. Neben den post-mortem Bewertungen ist es daher notwendig, eine Einschätzung des Erfolgs oder Misserfolgs am Ende des Projekts vorzunehmen. Letztendlich sollte diese Bewertung ein integraler Bestandteil eines guten Projektabschlusses sein.

Hier ist eine mögliche Lösung: Als Teil der Projektdefinition, also im Rahmen der Initialisierungsaktivitäten, können wir ein Set von Erfolgskriterien erstellen, die auf der klassischen ‘Dreifach-Beschränkung’ basieren – Lieferung innerhalb des Zeitplans, innerhalb des definierten Budgets und unter Einhaltung eines akzeptablen Qualitätsniveaus. Zusätzlich zu diesen Elementen könnten wir weitere Indikatoren einbeziehen, wie die Kundenzufriedenheit mit dem gelieferten Produkt und den Arbeitsstil des Projektteams. Es ist zwar möglich, auch einige der zuvor erwähnten anspruchsvolleren Kriterien zu berücksichtigen, doch ist es wichtig, das Projekt-Dashboard nicht mit zu vielen Metriken zu überladen. Denken Sie daran, dass jede definierte Metrik gesammelt, analysiert, interpretiert und kommuniziert werden muss.

Das Folgende ist ein Beispiel für ein Projekt-Dashboard, das den Erfolg klar messen soll:

• Pünktliche Lieferung: Gemessen am geplanten Fertigstellungsdatum in der letzten genehmigten Version des Projektmanagementplans im Vergleich zum tatsächlichen Lieferdatum oder der endgültigen Akzeptanz.
• Gemäß Budget: Gemessen an den geplanten Kosten im Vergleich zu den tatsächlichen Kosten.
• Akzeptables Qualitätsniveau: Hier ist eine detailliertere Definition erforderlich. Zum Beispiel könnten wir fragen: Wurden alle obligatorischen Anforderungen erfüllt? Wurden mindestens 80% der als empfohlen eingestuften Anforderungen erfüllt? Um ein noch höheres Qualitätsniveau anzustreben, könnten wir auch die Erfüllung eines gewissen Anteils optionaler Anforderungen einbeziehen, zum Beispiel 20%. Beachten Sie, dass wir zu diesem Zeitpunkt noch nicht wissen, welche spezifischen funktionalen Anforderungen und Qualitätsattribute die Lösung und ihre Komponenten haben werden. Jedoch können wir diese in Kategorien wie obligatorisch, empfohlen und optional einteilen. Geschäftsanforderungen würden in die Kategorie der obligatorischen Anforderungen fallen.

Mit diesen Elementen wären die klassischen Komponenten der ‘Dreifach-Beschränkung’ abgedeckt. Dies wird für viele Projekte als ausreichend erachtet. Wenn Sie jedoch zu anspruchsvolleren Kriterien übergehen möchten, könnten Sie Aspekte der Kundenzufriedenheit berücksichtigen. Dabei geht es nicht nur um die Zufriedenheit mit der gelieferten Lösung, sondern auch um die Beurteilung des Arbeitsstils des Projektteams.

Letztlich ist es möglich, unterschiedliche Gewichtungen für jedes Kriterium festzulegen. Sind beispielsweise Kosten oder Fristen ebenso wichtig wie die Qualität? Und sollten diese Kriterien das gleiche Gewicht erhalten? Das kann je nach Fall unterschiedlich sein. Ebenso könnte gefragt werden, ob die allgemeine Kundenzufriedenheit mit dem Arbeitsstil des Teams wichtiger ist als die anderen Kriterien. Auch hier lautet die Antwort: Es kommt darauf an. Diese Bewertungen hängen von den spezifischen Umständen Ihres Projekts und den Präferenzen des Sponsors, des Kunden sowie der ausführenden Organisation ab. Eine ausdrückliche Vereinbarung mit den wichtigsten Interessengruppen ist hierbei entscheidend.

Zusammenfassend lässt sich sagen, dass klare und quantifizierbare Erfolgskriterien für das Projekt bereits während der Initialisierungsaktivitäten definiert werden sollten. So vermeidet man Unklarheiten bis zum Ende des Projekts in der Hoffnung, dass es als erfolgreich angesehen wird.

1.12 Allgemeine Risiken, Annahmen und Einschränkungen identifizieren

Dieser Abschnitt wird Ihnen helfen zu verstehen, was allgemeine Risiken, Annahmen und Einschränkungen sind und wie sie als Teil der Projektdefinition während des Initiierungsprozesses identifiziert werden können.

Aber zuerst erinnern wir uns, wo sind wir jetzt im allgemeinen Prozess?

Wir sind noch nicht dabei das Projekt zu planen. Der Beginn der detaillierten Planung unseres Projekts setzt die Genehmigung des Projektantrags voraus. Aktuell beschäftigen wir uns mit Initiierungsaktivitäten, mit denen wir die wesentlichen Elemente zusammenstellen, die in den Projektantrag aufgenommen und noch genehmigt werden sollen. Erst nachdem der Projektantrag genehmigt wurde, werden wir mit der detaillierten Planung des Projekts beginnen

Bevor wir mit der detaillierten Planung beginnen, müssen wir zunächst Annahmen treffen und mögliche Einschränkungen erkennen, die für das Projekt relevant sind. Diese Einschränkungen müssen in der Planung berücksichtigt werden. Weiterhin ist es wichtig, allgemeine Risiken zu identifizieren, die schon in dieser frühen Phase erkennbar sind. Zu diesem Zeitpunkt ist es noch zu früh, um spezifische Risiken zu identifizieren, die mit noch nicht definierten Elementen des Projekts zusammenhängen. Jedoch ist es möglich und sinnvoll, typische Risiken, die mit der Art des Projekts verbunden sind, das wir gerade initiieren, zu erkennen und zu berücksichtigen.

Lassen Sie uns zunächst verstehen, was Risiken, Annahmen und Einschränkungen genau sind.

Risiken und Annahmen.

Ein Risiko ist ein potentielles zukünftiges Problem, das noch nicht eingetreten ist. Einige Methoden sprechen auch von positiven Risiken, die wir vorziehen als Gelegenheiten zu bezeichnen.

Ein Risiko bezieht sich auf zukünftige Bedingungen oder Umstände, die einen negativen Einfluss auf das Projekt haben könnten. Aber um als Risiko und nicht als Fakt betrachtet zu werden, muss ein gewisses Maß an Unsicherheit darüber bestehen, ob sie eintreten werden oder nicht. Wenn diese Umstände zu 100% sicher sind, sind sie keine Risiken, sondern Tatsachen.

Annahmen sind Aussagen, die für die Initiierung oder Planung des Projekts als wahr angenommen werden. Sie beinhalten die ausdrückliche Erwartung, dass benötigte Ressourcen oder Umstände verfügbar sein werden oder dass bestimmte schädliche Umstände nicht eintreten werden.

Wie Sie sehen können, können sich Annahmen und Risiken annähern. Wenn Sie ein mögliches zukünftiges negatives Ereignis als Annahme klassifizieren, gehen Sie davon aus, dass es nicht eintreten wird. Aber wenn dieses negative Ereignis letztendlich eintritt, dann wissen wir, dass es in Wirklichkeit keine Annahme, sondern ein Risiko war, für das mehr und besser hätte getan werden müssen, als einfach anzunehmen, dass es nicht eintreten würde.

Nehmen wir das Beispiel einer Aussage, die in viele Projektaufträge aufgenommen wird, nämlich: dass die für das Projekt erforderlichen Ressourcen nach Bedarf verfügbar sein werden. Was für eine Art von Aussage ist das? Die meisten Menschen würden sagen, es ist eine Annahme. Schließlich geht man bei Projektbeginn immer davon aus, dass man die benötigten Ressourcen bekommt.

Aber ist das wirklich eine Annahme? Wäre es nicht vorstellbar, dass es ein Projekt gibt, für das die erforderlichen Ressourcen nicht rechtzeitig verfügbar sein könnten? Vielleicht weil diese Ressourcen noch in einem anderen Projekt gebunden sind, das vorher abgeschlossen werden sollte, aber Probleme hatte und verzögert ist. Es ist nicht allzu schwer, sich dieses Szenario vorzustellen. In diesem Fall wäre die Aussage über die Verfügbarkeit der Ressourcen sicherlich ein Risiko und keine Annahme.

Der entscheidende Punkt ist, dass dieselbe Aussage je nach den Umständen des besonderen Projekts eine Annahme oder ein Risiko sein kann. Der Unterschied zwischen einer Annahme und einem Risiko besteht darin, ob die Kombination aus Wahrscheinlichkeit und Auswirkung für Sie akzeptabel ist oder nicht. Wenn die Kombination aus Wahrscheinlichkeit und Auswirkung des negativen Ereignisses für Sie nicht akzeptabel ist, das heißt, wenn die Kombination zu hoch ist, müssen die negativen Umstände als Risiko deklariert werden. Wenn das Ereignis negativ ist, aber die Kombination aus Wahrscheinlichkeit und Auswirkung akzeptabel ist, kann das Ereignis als Annahme betrachtet werden.

 

 

Sind die folgenden Aussagen Annahmen oder Risiken?

• Der Projektsponsor wird dem Projekt eine starke und aktive Unterstützung bieten.
• Die Online-Infrastruktur wird rechtzeitig vom Anbieter installiert, bevor wir für die abschließenden Tests bereit sind.

Je nach Projekt könnten beide Aussagen ein hohes Risiko darstellen, aufgrund ihrer potenziell signifikanten Auswirkungen auf den Projekterfolg, wenn sie nicht eintreten. Aber je nach Projekt könnte auch die Wahrscheinlichkeit des Eintretens als hoch genug angesehen werden, dass dieselben potenziellen Umstände als Annahmen klassifiziert werden könnten.

Während wir das Projekt initiieren, werden einige Unbekannte als Annahmen und andere als Risiken definiert werden.

Wir sind noch nicht in der Lage, eine detaillierte Risikoanalyse durchzuführen. Aber sicherlich können wir einige typische Risiken der Art von Projekt identifizieren, die wir durchführen, und wir müssen sie identifizieren.

Inhärente Risiken.

Die inhärenten Risiken sind jene, die aus den allgemeinen Merkmalen des Projekts entstehen.

Hier sind einige Beispiele.

Eigenschaft	Hohes Risiko	Niedriges Risiko
Gesamtarbeitsaufwand	Großes Projekt, z.B. > 20.000 Personenstunden	Kleines Projekt < 250 Stunden
Dauer	Mehr als 12 Monate	Weniger als 3 Monate
Teamgröße	Mehr als 25 Mitglieder	Weniger als 5
Anzahl der beteiligten Organisationen	Mehr als drei	Eine
Projektumfang	Schlecht definiert	Gut definiert
Vorteile	Nicht klar	Gut definiert
Anforderungen	Komplex, schwierig für den Kunden zu definieren	Klar, leicht für den Kunden zu definieren
Abhängigkeit von anderen Projekten oder externen Teams	Abhängig von drei oder Mehr Projekten oder externen Teams	Nicht mehr als eine Abhängigkeit von einem Projekt oder externen Team
Projektsponsoring	Unbekannt, passiv	Identifiziert und enthusiastisch
Notwendige Änderungen in bestehenden Verfahren, Prozessen und Richtlinien	Viele Änderungen	Wenig Änderung
Erfahrung des Projektdirektors	Wenig Erfahrung in Ähnlichen Projekten	Erfahrung in mehreren ähnlichen Projekten
Physischer Standort des Teams	Das Team ist über mehrere Standorte verteilt	Das Team befindet sich physisch am selben Ort
Technologie	Neue Technologie wird für kritische Komponenten verwendet	Keine neue Technologie erforderlich
Lieferant	Noch nie mit dem Lieferanten gearbeitet	Bewährter Lieferant

Gesamtaufwand in Stunden.

Gesamtarbeitsaufwand	Großes Projekt, z.B. > 20.000 Personenstunden	Kleines Projekt < 250 Stunden

Wenn das Projekt groß ist, zum Beispiel mit mehr als 20.000 Arbeitsstunden, wäre es eine Quelle hohen Risikos. Im Gegensatz dazu wäre ein kleines Projekt, sagen wir weniger als 250 Stunden, ein geringes Risiko.

Dauer.

Dauer

Mehr als 12 Monate

Weniger als 3 Monate

Mehr als 12 Monate, hohes Risiko.

Weniger als 3 Monate, geringes Risiko.

Teamgröße.

Teamgröße	Mehr als 25 Mitglieder	Weniger als 5

Mehr als 25 Projektteammitglieder, hohes Risiko.

Weniger als 5 Teammitglieder, geringes Risiko.

Das Gleiche gilt für die Anzahl der beteiligten Organisationen.

Anzahl der beteiligten Organisationen

Mehr als drei

Eine

Beachten Sie, dass die hier genannten Zahlen nur Beispiele sind und nicht für alle Projekte als gegeben angesehen werden sollten.

Sagen wir, wenn mehr als 3 Organisationen beteiligt sind, wäre das eine Quelle hohen Risikos. Im Gegensatz dazu, wenn nur eine Organisation beteiligt ist, wäre das ein Faktor geringen Risikos.

Allerdings, wenn diese Organisation chaotisch ist, wäre es eine Quelle hohen Risikos. Aber in diesem Fall ist das zu bewertende Kriterium nicht die Anzahl der beteiligten Organisationen, sondern die Qualität der von der ausführenden Organisation eingeleiteten Prozesse, und das ist etwas anderes.

Projektumfang.

Projektumfang

Schlecht definiert

Gut definiert

Wenn der Umfang des Projekts schlecht definiert ist, ist das eindeutig eine Quelle hohen Risikos.

Im Gegensatz dazu, wenn der Umfang des Projekts gut definiert ist und diese Definition von den wichtigsten Stakeholdern geteilt und akzeptiert wurde, ermöglicht uns dieser Aspekt, uns wohler zu fühlen.

Was ist mit den Nutzwert aus dem Projekt?

Vorteile

Nicht klar

Gut definiert

Wenn der Nutzwert des Projekts nicht klar ist, ist es eine Quelle hohen Risikos. Oder vielleicht sollte das Projekt überhaupt nicht initiiert werden, bis Klarheit über den zu erbringenden Nutzwert besteht. Erinnern wir uns, dass der Nutzwert das Gegenstück sind, um die Kosten für die Durchführung des Projekts zu rechtfertigen. Wenn der Nutzwert nicht klar ist und die finanzierende Organisation eine Kostensenkungsphase durchlaufen muss, sind die ersten Kandidaten, die gestrichen werden, Projekte, deren Nutzen nicht klar ist.

Andererseits, wenn der Nutzwert des Projekts klar ist, können wir annehmen, dass dies eine Quelle geringen Risikos für das Projekt ist.

Anforderungen.

Anforderungen

Komplex, schwierig für den Kunden zu definieren

Klar, leicht für den Kunden zu definieren

Wenn die Anforderungen komplex, unklar oder schwer für den Kunden zu definieren sind, ist dies eine typische Quelle hohen Risikos. Der Kunde weiß nicht, was er will. Oder es ist schwierig für sie, es in Worte zu fassen. Dies ist eine sehr häufige Situation bei Projekten mit immateriellen Produkten. Eine typische Antwort auf diese Art von hohem Risiko ist die Verwendung agiler Methoden, die eine schrittweise Definition der Anforderungen ermöglichen.

Das Gegenteil ist eine Situation, in der die Anforderungen klar sind und es für den Kunden leicht ist, sie zu definieren. Dies sollte eine Situation geringeren Risikos sein.

Abhängigkeit von anderen Projekten oder externen Teams.

Abhängigkeit von anderen Projekten oder externen Teams

Abhängig von drei oder mehr Projekten oder externen Teams

Nicht mehr als eine Abhängigkeit von einem Projekt oder externen Team

Wenn der Zeitplan unseres Projekts von der rechtzeitigen Fertigstellung oder dem Fortschritt von beispielsweise 3 oder mehr Projekten oder mehr als 3 externen Teams abhängt, ist dies eine Quelle hohen Risikos, einfach weil wir weniger Einfluss auf die externen Teams haben.

Im Gegenteil, wenn unser Projekt von nur einem anderen Projekt oder einem einzigen externen Team abhängt, können wir davon ausgehen, dass das mit diesem Faktor verbundene Risikoniveau niedrig ist. Oder vielleicht mittel, wobei es niedrig ist, wenn keine Abhängigkeit von einem externen Projekt oder einem externen Team besteht.

Projektsponsoring.

Projektsponsoring

Unbekannt, passiv

Identifiziert und enthusiastisch

Dies ist entscheidend. Wenn der Sponsor unbekannt, passiv, zeitlich eingeschränkt für das Projekt ist oder wenn der Sponsor kein Interesse am Projekt hat, ist dies eine Quelle hohen Risikos. Es ist fast sicher, dass das Projekt scheitern wird. Daher wird in einem solchen Fall empfohlen, das Projekt nicht zu starten. Alternativ könnte man einen Vertreter des Sponsors suchen, der sich mit dem erforderlichen Engagement um das Projekt kümmern kann.

Andererseits, wenn der Projektsponsor identifiziert ist, das angemessene Maß an Autorität in der sponsernden Organisation hat und hoch motiviert ist, das Projekt zu unterstützen, ist dies eine Quelle geringen Risikos. Es ist sogar eine Chance, die genutzt werden kann.

Nächster Punkt: Anzahl und Komplexität der vom Projekt erforderlichen Änderungen an bestehenden Verfahren, Prozessen und Richtlinien.

Notwendige Änderungen in bestehenden Verfahren, Prozessen und Richtlinien

Viele Änderungen

Wenig Änderung

Wir müssen realistisch sein. Wenn unser Projekt erfordert, dass sich eine große Anzahl von Dingen in der Organisation ändert, ist dies eine Quelle hohen Risikos. Je nach Fall kann angenommen werden, dass die Organisation möglicherweise nicht bereit ist, die notwendigen Änderungen vorzunehmen, und dies wird sich negativ auf das Projekt auswirken. Daher wäre dieser Aspekt eine Quelle hohen Risikos.

Andererseits, wenn nur wenige Änderungen an bestehenden Verfahren, Prozessen und Richtlinien erforderlich sind, wäre dies ein Element geringen Risikos.

Es gibt einen Risikofaktor, bei dem der Projektleiter die Quelle des Risikos ist. Es ist die Erfahrung des Projektleiters.

Erfahrung des Projektmanager

Wenig Erfahrung in ähnlichen Projekten

Erfahrung in mehreren ähnlichen Projekten

Wenn er wenig Erfahrung in dieser Art von Projekten hat, ist das offensichtlich ein Faktor hohen Risikos, und wenn er viel Erfahrung in dieser Art von Projekten hat, ist es ein Faktor geringen Risikos.

Ja, Sie verstehen richtig: Der Projektleiter kann eine Quelle hohen Risikos sein.

Was tun wir in diesem Fall? Nun, geben wir ihm eine Methode des Projektmanagements, eine firmeneigene Methode zum Beispiel, schicken wir ihn zur Schulung, oder wir bieten ihm einen Coaching-Service eines erfahrenen Projektleiters an.

Das sind Antworten auf die Risiken. Mehr dazu in der Lektion über das Risikomanagement.

Ein weiterer Faktor: die physische Lage des Teams.

Physischer Standort des Teams

Das Team ist über mehrere Standorte verteilt

Das Team befindet sich physisch am selben Ort

Im Falle einer Streuung, hohes Risiko.

Wenn alle am gleichen Ort sind, geringes Risiko.

Die zu verwendende Technologie kann auch eine Risikoquelle sein.

Technologie

Neue Technologie wird für kritische Komponenten verwendet

Keine neue Technologie erforderlich

Wenn die Technologie für das Projektteam neu ist, ist dies eine Quelle hohen Risikos.

Und umgekehrt, wenn das Team mit der zu verwendenden Technologie vertraut ist, wäre dies ein Faktor geringen Risikos.

Und schließlich der Lieferant oder die Lieferanten.

Lieferant

Noch nie mit dem Lieferanten gearbeitet

Bewährter Lieferant

Ist der Lieferant uns unbekannt? Wenn ja, könnte dies ein hohes Risiko sein.

Im Gegenteil, wenn der Lieferant uns und auf dem Markt als zuverlässiger und leistungsstarker Dienstleister bekannt ist, können wir dies als Element geringen Risikos behandeln.

Eigenschaft	Hohes Risiko	Niedriges Risiko
Gesamtarbeitsaufwand	Großes Projekt, z.B. > 20.000 Personenstunden	Kleines Projekt < 250 Stunden
Dauer	Mehr als 12 Monate	Weniger als 3 Monate
Teamgröße	Mehr als 25 Mitglieder	Weniger als 5
Anzahl der beteiligten Organisationen	Mehr als drei	Eine
Projektumfang	Schlecht definiert	Gut definiert
Vorteile	Nicht klar	Gut definiert
Anforderungen	Komplex, schwierig für den Kunden zu definieren	Klar, leicht für den Kunden zu definieren
Abhängigkeit von anderen Projekten oder externen Teams	Abhängig von drei oder Mehr Projekten oder externen Teams	Nicht mehr als eine Abhängigkeit von einem Projekt oder externen Team
Projektsponsoring	Unbekannt, passiv	Identifiziert und enthusiastisch
Notwendige Änderungen in bestehenden Verfahren, Prozessen und Richtlinien	Viele Änderungen	Wenig Änderung
Erfahrung des Projektdirektors	Wenig Erfahrung in Ähnlichen Projekten	Erfahrung in mehreren ähnlichen Projekten
Physischer Standort des Teams	Das Team ist über mehrere Standorte verteilt	Das Team befindet sich physisch am selben Ort
Technologie	Neue Technologie wird für kritische Komponenten verwendet	Keine neue Technologie erforderlich
Lieferant	Noch nie mit dem Lieferanten gearbeitet	Bewährter Lieferant

Auf der Grundlage dieser allgemeinen anfänglichen Analyse kann der Sponsor Entscheidungen über das allgemeine Design des Projekts treffen. Einschließlich Ziel und Strategie, wenn das Risikoniveau zu hoch erscheint.

Einschränkungen.

Lassen Sie uns ein wenig über Einschränkungen sprechen.

Einschränkungen sind Beschränkungen, die außerhalb der Kontrolle des Projektteams liegen und gesteuert werden müssen.

Einschränkungen sind nicht unbedingt Probleme. Noch sind sie Risiken, da sie 100% sicher sind. Einschränkungen sind Tatsachen. Datumsbeschränkungen zum Beispiel. Bestimmte Ereignisse (zum Beispiel ein Meilenstein, eine Phase oder das Ende des Projekts) müssen zu bestimmten Daten stattfinden. Zum Beispiel: ein Projekt, das zur Teilnahme an einer Handelsmesse oder einer internationalen Ausstellung mit einem neuen Produkt bestimmt ist. Die Messe wird nicht warten, bis wir das neue Produkt fertiggestellt haben. Das Datum der Messe ist eine zu beachtende Einschränkung.

Es ist möglich, dass das Projekt Ressourcenbeschränkungen hat. Zum Beispiel nicht mehr als x Anzahl von Personen. Oder die Hälfte des Teams muss französischsprachig sein, oder von einem bestimmten Geschlecht. Oder: Freitage sind Feiertage. All diese Beispiele sind Einschränkungen, die während der Planung zu beachten sein werden.

Es könnte eine Budgetbeschränkung geben. Zum Beispiel: das Projekt darf x Betrag an Geld nicht überschreiten. Dies bedeutet, dass Sie einen Umfang planen müssen, der sich dieser Einschränkung anpasst. Oder wenn nach der Definition des endgültigen Inhalts des Projekts, später während der Planung, das Team zu dem Schluss kommt, dass der erforderliche Umfang, um das Ziel zu erreichen, die finanzielle Einschränkung  überschreitet, dann muss verhandelt werden. Entweder muss die finanzielle Einschränkung erhöht werden, oder das Ziel und der damit verbundene Umfang, oder beide Elemente müssen möglicherweise nach unten angepasst werden.

Fassen wir zusammen, indem wir sagen, dass die Identifizierung allgemeiner Risiken, Annahmen und Einschränkungen ein wichtiger Schritt in der Definition eines Projekts ist, bevor es genehmigt werden kann. Wir sprechen noch nicht von einer detaillierten Planung.

 

 

1.13 Teilnahme an der Entwicklung des Projektauftrags und Genehmigung durch den Projektsponsor

Diese Sektion beleuchtet den Abschluss der Definitionsphase des Projekts. Sie sammelt die während der Anfangsphase erarbeiteten Informationen, um sie in der Projektauftrag festzuhalten. Dieses Dokument etabliert eine neue, zuvor nichtexistierende temporäre Organisation: das so genannte „Projekt X“.

Der Prozess der Projektdefinition ist nun vollendet. Alle in der Anfangsphase erarbeiteten und gesammelten Informationen werden in einem einzigen Dokument zusammengefasst, der Projektauftrag. Die Genehmigung dieser Urkunde markiert den Gründungsakt des Projekts. Sie wird den relevanten Interessengruppen mitgeteilt und ebnet den Weg für die Planungsaktivitäten.

Der Zweck, ein Projekt zu definieren und die Definitionsarbeit in einem einzigen Dokument zu konsolidieren, liegt darin, dem Sponsor oder dem Projektsteuerungsgremium alle notwendigen Informationen für die Projektgenehmigung zu liefern.

Es gibt drei mögliche Ergebnisse des Genehmigungsprozesses für den Projektauftrag: Entweder wird der Projektvorschlag vom Steuerungsgremium genehmigt und kann in eine Phase der Detailplanung übergehen, oder das Gremium fordert eine Überarbeitung und erneute Vorlage des Projektauftrags an. Das dritte mögliche Ergebnis ist eine Ablehnung durch das Steuerungsgremium, wodurch das Projekt im aktuellen Zyklus nicht weiterverfolgt wird.

Normalerweise enthält eine Projektgründungsurkunde folgende Informationen:

• Den Namen des Projekts,
• Den Zweck und das Leitziel des Projekts, also was das Projekt erreichen soll und warum,
• Das Hauptlieferobjekt, das heißt, was das Projekt schaffen wird, um das Leitziel zu erreichen, sowie die erwarteten Ergebnisse,
• Die Geschäftsanforderungen und Erfolgskriterien des Projekts,
• Allgemeine Risiken, Annahmen und Einschränkungen,
• Gegebenenfalls einen Meilensteinplan oder einen allgemeinen Fahrplan,
• Vorab genehmigte Finanzmittel oder Budgeteinschränkungen, falls vorhanden,
• Die Liste der wichtigsten Stakeholder,
• Ein Organigramm, das zeigt, wie das Projektorganigramm in die Struktur der sponsernden Organisation oder Organisationen passt.

Es ist wichtig zu verstehen, dass der Projektauftrag nicht mit dem Projektmanagementplan gleichzusetzen ist. Der Projektauftrag bündelt Informationen und Entscheidungen, die im Zuge des Initialisierungsprozesses gemacht wurden. Er legt den Grundstein für das Projekt und überführt eine Projektidee in eine von der sponsernden Organisation offiziell anerkannte, wenn auch temporäre Struktur um, die durch die Gründungsurkunde, der genehmigte Projektauftrag ins Leben gerufen wird. Aber die Unterzeichnung des Projektauftrags bedeutet nicht, dass es kein Planungsprozess notwendig wäre. Denn bevor das Projekt ausgeführt werden kann, bedarf es weiterer detaillierter Informationen und Entscheidungen, die im Rahmen der Projektplanung getroffen werden müssen. Die Erstellung der Gründungsurkunde, also des Projektauftrags, ist dennoch ein entscheidender Meilenstein. Er definiert die wichtigsten Merkmale der temporären Organisation „Projekt X“ und bestimmt den Projektmanager und den Sponsor dieser neuen Organisation.

Der Projektauftrag definiert den Projektmanager und das Niveau seiner Autorität. Diese Autoritätsdefinition umfasst in der Regel die Befugnis, Unterstützung von verschiedenen Abteilungen zu ersuchen und ein anfängliches Team zu formieren. Darüber hinaus kann der Umfang seiner Autorität weitere spezifische Elemente beinhalten, deren Ausmaß im Einzelfall festgelegt wird. Ein weit gefasstes Autoritätsniveau könnte Bestellungen bei Lieferanten einschließen oder selbst Änderungen bis zu einem zu definierenden Grad zu genehmigen, ohne dabei den Projektsponsor konsultieren zu müssen. Es ist jedoch wichtig zu betonen, dass abgesehen von der grundsätzlichen Befugnis, Unterstützung anzufordern, die weiteren Elemente und deren Ausmaß je nach Projektauftrag variieren können und nicht in jedem Fall alle genannten Befugnisse umfassen müssen.

In großen Projekten, insbesondere wenn verschiedene Organisationen beteiligt sind und ein Projektsteuerungsgremium eingesetzt wird, ist es sinnvoll, die Grenzen der Sponsorenautorität klar zu definieren. Bis zu welcher Grenze darf der Sponsor allein entscheiden, und ab wann muss er das Projektsteuerungsgremium konsultieren? In Projekten mit erheblichen Risiken kann es sogar angebracht sein, festzulegen, wann das Projektsteuerungsgremium die sponsernde Organisation oder Organisationen um Genehmigung ersuchen muss.

Schließlich wird der Projektauftrag vom Sponsor unterzeichnet und fungiert als offizielle Bestätigung seiner Unterstützung für das Projekt. Mit dieser Unterzeichnung erhält der Projektmanager den klaren Auftrag, das festgelegte Leitziel und die erwarteten Ergebnisse zu erreichen, indem er den definierten Hauptliefergegenstand samt seinen Komponenten liefert. Dies soll unter Berücksichtigung der im Dokument festgehaltenen Annahmen und Einschränkungen geschehen. In manchen Organisationen praktiziert man die gemeinsame Unterzeichnung des Projektauftrags durch den Projektmanager und den Sponsor, was als vertragliche Vereinbarung zwischen beiden Parteien angesehen wird.

Sie fragen sich vielleicht, warum die Befugnisse des Projektmanagers, des Sponsors und des Projektsteuerungsgremiums im Projektauftrag festgelegt werden sollen. Der Grund liegt darin, dass diese Akteure nicht über die gleiche Autorität wie funktionale Manager in der ständigen Organisationsstruktur verfügen. Projekte sind einzigartig und erfordern maßgeschneiderte Befugnisse für jede Rolle, um sicherzustellen, dass das Projekt effizient und effektiv durchgeführt werden kann. Daher ist es von entscheidender Bedeutung, dass alle beteiligten Stakeholder genau verstehen, welche Handlungsspielräume jeder Akteur hat. Die Autoritätsstufen können je nach Projekttyp, Rolle und Organisation variieren. Während in den ständigen Organisationsstrukturen von Organisationen die Autoritätsniveaus in der Regel klar definiert sind, erfordert die Einzigartigkeit von Projekten eine individuelle Festlegung, um sicherzustellen, dass das Projekt effizient gemanaged, gesteuert und kontrolliert wird.

Nachdem der Projektauftrag unterzeichnet ist, verteilt der Projektsponsor ihn an die relevanten Stakeholder. Sobald dieser Schritt abgeschlossen ist, wird der Projektmanager offiziell mit der Leitung des Projekts betraut. Seine Befugnis ist nun allgemein anerkannt, und er ist berechtigt, sämtliche Planungsaktivitäten zu steuern, die für die erfolgreiche Durchführung des Projekts erforderlich sind.

Zusammenfassend ist der Projektauftrag das Dokument, das die im Initialisierungsprozess erarbeiteten Informationen bündelt. Seine Genehmigung durch den Projektsponsor oder das Steuerungsgremium markiert den offiziellen Start einer neuen temporären Organisation. Dieses Dokument definiert die zentralen Parameter der Organisation, insbesondere ihren Zweck, ihr Leitziel, das Hauptlieferobjekt und die erwarteten Ergebnisse. Zudem ernennt es den Projektmanager, den Projektsponsor und gegebenenfalls das Projektsteuerungsgremium und legt ihre jeweiligen Autoritätsniveaus fest. Nach der Unterzeichnung des Projektauftrags ist der Projektmanager autorisiert, die Ressourcen der Organisation zu mobilisieren und zu managen, zur Erreichung des Leitziels und der definierten Ergebnisse.

 

 

 

1.14 Auftaktmeeting

Dieser Abschnitt erläutert, wie das Auftaktmeeting dazu dient, die Stakeholder über den Inhalt des genehmigten Projektauftrags zu informieren und gleichzeitig die Planungsprozesse zu initiieren.

Die vier Hauptziele des Auftaktmeetings sind wie folgt: Erstens, allen Stakeholdern mitteilen, dass das Projekt offiziell gestartet ist. Zweitens, die Gründung der neuen, zeitlich begrenzten Organisation vorstellen, nämlich das neue Projekt, das entsprechend dem im Projektauftrag definierten Leitziel und Zweck ins Leben gerufen wurde. Drittens, sicherstellen, dass alle Beteiligten ihre spezifische Rolle im Projekt verstehen, die sich von ihren üblichen Aufgaben unterscheiden kann. Viertens, eine gemeinsame Vision für das Projekt unter den Stakeholdern etablieren und ihre Verpflichtung dazu gewinnen.

Neben dem Projektteam und dem Projektmanager sollten auch andere Schlüsselpersonen am Auftaktmeeting teilnehmen. Dazu gehören der Projektsponsor, relevante Abteilungsleiter, der Kunde, sowie das Projektbüro, sofern vorhanden, und weitere nach Bedarf beteiligte Personen. Die Teilnahme dieser Schlüsselpersonen gewährleistet, dass alle relevanten Perspektiven und Anforderungen von Beginn an berücksichtigt werden, was für die Ausrichtung und den Erfolg des Projekts entscheidend ist.

Das Auftaktmeeting bietet dem Projektsponsor eine wichtige Gelegenheit, die Autorität des Projektmanagers zu bekräftigen. Dies ist vor allem für Abteilungsleiter wichtig, die Bedenken hinsichtlich der Bereitstellung von Personal und Ressourcen aus ihren Bereichen haben könnten.

Das Auftaktmeeting markiert ein klares und starkes grünes Licht für den Beginn der Planungsaktivitäten, die den Einsatz spezialisierter Ressourcen erfordern. Es dient dazu, die teilnehmenden Abteilungsleiter darauf aufmerksam zu machen, dass sie in Kürze Anforderungen für die Bereitstellung dieser Ressourcen erhalten werden.

Für ein effektives Auftaktmeeting ist eine strukturierte Tagesordnung unerlässlich. Folgende Punkte sollten auf der Agenda stehen:

• Begrüßung und Vorstellung: Alle Teilnehmenden werden begrüßt, und Personen, die den anderen noch nicht bekannt sind, werden vorgestellt. Dies fördert ein gemeinschaftliches Umfeld und erleichtert die spätere Zusammenarbeit.
• Überblick über den Projektauftrag: Eine Zusammenfassung der Schlüsselinformationen aus dem Projektauftrag vermittelt allen ein klares Verständnis der Projektziele und -rahmenbedingungen.
• Vorstellung des Projektorganigramms: Das Organigramm illustriert die Struktur der neuen, temporären Organisation. Da die meisten Menschen mit funktionalen Organisationsstrukturen und Hierarchien vertraut sind, ist es wichtig, die speziellen Rollen und Verantwortlichkeiten im Projektmanagement klarzumachen. Dies umfasst die Rollen des Sponsors, des Projektmanagers, der Teammitglieder, der Arbeitspaketleiter, des Kunden, des Projektbüros falls vorhanden, und möglicherweise neu geschaffener Rollen wie eines Lenkungsausschusses, eines Änderungskontrollausschusses oder einer Qualitätssicherungseinheit. Es wird erwartet, dass die meisten, wenn nicht alle, am Projekt beteiligten Personen teilnehmen. Alle Unklarheiten bezüglich Rollen oder Verantwortlichkeiten sollten während des Meetings aktiv angesprochen und geklärt werden.
• Präsentation allgemeinen Fahrplans: Falls der Projektauftrag bereits einen Meilensteinplan oder einen detaillierten Fahrplan beinhaltet, sollte dieser den Teilnehmern vorgestellt werden, um Klarheit über die kurz- und mittelfristigen Ziele zu schaffen.
• Bestätigung des Projektstarts: Es ist entscheidend, offiziell zu bestätigen, dass das Projekt gestartet wurde. Diese Bestätigung vermittelt den Teilnehmenden ein Gefühl der Dringlichkeit und Formalität, was zur Motivation beiträgt, und die Bedeutung des Projekts unterstreicht.
• Diskussion offener Fragen: Ein wesentlicher Teil des Auftaktmeetings ist die offene Diskussion aller Fragen. Dies dient nicht der Neuausrichtung des Projektziels, sondern bietet eine Plattform, um Bedenken und Fragen zu adressieren und ein gemeinsames Verständnis zu fördern.

Weitere Überlegungen für die Auftaktveranstaltung umfassen die folgenden Punkte:

• Teilnehmerkreis: Es ist essenziell, das gesamte Projektteam, den Sponsor und andere Schlüsselinteressenten einzubeziehen. Bei einer großen Anzahl von Teilnehmenden kann es sinnvoll sein, separate Veranstaltungen zu organisieren, um eine effektive Kommunikation zu gewährleisten.
• Dauer der Veranstaltung: Die Dauer eines Auftaktmeetings kann variieren, von einigen Stunden bis zu einem ganzen Tag, abhängig von der Komplexität und den Anforderungen des Projekts. Für komplexe oder kontroverse Projekte kann ein länger dauerndes Meeting eine lohnende Investition sein, um alle auf denselben Stand zu bringen und Unklarheiten aus dem Weg zu räumen.
• Vorbereitung und Organisation: Eine gründliche Vorbereitung ist entscheidend, um einen positiven ersten Eindruck zu hinterlassen und die Grundlage für den Projekterfolg zu legen. Der Projektmanager sollte das Meeting sorgfältig planen und durchführen, um sicherzustellen, dass es produktiv ist und nicht als Zeitverschwendung wahrgenommen wird. Eine vorbereitende Absprache zwischen Projektmanager und Sponsor über den Ablauf der Veranstaltung kann hierbei unterstützen.

Ein klarer Projektauftrag, ein engagierter Sponsor, ein zuständiger Projektmanager sowie klar definierte Rollen und Erwartungen legen den Grundstein für einen erfolgreichen Übergang von der Initialisierungsphase zu den Planungsaktivitäten des Projekts.

 

 

2.1 Überblick der Planungsaktivitäten

Dieser Abschnitt bietet einen allgemeinen Überblick über die Planungsaktivitäten eines Projekts und seiner Phasen.

Jede Arbeit erfordert eine Planung, bevor sie ausgeführt wird, selbst wenn diese Planung nur gedanklich erfolgt und nichts schriftlich festgehalten wird. Dies gilt ebenso, wenn die Arbeit als Projekt organisiert ist.

Ein Projektmanagementplan besteht aus einem integrierten Satz verschiedener Unterpläne, die aufeinander abgestimmt sein müssen.

Die Planung eines Projekts ist keine Einzelaktivität, sondern eine Teamarbeit. Sie umfasst den Projektmanager, das Projektteam und Experten des jeweiligen Fachgebiets, die detaillierte Kenntnisse darüber besitzen, was zur Erstellung des spezifischen Produkts, des Schlüssellieferobjekts des Projekts und seiner Komponenten, erforderlich ist.

Zunächst sammelt das Projektmanagementteam die Anforderungen der Hauptinteressenten darüber, wie das Projekt gesteuert werden soll. Anschließend überprüft das Team die während der Projektinitiierung gesammelten Einschränkungen und Annahmen erneut, um festzustellen, ob Änderungen vorliegen.

Nun gilt es, SMART-Unterziele festzulegen, die zum Leitziel führen, welches im Projektauftrag definiert wurde. Das Managementteam muss zudem die Phasen oder Iterationen bestimmen, die für die Entwicklung der Lösung erforderlich sind, bekannt als der Lebenszyklus der Lösungsentwicklung.

Besondere Aufmerksamkeit sollte der Erstellung des Projektbasisplans gewidmet werden, der den Umfang, das Budget und den Terminplan des Projekts umfasst. Dies bedeutet die Integration dessen, was das Projekt liefern soll, seine Kosten und den Zeitrahmen. Dies ist der Kern des Projektmanagementplans.

Darüber hinaus können Hilfspläne zur Steuerung verschiedener Projektaspekte ausgearbeitet werden. Die Verwendung von ‘können’ unterstreicht, dass Umfang und Detailtiefe dieser Managementpläne von der Projektgröße, der Komplexität, dem gewählten Projektmanagementansatz und der in der ausführenden Organisation angewandten Projektmanagementmethode abhängen. Bei großen, plangetriebenen Projekten kann die Erstellung von Hilfsplänen für die Steuerung zahlreicher Bereiche wie Umfang, Anforderungen, Terminplan, Kosten, Qualität, Ressourcen, Kommunikation, Risiken, Beschaffung und Stakeholder-Engagement erforderlich sein.

Im Zuge der Planungsaktivitäten identifiziert das Team Risiken, analysiert diese hinsichtlich ihres Einflusses und der Wahrscheinlichkeit ihres Eintretens und entwickelt anschließend Strategien zur Risikobewältigung.

Sind all diese Elemente sorgfältig abgewogen und integriert, sollte die Zustimmung des leitenden Gremiums eingeholt werden, typischerweise des Projektsponsors und des Projektkunden, es sei denn, beide Rollen werden von derselben Person wahrgenommen.

Schließlich informiert der Projektmanager die Stakeholder über den genehmigten Projektmanagementplan. Eine Zweite Auftaktsitzung wird organisiert, um alle über den finalen Plan zu informieren. Dies markiert den Übergang von den Planungsaktivitäten zu den Ausführungsaktivitäten.

Nach seiner Fertigstellung wird der Projektmanagementplan nicht einfach zur Seite gelegt und vergessen. Er dient während der gesamten Projektlaufzeit zur Lenkung des Projekts, zur Überwachung seiner Entwicklung, zur Korrektur von Abweichungen, zur angemessenen Kommunikation mit den Stakeholdern, zur Einbindung derselben, zum Risikomanagement und zur Steuerung aller anderen Aspekte des Projekts, für die ein Hilfsplan erstellt wurde.

Zweck der Projektplanung.

Der Zweck der Projektplanung ist es, durch eine vorausschauende, systematische Vorbereitung die Wahrscheinlichkeit zu erhöhen, dass das Projekt seine Ziele erreicht, innerhalb des Budgets und Zeitrahmens bleibt und die Bedürfnisse der Stakeholder erfüllt, indem sie:

• Orientierung bietet und den Beteiligten eine klare Richtung vorlegt, wie die Projektziele erreicht werden sollen.
• Komplexität reduziert, indem das Projekt in handhabbare Teilaufgaben und Meilensteine zerlegt wird.
• Unsicherheiten minimiert durch die frühzeitige Identifikation potenzieller Risiken und die Festlegung von Maßnahmen zu deren Minimierung.
• Ressourceneinsatz optimiert, um eine effiziente Zuweisung und Nutzung von Zeit, Budget, Personal und Material zu gewährleisten.
• Kommunikation und Koordination verbessert, sodass alle Beteiligten informiert sind und ihre Aktivitäten auf die Projektziele ausgerichtet sind.
• Eine Grundlage für die Überwachung und Steuerung schafft, gegen die der tatsächliche Fortschritt gemessen und bei Bedarf steuernd eingegriffen werden kann.

Projektplanungsaktivitäten sind keine einmalige Angelegenheit zu Projektbeginn, sondern ein iterativer Prozess, der zu Beginn jeder Projektphase wiederholt wird. Dieser Ansatz trägt dazu bei, dass der Projektplan kontinuierlich aktualisiert und an die sich ändernden Bedingungen und Anforderungen des Projekts angepasst wird, wodurch eine flexible Reaktion auf Herausforderungen und Veränderungen während des gesamten Projektverlaufs ermöglicht wird.

 

 

 

 

 

2.2 Anforderungen für das Projektmanagement sammeln und Annahmen sowie Einschränkungen überprüfen

In diesem Abschnitt wird erläutert, wie man die Anforderungen für das Projektmanagement erfasst, und warum es notwendig ist, die während der Projektinitiierung definierten Annahmen und Einschränkungen zu aktualisieren.

Anforderungen sind Bedingungen, die von Stakeholdern des Projekts formuliert werden, um deren Bedürfnisse zu erfüllen.

Während der Initiierungsaktivitäten haben wir bereits die Geschäftsanforderungen erfasst. Das umfasst die Fähigkeiten, die das Unternehmen durch das Projekt erwerben möchte und die es vom Projekt erwartet.

Später, im Rahmen der Planungsaktivitäten, werden wir die funktionalen Anforderungen der Lösung sowie deren Qualitätsmerkmale sammeln. Weitere Informationen zu diesem Aspekt der Anforderungen finden Sie im Abschnitt zur Entwicklung des Inhalts- und Umfangsbasisplans.

In diesem Kontext behandeln wir nicht Geschäftsanforderungen oder funktionale Anforderungen der Lösung. Aktuell diskutieren wir die Anforderungen an das Projektmanagement, die von den Hauptbeteiligten benötigt oder erwartet werden. Zum Beispiel: Wie möchte der Sponsor oder Kunde, dass das Projekt gemanagt wird? Welche Erwartungen hat das Projektteam in Bezug auf dasselbe Thema? Existierten ein Projektbüro und eine firmeninterne Projektmanagementmethode, die eingehalten werden müssen? Welche Aspekte des Projekts sollten geplant werden und welche nicht? Diese Informationen sind von Bedeutung, wenn wir die Anforderungen der Hauptbeteiligten für das Projektmanagement sammeln.

Es gibt mehrere Bereiche zu berücksichtigen, um die Anforderungen für das Projektmanagement zu definieren. Wie wird der Umfang gesteuert? Und wie der Terminplan und die Kosten? Wie gehen wir mit Qualität und den Ressourcen, sowohl menschlichen als auch nicht-menschlichen, um? Welche Ansätze gibt es für die Steuerung von Kommunikation und das Management der Risiken? Mit welcher Vorgehensweise sollen Probleme und Änderungen abgewickelt werden? Und wie sollen die Beschaffungen gesteuert und das Engagement der Stakeholder sichergestellt werden?

 

Betrachten wir einige Beispiele:

• Im Bereich des Personals: Gibt es Anforderungen an die Teamzusammensetzung? Zum Beispiel in Bezug auf Herkunft, Geschlecht oder kulturelle Vielfalt.
• Im Bereich der Planung: Wie inkrementell und iterativ kann die Planung sein, und inwiefern sollte sie plangetrieben sein? Befürworten einige Stakeholder einen rein agilen Ansatz? Das bedeutet, funktionale Anforderungen allmählich zu entdecken, anstatt sie zu Beginn des Projekts festzulegen. Möglicherweise bevorzugen andere Stakeholder, wie die Finanzabteilung, einen plangetriebenen Ansatz, um mehr Budgetvorhersagbarkeit zu haben. Dieser Punkt beeinflusst den Ansatz, der in den meisten Managementbereichen angewendet wird. Zum Beispiel ist es im agilen Ansatz üblich, funktionale Anforderungen schrittweise zu identifizieren, während die Lösung entwickelt wird, wodurch Änderungen erwartet werden. Bei einem plangetriebenen Ansatz versuchen wir, alle gewünschten Funktionen von Anfang an zu erfassen. Auf dieser Grundlage werden Terminplan und Budget festgelegt, und Änderungen am Lösungsinhalt gelten als Ausnahme. Daher erfordert die Steuerung solcher außergewöhnlichen Änderungen einen ziemlich bürokratischen Prozess zur Genehmigung von Änderungen am ursprünglich genehmigten Projektumfang.
• Im Bereich der Beschaffungen: Gibt es eine Einkaufsabteilung in der Organisation, die die Regeln für die Beschaffungen festlegt, die das Projekt durchführen muss? Wie integriert sich die Einkaufsabteilung in das Projektteam?

Wenn das Unternehmen eine standardisierte Projektmanagementmethode verwendet, wird die Art und Weise, wie diese Aspekte verwaltet werden, wahrscheinlich klarer sein. Selbst in solchen Fällen möchte man möglicherweise einige Aspekte dieser Standardmethode an die spezifischen Bedürfnisse des betreffenden Projekts anpassen.

Im Allgemeinen kann man sagen, dass je weniger die zu verwendende Managementmethode dokumentiert ist, desto mehr muss man die Anfragen der Beteiligten bezüglich der zu befolgenden Managementprozesse sammeln und berücksichtigen. Die Ergebnisse dieses Erhebungsprozesses sind ein notwendiger Input, den der Projektmanager benötigt, um Managementpläne für die verschiedenen Aspekte des Projekts zu erstellen.

Jetzt sprechen wir kurz über Annahmen und Einschränkungen. Beide wurden während der Projektinitiierung identifiziert. Allerdings könnten sich einige Dinge geändert haben, abhängig von der Zeit, die seit der Erstellung des Projektauftrags vergangen ist. Oder es kann sein, dass neue Beteiligte in die Planung einbezogen werden müssen, und dies löst die Notwendigkeit aus, das, was im Annahmeregister und in der Liste der Einschränkungen während der Initiierung aufgezeichnet wurde, zu überprüfen.

Vergessen wir nicht, dass Annahmen Aussagen sind, die als wahr angesehen werden über notwendige Dinge, von denen wir annehmen, dass sie geschehen werden, oder schädliche Dinge, von denen wir annehmen, dass sie nicht geschehen werden.

Die Erhebung von Anforderungen für das Projektmanagement ist wahrscheinlich ein guter Zeitpunkt, um diese Elemente zu aktualisieren. Wir könnten entdecken, dass einige Elemente, die zuvor als Annahmen klassifiziert wurden, tatsächlich Risiken sind und vom Annahmeregister in das Risikoregister für eine detailliertere Analyse übergehen müssen.

Was die Einschränkungen betrifft, dürfen wir nicht vergessen, dass es sich um Faktoren handelt, die außerhalb der Kontrolle des Projektteams liegen und dennoch verwaltet werden müssen. Die anfänglichen Einschränkungen wurden während der Projektinitiierung identifiziert. Jetzt ist es an der Zeit, sie zu überprüfen und bei Bedarf zu aktualisieren. Möglicherweise sind einige Einschränkungen nicht mehr relevant, oder es sind neue Einschränkungen aufgetreten. Da wir nun in die Phase der detaillierten Projektplanung eintreten, könnten wir feststellen, dass bestimmte Meilensteine bis zu bestimmten Terminen erreicht werden müssen. Dies sind Einschränkungen, die wir sorgfältig verstehen müssen. Ebenso können bestimmte Technologien als Voraussetzung oder als Ausschlusskriterien gelten. All diese Aspekte sind Einschränkungen.

Für weitere Details zu Risiken, Annahmen und Einschränkungen können Sie die Unit über Projektinitiierung konsultieren.

Zusammenfassend lässt sich sagen, dass die Erhebung von Anforderungen der Beteiligten für das Projektmanagement einen wichtigen Beitrag zur Planung und damit zum Erfolg des Projekts leistet. Annahmen und Einschränkungen müssen erfasst und im Verlauf des Projekts aktualisiert werden. Das neue Stadium der Planung nach der Initiierung ist ein guter Zeitpunkt, um das Annahmeregister und die Liste der Einschränkungen zu aktualisieren.

 

 

 

2.3 SMART-Unterziele definieren, die zum Leitziel führen

In dieser Sektion wird erläutert, was SMART-Unterziele sind und wie man sie definiert.

Ein Leitziel ist eine hervorragende Möglichkeit, die Stakeholder eines Projekts zu verbinden und sicherzustellen, dass alle in dieselbe Richtung arbeiten. Ein Leitziel ist eine allgemeine Aussage, die sich auf das zu erreichende Ergebnis konzentriert und nicht die Mittel beschreibt, die verwendet werden, um dieses gewünschte Ergebnis zu erzielen. Deshalb glauben wir, dass es besser ist, sich auf das Leitziel zu konzentrieren, wenn das Projekt initiiert wird.

Manche Menschen verwenden den Begriff Ziel ohne weitere Differenzierung. Einige Methodologien unterscheiden zwischen zwei Ebenen von Zielen, wie Oberziel und Unterziele, oder strategisches Ziel und operative Ziele. Andere Methoden verwenden den Begriff Ziel und ergänzen ihn durch Leistungsindikatoren. Die Idee dieser Paare ist es, ein Oberziel in Unterziele zu unterteilen, um die intermediäre Leistung zu messen und festzustellen, ob man sich auf dem Weg zur Zielerreichung befindet.

In diesem Kurs bevorzugen wir das Bezeichnungspaar “Leitziel und Unterziele”, wobei das Leitziel die allgemeinere Aussage ist und die Unterziele spezifischere und detailliertere Aussagen sind. Mit dieser Logik ist das Leitziel eine allgemeine Aussage darüber, was erreicht werden muss, während die Unterziele gruppierte Aktionen sind, die zum Leitziel führen.

In unserem Beispiel eines Online-Systems zur Steigerung der Transparenz von Transaktionen ist das gewünschte Ergebnis, die angestrebte Veränderung, die das Leitziel steuert, nämlich eine erhöhte Transparenz. Um dieses Ergebnis zu erreichen, haben wir verschiedene Strategien evaluiert und anschließend beschlossen, ein automatisiertes Onlinesystem zur Überwachung und Anzeige des Status der Transaktionen zu entwickeln und zu implementieren. Das ist das Hauptziel.

Während der Projektinitiierung haben wir die Ausrichtung des Leitziels und des darin enthaltenen Schlüsselliefergegenstands überprüft, indem wir uns folgende Frage gestellt haben: Wenn wir ein automatisiertes Onlinesystem verwenden würden, das den Status aller Transaktionen anzeigt, hätten wir dann das gewünschte Transparenzniveau erreicht? Die Antwort war ‘ja’. Wenn die Antwort ‘nein’ gewesen wäre, hätten wir entweder das Leitziel, den Schlüsselliefergegenstand oder beide Aussagen überarbeiten müssen, bis sie aufeinander abgestimmt gewesen wären.

Als Teil des Kursbeispiels wählten wir für die Lehrinhalte über die Initiierungsaktivitäten die Option eines automatisierten Onlinesystems und verglichen diese Option mit anderen verfügbaren Optionen, um dasselbe Leitziel der Transparenz der Operationen zu erreichen. Die anderen beiden in Betracht gezogenen Optionen waren: a) ein System nächtlicher Updates und b) mehr Steuerungspersonal, um die Aktualisierungsarbeiten manuell durchzuführen.

Die drei Optionen wurden anhand einer Multikriterienmatrix miteinander verglichen. Wir wählten die Option des automatisierten Onlinesynchronisationssystems und verwarfen die anderen beiden Optionen.

Jetzt gehen wir eine Ebene tiefer, sowohl für das Leitziel als auch für das ausgewählte Schlüssellieferobjekt. Dazu definieren wir gruppierte Aktionen, die zum Leitziel führen. Diese gruppierten Aktionen sind die Unterziele, und diese Unterziele liefern wiederum “Zwischenlieferobjekte”, die das Schlüssellieferobjekt bilden.

Lassen Sie uns bei diesem Beispiel bleiben: Welche gruppierten Aktionen würden dazu führen, das Leitziel zu erreichen? Anders ausgedrückt, welche Unterziele sind notwendig, um gemeinsam ein automatisiertes Online-Synchronisationssystem zu liefern?

Die Unterziele könnten Folgendes beinhalten:

• Explizite Definition der Arbeitsabläufe für alle Produkte, einschließlich der Schritte, an denen die Lieferanten bis zum Fälligkeitsdatum, Tag X, beteiligt sind.
• Erstellung einer Datenbank oder Kombination bestehender Datenbanken, um den Status aller Produkte in den verschiedenen Phasen ihrer definierten Arbeitsabläufe bis zum Fälligkeitsdatum, Tag X, zu verfolgen.
• Entwicklung und Implementierung einer automatisierten Online-Synchronisationsanwendung, entweder aus einem vorhandenen Softwarepaket oder als maßgeschneiderte Lösung bis zum Fälligkeitsdatum, Tag X.
• Schulung des Personals der Organisation sowie des Personals der beteiligten Lieferanten, um die Lösung bis zum Fälligkeitsdatum, Tag X, nutzen zu können.

Die resultierenden Zwischenlieferobjekte aus diesen spezifischeren Unterzielen sind die folgenden: definierte Arbeitsabläufe für alle Produkte, eine kombinierte Datenbank, eine automatisierte Onlinesynchronisationsanwendung und Schulungsmaßnahmen.

Wir erinnern uns auch daran, dass diese Unterziele SMART sein müssen. Das bedeutet, sie müssen spezifisch, messbar, erreichbar, realistisch und zeitlich begrenzt sein. Überprüfen wir, ob sie diese Kriterien erfüllen.

Erstens, alle haben ein klares Fälligkeitsdatum.

Zweitens, alle sind erreichbar und realistisch. Was erreichbar und realistisch ist, hängt in hohem Maße von den Fähigkeiten der spezifischen Organisation und den verfügbaren Ressourcen ab. Einen Mann zum Mond zu schicken und ihn sicher zur Erde zurückzubringen, ist für die NASA oder eine andere bedeutende Raumfahrtagentur machbar, aber nicht für die meisten anderen Organisationen. Das gesamte geschriebene Wissen der Welt allen Menschen zugänglich zu machen, scheint für Google erreichbar, aber nicht für andere Organisationen. Eine Zertifizierung in Projektmanagement zu erlangen, ist für Sie erreichbar, aber nicht für alle Menschen. Die Leitziele sollten herausfordernd und anregend sein, um das Team zu motivieren, aber sie sollten erreichbar sein. Unerreichbare Leitziel sind ziemlich demotivierend.

Schließlich, inwieweit sind die formulierten Leitziele spezifisch und messbar? Vielleicht können sie in diesem Sinne besser formuliert werden. Hier könnte die Definition von Leistungsindikatoren helfen.

Zum Beispiel könnte die Schulung der Organisation und der Lieferanten spezifischer und messbarer sein, wenn wir formulieren: das Personal der Organisation sowie das Personal der beteiligten Lieferanten für die Nutzung der Lösung schulen und einen ausreichenden Leistungsgrad gemäß einem Fähigkeitstest mit einer Punktzahl von x% bis zum Datum x erreichen.

Die anderen Unterziele sind in der vorgeschlagenen Formulierung ausreichend spezifisch. Die Definition von Leistungsindikatoren für das Onlinesystem, die Datenbank und die Arbeitsabläufe wird Teil der Definition der funktionalen Anforderungen und der Qualitätsattribute der Lösung sein.

Zusammenfassend lässt sich sagen, dass wir in den Planungsaktivitäten das Leitziel in Unterziele herunterbrechen, das heißt, in gruppierte Aktionen, die gemeinsam zum Leitziel führen. Diese Unterziele müssen spezifisch, messbar, erreichbar, realistisch und zeitlich begrenzt sein.

 

 

2.4 Den Lösungsentwicklungsansatz festlegen

In diesem Abschnitt werden die Hauptarten von Ansätzen vorgestellt, die für die Erarbeitung einer Lösung herangezogen werden können, oft auch als Lebenszyklus der Lösungsentwicklung bekannt. Es gibt drei wesentliche Ansätze zur Entwicklung einer Lösung: den prädiktiven, den iterativen und den inkrementellen Ansatz. Der sogenannte agile Ansatz kombiniert Elemente des iterativen und inkrementellen Ansatzes.

Der Projektlebenszyklus umfasst alle Phasen oder Iterationen, in denen ein Projekt strukturiert ist. Abhängig von der Beschaffenheit und dem Typ des zu entwickelnden Produkts lassen sich unterschiedliche Projekt-Lebenszyklen bestimmen:

• Prädiktive Lebenszyklen legen die Anforderungen an das Produkt und den zu liefernden Umfang gleich zu Beginn des Projekts fest. Planabweichungen und Änderungen gelten als Ausnahme.
• Iterative und inkrementelle Lebenszyklen entwickeln das Produkt schrittweise weiter, wodurch eine laufende Präzisierung der Anforderungen ermöglicht wird.
• Durch den iterativen Ansatz wird der Lösungsumfang in kurzen Zyklen kontinuierlich verbessert, indem regelmäßig Feedback eingeholt und umgesetzt wird.
• Der inkrementelle Ansatz ergänzt in jeder Phase neue Funktionen zum Produkt und schließt diese jeweils ab.
• Agile Lebenszyklen kombinieren iterative und inkrementelle Elemente.

Lassen Sie uns dies an einem Beispiel veranschaulichen.

Prädiktiver Lösungsansatz.

Stellen Sie sich vor, ein Projekt wird ins Leben gerufen, um ein Schlagloch zu reparieren. Bei genauer Kenntnis der Schlaglochmaße und klar definierten Anforderungen ist der Arbeitsablauf vorhersehbar. Der Prozess beginnt mit der Erfassung der Maße und Anforderungen, gefolgt von der Planung und Vorbereitung der Reparaturform. Anschließend wird der Beton eingesetzt, die Oberfläche bearbeitet und schließlich das Schlagloch verfüllt. Dieser sequenzielle Ablauf ist als Wasserfall- oder prädiktiver Ansatz bekannt und setzt voraus, dass alle Anforderungen von Beginn an bekannt und eindeutig sind. Fehlt jedoch das genaue Wissen über die Dimensionen des Schlaglochs, gestaltet sich dieser Ansatz als schwierig oder ist unter Umständen sogar nicht durchführbar.

Iterativer Lösungsansatz.

In diesem Beispiel sind die genauen Maße des Schlaglochs unbekannt, daher entscheiden Sie sich, einen Betonblock zu meißeln, um die Lücke zu schließen. Diese kontinuierliche Feinabstimmung durch Meißeln, Ausprobieren und weiteres Meißeln führt dazu, dass der Betonblock schließlich perfekt in das Schlagloch passt. Durch diesen Prozess der wiederholten Anpassung, auch Iterationen genannt, erreichen Sie eine ideale Passform des Blocks im Schlagloch, selbst ohne genaue Kenntnis der Maße oder spezifischen Anforderungen. Dieses Vorgehen wird als iterativer Ansatz bezeichnet.

Inkrementeller Lösungsansatz.

In einer alternativen Methode zur Lösung des komplexen Problems könnte man einen standardisierten Betonblock herstellen, der das Schlagloch nur ungefähr ausfüllt, und diesen dann dem Kunden übergeben. Der Kunde setzt den Betonblock ins Schlagloch ein und gibt Feedback zu den noch offenen Stellen. Auf Grundlage dieses Feedbacks fertigen Sie dann zusätzliche, kleinere Betonstücke an und füllen nach und nach die verbleibenden Lücken, wobei Sie sich jedes Mal auf das neueste Kundenfeedback stützen. Dieser Prozess wird als inkrementeller Ansatz bezeichnet. Hierbei muss der Kunde nicht auf das Projektende warten, um einen Nutzen zu ziehen. Bereits mit der Erstbefüllung ist das Schlagloch teilweise verfüllt; es bleiben zwar Lücken, diese werden jedoch kontinuierlich weniger. So kann der Kunde jeden Fortschritt, jedes sogenannte Inkrement, nutzen und dennoch laufend weitere funktionale Anforderungen bis zum Abschluss des Projekts einbringen. Auf diese Weise lässt sich die Lücke auch ohne genaue Kenntnis der anfänglichen Maße schrittweise mit einem inkrementellen Ansatz schließen, wobei der Kunde bereits frühzeitig einen Mehrwert erhält.

Agiler Lösungsansatz.

Diese Methode bietet eine innovative Lösung für komplexe Probleme, insbesondere wenn zu Beginn keine klaren Anforderungen vorliegen. Angenommen, Sie haben keinerlei Informationen über die Größe des Schlaglochs. In einem solchen Fall könnten Sie sich dazu entschließen, mit der Lieferung kleinerer Steine zu beginnen, um das Schlagloch nach und nach zu füllen – ein Vorgehen, das dem inkrementellen Ansatz ähnelt. Basierend auf fortlaufendem Kundenfeedback liefern Sie Steine in den passenden Größen und Formen. Einige Steine müssen eventuell nachbearbeitet werden, um besser in das Schlagloch zu passen, wie in einem iterativen Ansatz. Dabei entscheidet der Kunde, ob eine solche Anpassung eines bereits gelieferten Steins sofort oder zu einem späteren Zeitpunkt erfolgen soll. Manchmal bevorzugt der Kunde das Hinzufügen neuer Steine (inkrementell) gegenüber der Perfektionierung eines bereits gelieferten, der nicht ideal passte (iterativ). Die Entscheidung liegt beim Kunden, und diese Kombination aus einer iterativen und einer inkrementellen Vorgehensweise macht den Agilen Ansatz aus. Dies ist manchmal eine sehr effektive Strategie im Umgang mit vielen Unbekannten und/oder unklaren Anforderungen und wird als agiler Ansatz bezeichnet, der Merkmale sowohl des iterativen als auch des inkrementellen Ansatzes vereint.

Zwischenfazit.

Wir haben den prädiktiven, iterativen, inkrementellen und agilen Ansatz betrachtet. Diese Übersicht, die durch die begleitende Grafik unterstützt wird, soll Ihnen helfen, sich die verschiedenen Lebenszyklusmodelle, die Sie für die Entwicklung Ihrer Lösungen einsetzen können, leichter zu merken.

Beispiel eines Onlinesystems.

Jetzt nehmen wir die besprochenen Konzepte und wenden sie auf das Beispiel unserer Onlinelösung zur Erhöhung der Transparenz von Transaktionen an.

Prädiktiver Ansatz (auch als “Wasserfallmodell” bekannt).

Falls zu Projektbeginn alle Anforderungen bekannt und eindeutig definiert sind, bietet sich der prädiktive Ansatz an. In diesem Fall werden die Projektphasen nacheinander abgearbeitet, um schließlich eine umfassende Onlinelösung bereitzustellen.

Iterativer Ansatz.

Wenn die Anforderungen zu Projektbeginn nicht eindeutig sind, ist der iterative Ansatz besonders geeignet. Er startet mit einer Basisversion der Onlinelösung. Kundenerfahrungen und -feedback fließen in wiederkehrenden Zyklen ein, um die Lösung kontinuierlich zu verfeinern, bis sie den Erwartungen entspricht. Parallelarbeit an allen Prozessen und für jede Produktlinie, einschließlich Buchhaltung, Vertrieb und Logistik, fördert von Beginn an eine lückenlose Integration und Konsistenz. Dieser Ansatz erlaubt es Kunden, ihre Anforderungen schrittweise zu formulieren. Die Gesamtlösung wird so in fortlaufenden Zyklen den sich wandelnden oder neu entstehenden Anforderungen angepasst und verbessert.

Inkrementeller Ansatz.

Mit dem inkrementellen Ansatz starten wir in unserem Beispiel mit einem Onlinesystem, das bereits in seiner Anfangsversion als funktionsfähig betrachtet wird, sich aber zunächst auf einen bestimmten Produktbereich beschränkt. Ein erster Schritt könnte sein, die Transparenz aller Transaktionszustände innerhalb einer ausgewählten Produktlinie zu ermöglichen. So erhält der Kunde die Möglichkeit, das System in Gebrauch zu nehmen, ohne auf die vollständige Umsetzung der neuen Transaktionsverfolgungsmethode für das gesamte Produktsortiment warten zu müssen. Dies bildet das erste Inkrement. In darauf folgenden Inkrementen erweitern wir das System sukzessive um weitere Produktlinien, sodass schrittweise mehr Bereiche von der neuen Lösung profitieren.

Agiler Ansatz.

Beim agilen Ansatz kombinieren Sie den iterativen mit dem inkrementellen Ansatz. Wie im inkrementellen Modell beschrieben, stellen wir zunächst eine funktionsfähige Version des Online-Systems bereit, die der Kunde nutzen kann. Dies entspricht dem ersten Inkrement. Im Unterschied dazu ermöglicht der agile Ansatz dem Kunden jedoch, aktiv mitzuentscheiden, ob in einem nächsten Schritt die bereits entwickelten Funktionen auf eine neue Produktlinie ausgeweitet werden oder ob für die bestehende Produktgruppe zusätzliche Funktionen entwickelt werden sollen.

Nehmen wir beispielsweise an, im vorherigen Inkrement wurde eine Funktion implementiert, die den Lieferstatus mit „Das Produkt ist auf dem Weg zu Ihnen“ anzeigt, ohne weitere Details zu liefern. Im nächsten Schritt könnte das Entwicklungsteam genau definieren, was „auf dem Weg zu Ihnen“ bedeutet, indem es detaillierte Zustände einführt: Zustand 1) Das Produkt hat unser Lager verlassen; Zustand 2) Das Produkt befindet sich im Hauptverteilzentrum des Versandunternehmens; Zustand 3) Das Produkt ist im regionalen Verteilzentrum; Zustand 4) Das Produkt ist unterwegs zu Ihrem Zuhause; und Zustand 5) Das Produkt wurde an Ihrer Adresse zugestellt.

Alternativ kann der Kunde entscheiden, dass das nächste Inkrement die Funktionalität auf einer ziemlich allgemeinen Ebene von “auf dem Weg zu Ihnen” belässt, aber das Team implementiert sie in einer neuen Produktreihe.

In jeder Projektphase, ob Iteration oder Inkrement, entscheidet der Produktverantwortlicher über die Einführung neuer Funktionen, die Verbesserung bestehender Funktionen oder deren Implementierung in weiteren Produktlinien. Der Entwicklungsprozess wird durch kontinuierliche Kundenfeedbacks und neue Anforderungen vorangetrieben und dauert an, bis die Zielsetzungen hinsichtlich Funktionen, Anwendungsbereich und Qualität erreicht sind oder das Budget ausgeschöpft ist. Die Kombination aus iterativem und inkrementellem Vorgehen versetzt das Team in die Lage, sich dynamisch an veränderliche Startbedingungen anzupassen.

Allerdings eignen sich nicht alle Produkte gleichermaßen für inkrementelle, iterative oder agile Ansätze. Besonders bei einigen Produkten können Änderungen, vor allem in späten Entwicklungsphasen, problematisch sein. Physische Produkte sind oft weniger geeignet für progressive Entwicklungsmethoden. Generell gilt: Je näher ein Produkt der Massenproduktion kommt, desto schwieriger ist es, wichtige, zuvor übersehene Anforderungen nachzutragen.

Zudem führt die Flexibilität im Lieferumfang, die agile Methoden mit sich bringen, dazu, dass einige Professionals des Projektmanagements diese eher als Produktentwicklungsmethoden denn als Projektmanagementansätze betrachten.

Um zusammenzufassen, werfen wir noch einmal einen Blick auf die Grafiken, die den prädiktiven, iterativen, inkrementellen und agilen Ansatz veranschaulichen.

 

 

 

 

 

2.5 Entwicklung des Fortschrittsmessungsbasisplans hin zur Projektleistungsmessungsbasis

In diesem Abschnitt erhalten Sie einen Überblick über die kommenden Abschnitte, die detailliert beschreiben, wie der Fortschrittsmessungsbasisplan eines Projekts erstellt wird.

Jedes Projekt wird durch feste Vorgaben wie Umfang, Terminplan und Budget bestimmt, die gemeinsam den Fortschrittsmessungsbasisplan ausmachen. Ohne diesen Basisplan gleicht ein Vorhaben eher einer endlosen Odyssee als einem strukturierten Projekt.

Der Fortschrittsmessungsbasisplan ist der Eckpfeiler des Projektmanagementplans. Dieser Basisplan legt fest, was das Projekt liefern soll, wann es geliefert werden soll und für wie viel Geld.

Einen typischen Fortschrittsmessungsbasisplan besteht aus drei Elementen: der Inhalts- und Umfangsbasisplan, der Terminbasisplan und der Kostenbasisplan. Diese drei Elemente sind miteinander verbunden und bilden die sogenannte Dreifachbeschränkung. Wird eines dieser Elemente beeinträchtigt, hat das in der Regel auch Auswirkungen auf mindestens eines der anderen Elemente, wenn nicht sogar auf beide.

Eine Erweiterung des Projektumfangs beeinträchtigt in der Regel den Terminplan und die Kosten.

Eine Verkürzung des Terminplans beeinflusst meist den lieferbaren Umfang innerhalb der kürzeren Zeit und kann zudem zu einer Kostensteigerung führen, sollte eine Beschleunigung der Arbeiten notwendig werden.

Eine Reduzierung des Budgets hat oft Auswirkungen auf den Projektumfang oder die Qualität der Ergebnisse innerhalb dieses Umfangs. Zudem kann sich die Projektdauer verlängern, falls die Mittel zwar nicht gekürzt, aber langsamer bereitgestellt werden als geplant.

Wenn die drei Elemente des Fortschrittsmessungsbasisplans sorgfältig berücksichtigt werden, befinden wir uns in einer deutlich besseren Position, um den Kern des Projekt auf integrierte Weise zu überwachen.

In den nächsten Abschnitten wird detailliert beschrieben, wie die Basispläne für Inhalt und Umfang, Termine sowie Kosten zu einem umfassenden Fortschrittsmessungsbasisplan zusammengeführt werden. Dabei wird konkretisiert, welche Leistungen erbracht, bis wann diese abgeschlossen und welche Kosten dafür veranschlagt werden sollen.

 

 

 

2.5.1 Funktionale Anforderungen und Qualitätsattribute der Lösung

In diesem Abschnitt erfahren Sie, was funktionale Anforderungen sind und wie sie priorisiert werden. Wir haben bereits die Identifizierung geschäftlicher Anforderungen im Rahmen der Projektinitiierung und die Anforderungen an das Projektmanagement zu Beginn der Projektplanung besprochen. Nun, im weiteren Verlauf unserer Projektplanung, richten wir unser Augenmerk auf die funktionalen Anforderungen und die Qualitätsattribute der zu erstellenden Lösung.

Lassen Sie uns zunächst rekapitulieren, was wir unter Anforderungen verstehen. Sie umfassen spezifische Merkmale oder Bedingungen, die von Stakeholdern für ein bestimmtes Element verlangt werden, um deren Bedürfnisse zu erfüllen.

Die Erstellung einer umfassenden Liste von Anforderungen stellt eine anspruchsvolle Herausforderung dar und ist eine der Kernkompetenzen im Berufsfeld des Business-Analysten.

Einige dieser Herausforderungen bei den Anforderungen umfassen:

• Erstens: Wie zuverlässig und vollständig ist die Anforderungsliste, die wir erhalten, wenn wir die Stakeholder nach ihren Bedürfnissen fragen? Wie gehen wir mit Anforderungen um, die nach der Festlegung des Fortschrittsmessungsbasisplans definiert werden?
• Zweitens: Nicht alle Anforderungen sind gleich wichtig. Einige werden unverzichtbar sein, während andere optional sein können.
• Drittens: Da die Stakeholder eine kollektive Gruppe sind, werden ihre Anforderungen vielfältig und potenziell widersprüchlich sein, entsprechend verschiedenen Interessen und Bedürfnissen. Teil der Projektmanagementarbeit ist es, einen gemeinsamen Nenner und ein akzeptables Maß an kollektiver Übereinstimmung über die Merkmale der zu entwickelnden Lösung zu erreichen.
• Viertens: Wie können wir sicherstellen, dass die Anforderungsliste effektiv angewendet wird? Wie können wir sicher sein, dass wir nicht später, vielleicht zu spät, feststellen müssen, dass wir bestimmte Anforderungen vergessen haben?

Der Prozess zur Definition funktionaler Anforderungen und Qualitätsattribute verläuft typischerweise iterativ. Er startet mit einer initialen, allgemeinen Beschreibung der Anforderungen, die nach und nach zu detaillierten Spezifikationen ausgearbeitet werden. Diese frühe Phase der Anforderungsdefinition liefert die essenziellen Informationen, die nötig sind, um die Beschreibung des Projektinhalts- und -umfangs sowie den Projektstrukturplan (WBS) zu entwickeln und eine erste Schätzung von Aufwand, Kosten und Dauer vorzunehmen. Änderungen, die nach der Genehmigung des Leistungsmessungsbasis auftreten, werden durch einen etablierten Änderungsmanagementprozess oder eine Versionskontrolle geregelt, um sicherzustellen, dass auch spätere Anforderungen, die über die Erstlieferung hinausgehen, effektiv integriert werden können, besonders wenn der Produkttyp einen inkrementellen Entwicklungsansatz unterstützt.

Das technische Wort für das Sammeln von Anforderungen von Stakeholdern wird als Anforderungserhebung bezeichnet (Requirements Elicitation auf Englisch). Um genaue Anforderungen zu erreichen, müssen die Mitglieder des Projektteams, die als Businessanalysten agieren, die richtigen Fragen stellen, aufmerksam zuhören und die Antworten dokumentieren.

Erhebung von Anforderungen.

Zur Erhebung von Anforderungen bieten sich verschiedene Methoden an:

• Interviews: Eine sehr gängige Methode, die sowohl in Einzel- als auch in Gruppengesprächen durchgeführt werden kann. Bei Gruppeninterviews kann professionelle Moderation hilfreich sein. Wenn direkte Gespräche mit vielen Endnutzern nicht möglich sind, können repräsentative Stichproben in Fokusgruppen befragt werden.
• JAD (Joint Application Development): Ein intensiver Workshop, in dem Stakeholder so lange zusammenarbeiten, bis eine vollständige und von allen akzeptierte Anforderungsliste erstellt ist. Dies erinnert an das Konklave zur Papstwahl, bei dem niemand den Raum verlässt, bis eine Einigung erzielt ist.
• Fragebögen und Online-Umfragen: Eignen sich, um standardisierte Informationen von einer größeren Gruppe entfernter Stakeholder zu sammeln.
• Prototypenentwicklung: Die Erstellung von Prototypen ist eine relativ moderne Technik zur Anforderungserfassung gemäß den agilen Prinzipien. Bei diesem Ansatz erhält das Team vorläufige Anforderungen, die zur Erstellung eines Prototyps der Lösung verwendet werden. Dieser Prototyp wird dann dem Kunden präsentiert, der daraufhin zusätzliche Anforderungen auf dieser greifbareren Basis stellt. Das Team nutzt diesen Ansatz, wie im Abschnitt über iterative und inkrementelle Lebenszyklen beschrieben. Diese Zyklen setzen sich fort, bis der Kunde angibt, dass genügend Anforderungen erfüllt wurden, oder für eine vorab vereinbarte Anzahl von Iterationen.
• Beobachtung: Die gezielte Beobachtung von Nutzern im Umgang mit bestehenden Systemen kann wertvolle Einblicke in Verbesserungspotenziale und unentdeckte Bedürfnisse bieten.

Nachverfolgbarkeit.

Die Nachverfolgbarkeit spielt eine entscheidende Rolle im Entwicklungslebenszyklus einer umfangreichen Lösung, indem sie sicherstellt, dass alle Anforderungen über die verschiedenen Phasen hinweg verfolgt werden können. Bei inkrementellen Lebenszyklen, in denen jede Phase oder Iteration einen vollständigen Zyklus von Anforderungen, Design, Produktion und Tests umfasst, minimiert sich das Risiko, Anforderungen zu übersehen. In prädiktiven Ansätzen, die durch eine umfangreiche initiale Anforderungserhebungsphase gekennzeichnet sind, ist die Nachverfolgbarkeit unabdingbar, um die kontinuierliche Umsetzung der in der ersten Projektphase erhobenen Anforderungen durch die Design-, Entwicklungs-, Test- und Implementierungsphasen zu gewährleisten.

Ein effektives Werkzeug zur Gewährleistung der Nachverfolgbarkeit ist die Nachverfolgbarkeitsmatrix. Diese Matrix dient als visuelle Darstellung, die zeigt, wie jede Anforderung während der Designphase ein entsprechendes Designelement erhält. Weiterhin bestätigt die Matrix, dass jedes Designelement in der Produktionsphase realisiert, in der Testphase überprüft und letztlich implementiert wird. Umgekehrt hilft die Matrix dabei sicherzustellen, dass keine Elemente entworfen und produziert werden, die nicht den festgelegten Anforderungen entsprechen.

Ein beispielhafter Aufbau einer Nachverfolgbarkeitsmatrix könnte folgendermaßen aussehen:

Anforderung	Quelle	Design– komponenten	Konstruktions– komponenten	Test– komponenten
R-001	Verkaufsgruppe xx	Dxx1-R001	Bxx1-R001	Txx1-R001
R-002	Finanzgruppe xy	Dxy1-R002	Bxy1-R002	Txy1-R002
R-003	Sponsor	Dxz1-R003 Dzz1-R003	Bxz1-R003 Bzz1-R003	Txz1-R003

• Anforderung / Quelle: Jede Anforderung wird mit ihrer Quelle aufgeführt, beispielsweise von welchem Stakeholder oder aus welchem Dokument sie stammt.
• Designkomponenten: Für jede Anforderung werden die entsprechenden Designelemente aufgelistet.
• Entwicklungskomponenten: Hier werden die physischen oder digitalen Komponenten aufgeführt, die auf Basis der Designelemente entwickelt werden.
• Testkomponenten: Dieser Teil der Matrix zeigt, welche Tests durchgeführt werden, um die Erfüllung der Anforderungen zu überprüfen.

Die Nachverfolgbarkeitsmatrix ist nicht nur ein Instrument zur Überwachung, sondern auch zur Qualitätssicherung, indem sie gewährleistet, dass jede Anforderung im finalen Produkt berücksichtigt wird. Durch die Verwendung spezialisierter Softwarepakete kann die Verwaltung dieser Matrix und damit die Nachverfolgung der Anforderungen erheblich erleichtert werden.

Auswahl und Priorisierung von Anforderungen.

Die MoSCoW-Methode ist eine effektive Priorisierungstechnik. Dabei steht MoSCoW für ein Akronym, das sich aus dem ersten Buchstaben jeder der vier Kategorien von Anforderungen zusammensetzt, die in absteigender Reihenfolge der Wichtigkeit klassifiziert sind. Auf Deutsch können diese vier abnehmenden Wichtigkeitsniveaus der Anforderungen als Niveau 1: Muss (unverzichtbar), Niveau 2: Sollte (wichtig), Niveau 3: Könnte (optional) und Niveau 4: Wird-nicht umgesetzt (unwesentlich) ausgedrückt werden.

Die wörtliche Übersetzung wäre „man muss haben“, „man sollte haben“, „man könnte haben“ und „man wird nicht haben“.

Die unverzichtbaren Anforderungen (Niveau 1: Muss) befinden sich auf der obersten Stufe der Wichtigkeit. Sie sind entscheidend für den Erfolg der Lösung oder Iteration. Das Fehlen auch nur einer einzigen unverzichtbaren Anforderung wird als Misserfolg angesehen. Bestimmte Anforderungen, die zunächst als wesentlich erachtet wurden, können später von den relevanten Stakeholdern herabgestuft werden, zum Beispiel wenn neue Anforderungen auftauchen, die als noch wichtiger angesehen werden.

Auf der zweiten Ebene stehen die wichtigen, jedoch nicht unverzichtbaren Anforderungen für die aktuelle Lieferung (Niveau 2: Sollte).

Beachten Sie, dass wir in unserem Beispiel in der Einheit über Projektinitiierung die MoSCoW-Technik verwenden konnten, um die Erfolgskriterien des Projekts zu definieren. Im Projektauftrag formulierten wir, dass das Projekt als erfolgreich betrachtet wird, wenn alle unverzichtbaren Anforderungen und 80 % der wichtigen Anforderungen umgesetzt werden, ohne bereits zu diesem Zeitpunkt zu wissen, welche konkreten Anforderungen als unverzichtbar und welche als wichtig eingestuft würden.

Auf der dritten Wichtigkeitsebene stehen die optionalen Anforderungen (Niveau 3: Könnte). Sie sind wünschenswert, aber weniger wichtig und sicherlich nicht wesentlich. Sie könnten die Benutzererfahrung zu geringen Entwicklungskosten verbessern. Diese Anforderungen werden in der Regel in die Lösung aufgenommen, wenn Zeit und Ressourcen dies zulassen.

Schließlich werden die unwesentlichen Anforderungen (Niveau 4: Wird-nicht umgesetzt) der vierten Wichtigkeitsebene zugewiesen. Diese Anforderungen werden nicht umgesetzt, da sie von den Stakeholdern als am wenigsten kritisch, rentabel oder notwendig für die Lösung oder für die aktuelle Lieferung angesehen werden. Möglicherweise werden sie in späteren Versionen der Lösung erneut in Betracht gezogen.

Abschließend ein kurzes Wort zum Unterschied zwischen funktionalen Anforderungen und Qualitätsattributen, auch bekannt als nicht-funktionale Anforderungen.

Funktionale Anforderungen beziehen sich auf Aktionen, das heißt, den Prozess, den ein System durchführen muss, während Qualitätsattribute sich darauf beziehen, wie ein System sein sollte oder auf Funktionsbeschränkungen.

Die nachfolgende Tabelle bietet Beispiele von Funktionalen Anforderungen und Qualitätsattribute.

„Bitte halten Sie das Video an und schauen Sie sich die folgende Tabelle an.“

Funktionale Anforderungen	Qualitätsattribute (nicht-funktionale Anforderungen)
Der Benutzer MUSS sich über eine Web-Oberfläche anmelden können	Das System MUSS auf Anmeldeanfragen innerhalb von 1 Sekunde reagieren (Leistung)
Das System muss dem Benutzer alle vergangenen und aktuellen Transaktionen anzeigen	Der Status der aktuellen Transaktionen muss in 10 ms aktualisiert werden. (Leistung)
Wenn sich ein Kunde im System registriert, muss das System eine E-Mail senden	Die E-Mail an neu registrierte Benutzer muss 2 Sekunden nach der Registrierung gesendet werden (Leistung)
	Das System muss auf Android, Windows und iOS laufen (Betriebsfähigkeit).
	Das System muss sich drahtlos mit Druckern verbinden können (Betriebsfähigkeit).

Eine weitere wichtige Unterscheidung betrifft Anforderungen und Spezifikationen, da beide Begriffe manchmal als synonym verwendet werden. Sie sind zwar ähnlich, aber nicht identisch. Spezifikationen sind detaillierter und technischer als Anforderungen. Sie enthalten spezifische Maße, Materialien, Methoden und sogar Algorithmen, die während des Entwicklungsprozesses verwendet werden. Anforderungen hingegen beschreiben die allgemeinen Funktionen, die das System oder Produkt erfüllen muss, ohne sich auf die spezifische Implementierung einzulassen.

Rekapitulieren wir die hier behandelten Begriffe folgendermaßen: Die drei Elemente – funktionale Anforderungen, Qualitätsattribute und Spezifikationen – spielen unterschiedliche, aber miteinander verbundene Rollen in der Entwicklung und dem Design von Produkten oder Systemen:

• Funktionale Anforderungen: Diese definieren, was das Produkt oder System tun soll. Sie beschreiben die spezifischen Verhaltensweisen, Funktionen und Aufgaben, die das System ausführen muss, um die Bedürfnisse der Benutzer oder Stakeholder zu erfüllen.
• Qualitätsattribute: Auch als nicht-funktionale Anforderungen bekannt, beschreiben diese, wie das Produkt oder System sein soll. Sie betreffen die allgemeinen Eigenschaften und Merkmale des Systems, wie Leistung, Zuverlässigkeit, Benutzerfreundlichkeit, Sicherheit und Wartbarkeit, die beeinflussen, wie gut das System seine Aufgaben erfüllt.
• Spezifikationen: Dies sind detaillierte, technische Beschreibungen, die angeben, wie die funktionalen Anforderungen und Qualitätsattribute umgesetzt werden sollen. Sie bieten konkrete Anweisungen und Richtlinien für die Entwicklung und das Design des Produkts oder Systems, einschließlich Materialien, Architekturen, Algorithmen und technischen Standards, die befolgt werden müssen.

Die Zusammenfassung lautet wie folgt:

• Die Liste der funktionalen Anforderungen, also was das System tun muss, und die Qualitätsattribute, also wie das System sein soll, müssen von den relevanten Stakeholdern vereinbart werden, indem sie einer Priorisierungsmethode folgen, zum Beispiel der MoSCoW-Methode.
• Es stehen verschiedene Techniken zur Erhebung von Anforderungen zur Verfügung.
• Die Unzuverlässigkeit der anfänglich gesammelten Anforderungen kann die Notwendigkeit eines weniger prädiktiven und mehr iterativen oder inkrementellen Ansatzes für das gesamte Projekt bestimmen.
• Es ist wichtig, sicherzustellen, dass die gesammelten Anforderungen tatsächlich umgesetzt werden. Dazu kann eine Nachverfolgbarkeitsmatrix verwendet werden.

 

 

 

 

 

2.5.2 Inhalt und Umfang

Der Inhalt dieses Abschnitts wird Ihnen helfen, die beiden Teile der Beschreibung des Projektinhalts und -umfangs zu verstehen: nämlich den Produkt- und den Projektinhalt und -umfang. Das bedeutet, es handelt sich nicht nur um eine detaillierte Beschreibung des Produkts, sondern auch um eine detaillierte Beschreibung der Arbeit zur Erstellung dieses Produkts.

Die Beschreibung des Projektinhalts und -umfangs ist einer der Eckpfeiler des Projektmanagementplans, den wir Schritt für Schritt entwickeln. Sie beantwortet die Frage: Was wird gemacht? Die Definition des Umfangs und dessen Inhalts ermöglicht es, die Kosten, den Aufwand und die Fristen, die mit diesem Umfang und dem Inhalt innerhalb dieses Umfangs verbunden sind, zu schätzen.

Zu diesem Zeitpunkt der Planungsarbeit haben wir bereits wichtige Elemente entwickelt, die wir benötigen, um die Beschreibung des Projektinhalts und -umfangs zu erstellen.

• Zuerst haben wir den Projektauftrag, der alle gesammelten und vereinbarten Informationen der Projektinitiierung zusammenfasst.
• Außerdem haben wir Annahmen und Einschränkungen aus dem Projektauftrag zu Beginn der Planungsarbeiten aktualisiert.
• Schließlich können wir die Dokumentation der Anforderungen verwenden, um zu bestimmen, welche Anforderungen umgesetzt werden und welche nicht. Unwesentliche und ein Teil der optionalen Anforderungen werden als außerhalb des Umfangs erklärt und nicht umgesetzt.

Wenn wir einen prädiktiven Ansatz verwenden, kann die Beschreibung des Projektinhalts und -umfangs detailliert sein. Wenn wir einen iterativen Ansatz verwenden, wird die Beschreibung des Projektinhalts und -umfangs wahrscheinlich eine weniger präzise Sicht auf das Produkt und das gesamte Projekt bieten und eine detaillierte Beschreibung des Inhalts und Umfangs nur für die nächste Iteration definieren.

Die Liste der Elemente, die in einer Beschreibung des Projektinhalts und -umfangs enthalten sein sollten, lautet wie folgt:

• Eine Beschreibung des zu erstellenden Produkts, einschließlich der wichtigsten Liefergegenstände und ihrer jeweiligen Akzeptanzkriterien.
• Ausschlüsse, die explizit angeben, was außerhalb des Umfangs liegt, um die Erwartungen der Stakeholder zu managen.
• Aktualisierte Annahmen und Einschränkungen, die zu Beginn der Planungsaktivitäten überprüft wurden.
• Eine Beschreibung der erforderlichen Arbeit zur Herstellung des beschriebenen Produkts.

Nachfolgend sehen Sie ein Beispiel einer Beschreibung des Projektumfangs und -inhalts für unser Beispielprojekt eines Onlinesystems zur Verfolgung des Status von Transaktionen.

Produktumfang – Beschreibung.

Das Projekt erstellt ein webbasiertes System mit dediziertem Hosting, das mehrere Benutzer gleichzeitig verwalten kann. Das System bietet Echtzeitinformationen über den Status einer Transaktion gemäß einem vom Projekt erstellten Statusschema (Statusdefinition). Das System vergibt eindeutige Kennungen für jeden Kunden und jede Bestellung. Der Kunde kann seinen Benutzernamen über seine E-Mail-Adresse abrufen. Endbenutzer können Bestellungen aufgeben und den Status jeder Transaktion verfolgen, einschließlich Zahlung und Lieferung, sowie Details zu allen vergangenen Transaktionen. Das Projekt wird die Online-Lösung in einer Produktlinie implementieren, die während einer Analysephase zu Beginn der Umsetzung definiert wird. Weitere Produktlinien werden von einem nachfolgenden Projekt behandelt. Die erste Version des Online-Systems wird nur Deutsch und Englisch unterstützen.

Schlüsselliefergegenstände.

• Schnittstelle mit dem verbesserten Finanzsystem, das vom „Projekt “Finanzsystem geliefert wird.
• Aktualisierungen des Kundenbeziehungsmanagementsystems und des Verkaufsmanagementsystems.
• Integration mit dem Bestellsteuerungssystem für Lieferanten innerhalb des Umfangs.
• Automatisierung der derzeit manuellen Logistiksteuerung.
• Gesamtintegration.
• Neue Startseite für Kunden.
• Leistungsberichte.

Akzeptanzkriterien.

• 100% aller als unverzichtbar klassifizierten Anforderungen für das Produkt und für jede Komponente.
• 80% aller als wichtig klassifizierten Anforderungen für das Produkt und für jede Komponente.

Ausschlüsse.

• Marketingkampagne an Endbenutzer.
• Andere Produkte oder Produktlinien, außer der Auswahl, die während einer Analysephase zu Beginn der Projektumsetzung getroffen wird.
• Jede Sprache, die nicht Deutsch oder Englisch ist.

Projektinhalt und -umfang (erforderliche Arbeit).

• Analyse, Design und Implementierung von Schnittstellen mit Finanz-, CRM- und Handelssystemen.
• Prüfung des CRM- und Verkaufssystems, um festzustellen, ob eine Aktualisierung der aktuellen Systeme oder die Einführung neuer Systeme bevorzugt wird.
• Umsetzung der Aktualisierung des CRM-Verkaufssystems oder Migration zu neuen CRM-Verkaufssystemen, einschließlich Datenkonvertierung und -migration.
• Festlegung von Auswahlkriterien für ein Logistiksystem, Auswahl eines Logistikmanagementpakets, Anpassung und Implementierung.
• Analyse von Produkten und Produktlinien zur Auswahl der im Projektumfang enthaltenen Produkte.
• Untersuchung der potenziellen Lieferanten, die im Projektumfang berücksichtigt werden sollen.
• Integration mit den Systemen der ausgewählten Lieferanten für die gewählte Produktpalette.
• Entwicklung einer neuen Startseite für die Kunden.
• Definition und Erstellung von Leistungsberichten.

Annahmen.

• Ein engagiertes Sponsoring von der Geschäftsführung von XZ wird bereitgestellt.
• Die Finanz- und Verkaufsabteilungen werden effektiv und effizient zusammenarbeiten und die erforderlichen Experten gemäß des Terminbasisplans bereitstellen.
• Die ausgewählten Lieferanten werden effektiv und effizient zusammenarbeiten und die erforderlichen Experten gemäß des Terminbasisplans bereitstellen.
• Die Projekte “Finanzsystem” und “Definition der Statuten” werden ihre Ergebnisse innerhalb der im Terminbasisplan definierten Fristen liefern.

Einschränkungen.

• Das Online-System muss auf iOS, Android und Windows funktionieren.
• Das Logistiksystem muss externe Kosten im Hinblick auf Bargeldabflüsse haben, die den Betrag xx nicht überschreiten.
• IT-Consulting XX wird als Anbieter von Beratungsdienstleistungen genutzt werden.

Zusammenfassend lässt sich sagen, dass die Beschreibung des Projektinhalts und -umfangs aus zwei Hauptkomponenten besteht: dem Produktumfang und dem Projektumfang. Der Produktumfang beschreibt, was das zu erstellende Produkt ist und was es leisten soll. Der Projektumfang umfasst eine zusammenfassende Beschreibung der erforderlichen Arbeit, um das Produkt zu erstellen. Durch die Beschreibung des Projektinhalts und -umfangs werden auch die Grenzen des Projekts geklärt, indem angegeben wird, was innerhalb und was außerhalb des Umfangs liegt. Alles, was außerhalb des Umfangs liegt, wird nicht durchgeführt, und es wird deutlich, dass es nicht Teil des Projekts ist. Darüber hinaus werden in der Beschreibung des Projektinhalts und -umfangs die aktuellen Annahmen und Einschränkungen aufgelistet.

 

 

2.5.3 Projektstrukturplan (WBS)

In diesem Abschnitt wird erläutert, was ein Projektstrukturplan ist, auch bekannt als PSP auf Deutsch und WBS auf Englisch, sowie wie er erstellt wird. WBS steht für “Work Breakdown Structure” auf Englisch.

Ein Projektstrukturplan ist eine hierarchische Aufgliederung der Arbeit, die vom Projektteam durchgeführt werden muss. Der Zweck dieser Struktur besteht darin, komplexe Arbeit in kleinere, handhabbare Teile zu unterteilen. Als Ergebnis dieser Aufteilung ist der Projektstrukturplan eines der wichtigsten Dokumente im Projektmanagement.

Es gibt zwei Arten von WBS. Der erste Typ basiert auf Liefergegenständen, während der zweite Typ auf den Projektphasen basiert. Der am häufigsten verwendete Ansatz ist der liefergegenstandsbasierte Ansatz. Der Hauptunterschied zwischen den beiden Ansätzen liegt in den Elementen, die auf der ersten Ebene der Struktur identifiziert werden.

Hier ist ein Beispiel für eine liefergegenstandsbasierte WBS. Die Elemente der ersten Ebene sind zusammenfassende Beschreibungen der Liefergegenstände, während die Elemente der zweiten Ebene die einzelnen Liefergegenstände darstellen, die den jeweiligen zusammengefassten Liefergegenstand der ersten Ebene ausmachen.

Hier ist ein Beispiel für eine phasenbasierte WBS. Die Elemente der ersten Ebene sind Phasen dieses Projekttyps. Die Elemente der zweiten Ebene sind die Liefergegenstände jeder Phase.

Eine gute Struktur für den Projektstrukturplan (WBS) ist einfach die, die das Projektmanagement erleichtert. Jedes Projekt ist unterschiedlich. Jeder Projektmanager ist unterschiedlich. Und somit ist jede Struktur für die Projektstrukturplan anders. Daher ist die richtige Struktur für die Projektstrukturplan diejenige, die die gesamte zu erledigende Arbeit am besten erfasst.

Es ist oft ratsam, mit einer Struktur für die Projektstrukturplan nach Liefergegenständen zu beginnen und nachdem alle Elemente identifiziert wurden, ohne sich um die Phasen zu kümmern, diese bereits unterteilten Elemente in eine andere Struktur für die Projektstrukturplan basierend auf Phasen zu überführen, wodurch die Erstellung des Projektterminplans vorbereitet wird.

Wie baut man einen Projektstrukturplan auf?

Die beste Art, einen Projektstrukturplan aufzubauen, ist, auf der obersten Ebene mit den Zusammenfassungsliefergegenständen zu beginnen und von dort aus nach unten zu arbeiten.

Dies ist eine Teamarbeit und keine Aufgabe, die dem Projektmanager allein zugewiesen wird. Der Projektmanager benötigt das technische Wissen und die Erfahrung der Teammitglieder, denn sie sind die technischen Experten, die wissen, was speziell getan werden muss, um den jeweiligen Liefergegenstand zu erstellen. Durch die Teamarbeit mit den Spezialisten wird nicht nur das Risiko verringert, Dinge zu übersehen, die getan werden müssen, sondern es hilft auch, das Team für das Projekt zu gewinnen.

• Als Team beginnen wir zunächst mit der Identifizierung der Zusammenfassungsliefergegenstände auf der obersten Ebene.
• Anschließend organisieren sich kleinere Gruppen im Team, um diese Zusammenfassungsliefergegenstände in kleinere Komponenten aufzuteilen.
• Abschließend kommt das gesamte Team zusammen, um die Ergebnisse zu überprüfen und etwaige Mängel zu beheben.
• Falls ein Teil des Teams nicht anwesend ist, arbeiten wir mit den verfügbaren Informationen, um den Detailgrad zu erreichen, der möglich ist. Wenn später weitere Spezialisten dem Projektteam beitreten, können zusätzliche Details zum ursprünglichen Projektstrukturplan hinzugefügt werden, insbesondere in den Bereichen, die anfänglich zu grob zusammengefasst wurden.

Wir starten damit, den Projektumfang und die im Dokument erwähnten Liefergegenstände zu verwenden, um die Zusammenfassungsliefergegenstände auf oberster Ebene zu identifizieren. Anschließend zerlegen wir jedes dieser Zusammenfassungsliefergegenstände in kleinere Teile.

Nehmen wir das Zusammenfassungsliefergegenstand Logistik als Beispiel, da dies das komplizierteste zu sein scheint, weil für die Logistik in unserem Beispiel derzeit kein bestehendes System vorhanden ist und alles von Grund auf neu erstellt werden muss.

Angenommen, das Expertenteam schlägt vor, dass für die Entwicklung eines Logistikmanagementsystems ein Anbieter für solche Lösungen benötigt wird. Infolgedessen wird dem Lebenszyklus gefolgt, den dieser Anbieter vorschlägt. Das bedeutet, dass im Moment nur bekannt ist, dass eine Lösung für das Logistikmanagement entwickelt und implementiert wird, die mit Hilfe eines spezialisierten Dienstleisters auf diesem Gebiet erstellt wird.

In Bezug auf die Beschaffung eines spezialisierten Dienstleisters erinnert uns ein Mitglied der Einkaufsabteilung daran, dass der Beschaffungsprozess des Unternehmens für neue Anbieter immer derselbe ist und dass wir diesen Unternehmensprozess übernehmen müssen, um den neuen Anbieter zu erhalten, den wir benötigen.

In Bezug auf die notwendigen Elemente für die Entwicklung und Implementierung einer Lösung für das Logistikmanagement haben wir derzeit nur begrenzte Informationen. Daher können wir vorläufig ein generisches Lebenszyklusmodell verwenden.

Die meisten Projektmanager definieren Arbeitspakete, die zwischen 40 und 80 Stunden Aufwand erfordern. Das Detailniveau der Arbeitszerlegung sollte dem gewünschten und verwaltbaren Detailgrad entsprechen.

Verschiedene Teile eines Projekts können unterschiedliche Detailgrade in der Arbeitszerlegung erfordern. Wir machen uns keine Sorgen über die anfängliche Organisation unseres Projektstrukturplans, da sie später bei Bedarf neu organisiert werden kann, wenn wir mehr über das Projekt erfahren.

Ein letztes Wort zur Struktur des Projektstrukturplans und zu agilen Lebenszyklen: Es gibt oft das Missverständnis, dass ein Projektstrukturplan eine Zeitverschwendung ist, wenn ein agiler Ansatz verwendet wird. Diese Annahme basiert auf der Vorstellung, dass bei einem agilen Projekt der Projektumfang nicht zu Beginn festgelegt wird. Das ist zwar richtig, jedoch zerlegen auch Projekte mit einem agilen Entwicklungsansatz die Arbeit in kleinere Bestandteile und entwickeln sowohl eine Roadmap für einen guten Überblick über die Funktionalitätsumsetzung in den verschiedenen Phasen der Produktentwicklung (Releases genannt in Agile) als auch eine feinere Zergliederung der Komponenten anhand des Produktbacklogs.

Dieses Backlog ist eine dynamische Liste ausstehender Arbeiten, die ständig aktualisiert und vor Beginn der nächsten Iteration nach Priorität geordnet wird, um Anforderungen in der vom Kunden bevorzugten Reihenfolge umzusetzen. Das heißt, das Backlog ist eine Art Projektstrukturplan, der ständig nach Implementierungsreihenfolge neu organisiert wird.

Außerdem, ähnlich wie wir es mit den Arbeitspaketen eines traditionellen Projektstrukturplans machen, werden auch die Elemente des Backlogs feiner zerlegt, wenn sie kurz vor der Entwicklung stehen und detaillierter erforscht werden.

Es gibt keinen Grund, warum wir nicht ähnlich vorgehen können, wenn ein eher plangetriebener Entwicklungsansatz verwendet wird, indem wir die zu erledigende Arbeit bis zum nächsten Meilenstein oder für die nächste Iteration weiter zerlegen und detaillierter definieren. Dabei nutzen wir die traditionelle Technik der sogenannten Wellenplanung, die darin besteht, Details allmählich zu planen, je weiter das Projekt voranschreitet.

In Zusammenfassung können wir die zu erledigende Arbeit entweder nach den Liefergegenständen, die die Lösung bilden, oder nach den Projektphasen zerlegen. Dadurch erhalten wir die Möglichkeit, die Arbeit schrittweise von Meilenstein zu Meilenstein feiner zu gliedern, indem wir eine hybride Methode der schrittweisen Zerlegung anwenden, während das Projekt fortschreitet.

Das Wichtigste ist, dass wir die zu erledigende Arbeit identifizieren. In einer idealen Welt könnten wir die gesamte bevorstehende Arbeit erfassen. Doch in der Realität ist uns bewusst, dass uns ein Teil, vielleicht sogar ein wichtiger, entgehen könnte. Aus diesem Grund bilden wir Reserven für Unvorhergesehenes, über die wir in einem anderen Abschnitt sprechen werden.

Verschiedene Detailgrade der Zerlegung können nebeneinander existieren. Für Projektteile, die zunächst nur grob zergliedert werden können, werden mehr Details nach und nach hinzugefügt, sobald mehr Informationen verfügbar sind. Die detaillierteste, also die niedrigste Ebene des Projektstrukturplans, sind die Arbeitspakete. Diese müssen mit dem erforderlichen Detailgrad definiert werden, um sie einem Team zuzuweisen, das sie unter der Leitung eines jeweiligen Arbeitspaket-Leiters erstellen wird.

 

 

 

 

 

2.5.4 Arbeitspakete

Dieser Abschnitt hilft Ihnen zu verstehen, was Arbeitspakete sind, wie sie definiert und delegiert werden, und welche Verantwortlichkeiten mit ihnen verbunden sind.

Beginnen wir mit den Definitionen:

• Die Methodik der britischen Regierung, genannt Prince2, definiert ein Arbeitspaket als eine Sammlung von Informationen über eines oder mehrere erforderliche Produkte. Diese Informationen werden vom Projektmanager zusammengestellt, um die Verantwortung für die Arbeit oder Lieferung offiziell an einen Teamleiter oder Teammitglied zu übergeben.
• Die ISO-Norm 21502 definiert ein Arbeitspaket als eine Gruppe von Aktivitäten, die einen definierten Umfang, Liefergegenstände, Terminplan und Kosten haben.
• Das PMI definiert im PMBOK Guide ein Arbeitspaket als die Arbeit, die auf der untersten Ebene des Projektstrukturplans definiert wird und deren Kosten und Dauer geschätzt und gesteuert werden kann.
• Die deutsche Norm DIN 69901 definiert ein Arbeitspaket als die kleinste in sich abgeschlossene Arbeitseinheit im Projekt, für die Aufwand, Kosten und Termine abgeschätzt sowie verfolgt werden können.

Welche Elemente müssen in diesem Informationspaket definiert werden?

Die Elemente, die in einem Arbeitspaket definiert werden müssen, ähneln der Definition eines Projekts. Tatsächlich kann das, was für das anfragende Unternehmen ein Arbeitspaket ist, für ein Unterteam, wie zum Beispiel einen Subunternehmer, ein eigenständiges Projekt darstellen. Das Arbeitspaket muss den Umfang und Inhalt der Arbeit, die Liefertermine und Kosten klar definieren und muss zwischen dem Projektmanager und der für dieses Arbeitspaket verantwortlichen Person vereinbart werden. Darüber hinaus muss es klären, wie verschiedene Aspekte verwaltet werden sollen, wie beispielsweise die Kommunikation, Berichterstattung, die Behandlung von Problemen und Änderungen.

Hier ist ein Beispiel für eine Definition eines Arbeitspakets:

Unter Verwendung des Beispiels unserer Online-Lösung zum Verfolgen von Transaktionen nehmen wir an, dass die Aufgabe, einen Anbieter zu beschaffen, in Form eines Arbeitspakets an das Projektteammitglied aus der Einkaufsabteilung delegiert wird.

Nachfolgendes Beispiel zeigt die Definition eines Arbeitspakets.

Bitte beachten Sie, dass ein Arbeitspaket das Ergebnis der Aufteilung eines Liefergegenstands in die notwendigen Aktivitäten zu seiner Erstellung ist.

Jedes Arbeitspaket folgt einem Fertigstellungsprozess, der als Lebenszyklus bezeichnet wird. Die Beschaffungsabteilung beispielsweise folgt bei der Auswahl eines Anbieters einem standardisierten Lebenszyklus, der einem vorkonfigurierten und wiederholbaren Prozess entspricht. Sollte der Liefergegenstand, der durch das Arbeitspaket realisiert werden soll, keinen vorgegebenen Lebenszyklus aufweisen, muss der Arbeitspaketleiter gemeinsam mit dem Arbeitspaketteam die erforderlichen Schritte erörtern. Dieser Vorgang ähnelt dem Prozess der Erstellung eines Projektstrukturplans, den wir in einem früheren Abschnitt erläutert haben.

Zu Beginn eines Projekts ist eine detaillierte Definition und Planung aller Arbeitspakete in der Regel nicht möglich. Stattdessen ist es üblich, nur jene Arbeitspakete detailliert zu definieren und in Detail zu planen, die in der unmittelbar bevorstehenden Phase oder bis zum nächsten Meilenstein fertiggestellt werden sollen. Dieser Ansatz einer schrittweisen Definition und Detailplanung der Arbeitspakete wird als Wellenplanung bezeichnet.

Es ist von Bedeutung, auf die Parallelen zwischen der Wellenplanung und agilen Methoden hinzuweisen, insbesondere in Bezug auf die Art und Weise, wie agile Teams Aufgaben aus dem Backlog aufbrechen. Ein Backlog, verstanden als eine Liste noch zu erledigender Arbeiten, kann Anforderungen (in der agilen Terminologie oft ‘User Stories’ genannt) oder andere Aufgabentypen umfassen. Sowohl bei der Wellenplanungstechnik aus dem traditionellen Projektmanagement als auch bei der Backlogtechnik aus agilen Methoden findet eine stufenweise Detaillierung der Arbeit statt, wodurch ein Team schrittweise zu einem detaillierten Aktionsplan gelangt. Im Kern beider Techniken geht es um die allmähliche Verfeinerung der fehlenden Arbeit, bis hin zu der Ebene der Detailaktivitäten. Es ist ein Irrglaube, dass ein plangetriebener Ansatz alle Details von Projektanfang bis zum Projektende am Projektanfang definieren und planen muss.

Der Arbeitspaketleiter.

Ein Arbeitspaketleiter, auch als Teamleiter bekannt, ist dem Projektmanager gegenüber für die Leitung, Steuerung und Lieferung der ihm zugewiesenen Ergebnisse, wie in einem Arbeitspaket definiert, verantwortlich.

Der Arbeitspaketleiter kann sowohl aus demselben Unternehmen wie der Projektmanager stammen als auch aus einem anderen Unternehmen, zum Beispiel einem Subunternehmen, was in vielen Projekten sehr üblich ist.

Die Verantwortlichkeiten des Arbeitspaketleiters ähneln denen des Projektmanagers für das gesamte Projekt und umfassen folgende Punkte:

• Das Arbeitspaketteam leiten, um das Produkt mit der erforderlichen Qualität, rechtzeitig und innerhalb des Budgets zu vervollständigen und zu liefern.
• Planen, kontrollieren und über den Fortschritt der Arbeiten an den Projektmanager berichten.
• Risiken und Probleme steuern, einschließlich Eskalation, falls notwendig.
• Umfangsänderungen kontrollieren und die Genehmigung für diese Änderungen suchen, wenn sie die Autorität des Arbeitspaketleiters überschreiten.

In kleinen Projekten kann der Projektmanager zusätzlich die Aufgaben eines Arbeitspaketleiters übernehmen und ein oder mehrere technische Teams führen, um verschiedene Komponenten der Lösung zu entwickeln. Es ist jedoch wichtig zu verstehen, dass der Projektmanager, auch nach der Delegation von Arbeitspaketen, nicht einfach die Verantwortung abgeben und annehmen kann, dass alles wie von selbst läuft.

Die Überwachung und Steuerung der Arbeitspakete bleibt ein zentraler Bestandteil der Aufgaben des Projektmanagers und umfasst folgende Bereiche:

• Die Initiierung von Arbeitspaketen gemäß dem Projektmanagementplan oder als Reaktion auf Risiken und Probleme sicherstellen.
• Verantwortlichkeiten für jedes Arbeitspaket einem Arbeitspaketleiter zuweisen.
• Den Plan für jedes Arbeitspaket überprüfen und genehmigen, nachdem sichergestellt wurde, dass er mit dem Gesamtprojektplan und der jeweiligen Projektphase übereinstimmt.
• Die Planung und Ausführung von Integrationslieferungen zwischen den Arbeitspaketen überwachen, um sicherzustellen, dass diese den Anforderungen entsprechen.
• Den Fortschritt der Arbeit kontinuierlich überprüfen. Bei der Verwaltung von Risiken, Änderungen und Problemen gemäß den in den Hilfsmanagementplänen definierten Verantwortlichkeiten handeln.
• Die Qualität der Lieferergebnisse sicherstellen.
• Die Fertigstellung und den Abschluss jedes Arbeitspakets bestätigen.

Wenn der Projektmanager und der Arbeitspaketleiter verschiedenen Organisationen angehören, insbesondere unterschiedlichen Unternehmen, können die Abläufe komplexer werden. Es gibt Fälle, in denen Subunternehmer Informationen zurückhalten möchten, bis zum festgelegten Lieferdatum. Ein solcher Ansatz kann jedoch häufig zu unerwarteten Problemen führen. Daher liegt es in der Verantwortung des Projektmanagers, klare Erwartungen zu setzen und die Einhaltung vereinbarter Regeln sicherzustellen. Der ideale Zeitpunkt, um diese Aspekte zu klären, ist während der Verhandlungen über die Zuweisung eines Arbeitspakets an einen Arbeitspaketleiter.

Zusammenfassend kann in einem kleinen Projekt der Projektmanager sowohl die Rolle des Projektmanagers als auch die des Arbeitspaketleiters übernehmen, indem er sich direkt um die technische Umsetzung und die Erstellung der Liefergegenstände kümmert. In komplexeren Projekten ist es hingegen üblich, dass der Projektmanager Arbeitspakete an spezialisierte Teilteams delegiert, die jeweils von einem Arbeitspaketleiter geführt werden. Diese Arbeitspaketleiter sind dem Projektmanager unterstellt. Zu den zentralen Aufgaben des Projektmanagers gehören das Definieren, Delegieren, Überprüfen, Integrieren und Akzeptieren der Arbeitspakete.

 

 

2.5.5 Entwicklung des Umfangs- und Inhaltsbasisplan hin zum Projektumfang und -inhalt

Dieser Abschnitt fasst die Arbeit zusammen, die zur Erstellung des Inhalts- und Umfangsbasisplans notwendig war.

Ein Basisplan ist eine offiziell genehmigte Version eines Arbeitsergebnisses, das ausschließlich durch formelle Änderungsverfahren modifiziert werden darf und als Maßstab für den Vergleich mit den tatsächlichen Ergebnissen dient. Er fungiert somit als Referenzpunkt zur Leistungsmessung.

Der Inhalts- und Umfangsbasisplan umfasst die Beschreibung des Projektinhalts und -umfangs, und den Projektstrukturplan bis hinunter auf die Ebene der Arbeitspakete. Als genehmigter Dokumentensatz für die Projektleitung ist er verbindlich und unterliegt strikten Änderungskontrollprozessen. Weder der Projektmanager noch Teammitglieder dürfen diesen oder einen anderen Basisplan ohne ein formelles Änderungsverfahren ändern.

Die Bündelung der Beschreibung des Projektumfangs und -inhalts, des Projektstrukturplans und der Arbeitspakete ergibt der Inhalts- und Umfangsbasisplan, der den Rahmen dessen definiert, was im Projekt umgesetzt werden soll.

Es ist wichtig zu beachten, dass der Inhalts- und Umfangsbasisplan einer der drei klassischen Basispläne in der Projektplanung ist, neben dem Termin- und dem Kostenbasisplan. Für detailliertere Informationen sollten die Abschnitte zur Beschreibung des Projektinhalts und -umfangs, zum Projektstrukturplan sowie zu den Arbeitspaketen konsultiert werden.

 

.

 

 

 

 

 

2.5.6 Schätzung der Dauer und Kosten

In diesem Abschnitt erfahren Sie, wie Sie Techniken zur Schätzung von Zeit und Kosten anwenden und die passendste Schätzmethode auswählen können. Die zwei zentralen Fragen in jedem Projekt sind: ‘Wie lange wird es dauern?’ und ‘Wie viel wird es kosten?’

Präzise Kostenschätzungen und Zeitrahmen sind von großer Bedeutung, da auf ihrer Grundlage entschieden wird, ob ein Projekt durchgeführt werden soll oder nicht. Einmal genehmigt, werden diese Schätzungen zu einem wesentlichen Bestandteil des Projektmanagementplans und bilden den Ausgangspunkt für den Fortschrittsmessungsbasisplan, anhand dessen die tatsächliche Leistung bewertet wird. Es ist daher entscheidend, die Grundlage für die Leistungsbewertung als Projektmanager sorgfältig zu legen.

Ein guter Startpunkt für Schätzungen ist die Analyse des Aufwands und der Dauer der einzelnen Arbeitspakete. ‘Aufwand’ bezieht sich auf die benötigten Arbeitsstunden für eine Aktivität, z.B. 100 Stunden. ‘Dauer’ bezieht sich auf die Zeit, die benötigt wird, um diesen Aufwand zu leisten, z.B. 3 Wochen, wenn eine Person die Arbeit verrichtet. Indem wir Aufwand und Dauer für jedes Arbeitspaket schätzen, legen wir die Grundlage für die Berechnung von Kosten und die Erstellung des Terminplans. Zusätzlich müssen wir auch zeitunabhängige Faktoren wie Materialkosten und sonstige Ausgaben, wie Reisekosten, berücksichtigen.

Während der Initiierungs- und Planungsprozessen arbeitet der Projektmanager eng mit den jeweils zur Verfügung stehenden Teammitgliedern zusammen, um erste Schätzungen für Zeit und Kosten zu erstellen. Diese anfänglichen Schätzungen können im Verlauf des Projekts durch die Beiträge der Personen, die den Arbeitspaketen zugeordnet sind, weiter präzisiert werden. Die Teammitglieder der Arbeitspakete sind Experten in ihren jeweiligen Bereichen und verfügen über detailliertes Wissen über die Anforderungen ihrer Arbeitspakete. Sie zerlegen die Arbeitspakete in einzelne Aktivitäten und berücksichtigen dabei die spezifischen Bedingungen, unter denen die Arbeiten durchgeführt werden. Ihre Beteiligung am Schätzprozess fördert nicht nur eine realistischere Einschätzung, sondern steigert auch ihr Engagement für die Einhaltung der Schätzungen, da sie direkt an deren Erstellung beteiligt waren.

Es ist wichtig zu erkennen, dass Schätzungen nicht von Anfang an perfekt sein müssen. Für die initiale Projektauswahl kann eine Schätzung mit einer Genauigkeitsspanne von plus/minus 75% durchaus angemessen sein. Mit zunehmendem Verständnis des Projekts während der Planungsprozessen verbessert sich die Genauigkeit der Schätzungen. In einem idealen Szenario, besonders bei sehr vorhersehbaren Projekten, kann die Genauigkeitsspanne auf plus/minus 10% reduziert werden.

Diverse Techniken stehen zur Verfügung, um Schätzungen auf der Projektebene, der Ebene der Arbeitspakete und auf Aktivitätsebene vorzunehmen.

• Top-Down-Techniken eignen sich besonders für schnelle und grobe Schätzungen. Sie basieren auf Analogien oder Verhältnissen zu ähnlichen Projekten oder Arbeitspaketen, die bereits in der Vergangenheit umgesetzt wurden. Mit dieser Methode lassen sich das gesamte Projekt, einzelne Phasen oder Liefergegenstände zügig einschätzen, allerdings oft auf Kosten der Genauigkeit. Ein typisches Beispiel wäre: „Dieses Projekt ähnelt Projekt X und wird daher voraussichtlich ähnlich viel Zeit und Kosten in Anspruch nehmen“. Alternativ kann auch die Größe oder Komplexität als Vergleichsmaßstab herangezogen werden: „Das neue Projekt ist doppelt so umfangreich oder komplex und wird dementsprechend auch doppelt so viel Zeit und Kosten erfordern“. Top-Down-Schätzungen sind besonders nützlich, um Projekte für ein Portfolio auszuwählen, ohne dabei eine umfassende Planung vornehmen zu müssen.
• Bottom-Up-Techniken beginnen auf der Ebene der detailliertesten Elemente im Projektstrukturplan und arbeiten sich nach oben. Jede Aufgabe innerhalb der Struktur wird individuell geschätzt und die Ergebnisse werden summiert. Obwohl dieser Ansatz aufwendiger ist als pauschale Top-Down-Schätzungen, führt er zu präziseren Ergebnissen und ermöglicht es, die Plausibilität von groben Schätzungen zu überprüfen. Es ist nicht unüblich, dass Pläne, die ursprünglich auf Top-Down-Schätzungen basierten, durch detailliertere Bottom-Up-Schätzungen angepasst werden müssen.

Ein pragmatischer Ansatz könnte sein, mit einer Top-Down-Schätzung zu beginnen und diese dann zu verfeinern, indem für jedes Arbeitspaket in neuen Projektphasen detaillierte Schätzungen unter Einbeziehung der jeweiligen Arbeitspaketleiter vorgenommen und aggregiert werden.

Idealerweise sollten mehrere Schätzungstechniken kombiniert werden, um die Genauigkeit zu erhöhen und die Ergebnisse zu validieren. Die Verwendung eines Durchschnittswerts aus verschiedenen Techniken stärkt die Glaubwürdigkeit der Schätzungen. Dies ist besonders wichtig, wenn man mit kritischen Rückfragen von Stakeholdern konfrontiert ist, die wissen möchten, warum ein Projekt bestimmte Kosten oder Zeiträume erfordert.

Bei der parametrischen Modellierungstechnik wird der Aufwand, die Dauer oder die Kosten eines Projekts auf Basis eines bekannten Parameters berechnet und auf das gesamte Projekt extrapoliert. Ein klassisches Beispiel aus dem Bauwesen: Wenn ein Quadratmeter Baufläche 1.000 € kostet, dann belaufen sich die Kosten für 100 Quadratmeter auf 100.000 €. Diese Methode ist besonders effektiv, wenn der zugrunde liegende Parameter gut verstanden und über verschiedene Projektgrößen hinweg skalierbar ist, was eine schnelle und zuverlässige Schätzung ermöglicht.

Die Einbeziehung von Expertenurteilen, die mit der Materie vertraut sind, ist eine bewährte Schätzungstechnik. Diese Experten können aus der eigenen Organisation, aus externen Beratungsunternehmen oder von Lieferanten kommen. Wenn mehrere Experten einbezogen werden, kommt die als Delphi-Methode bekannte Technik zum Einsatz, die weiter unten im Text genauer erläutert wird.

Lassen Sie uns Schätzungstechniken anhand eines Beispiels praktizieren: Wir betrachten die Entwicklung eines Online-Systems zur Überwachung des Status von Transaktionen, mit dem Ziel, deren Transparenz zu erhöhen. Als Ausgangspunkt nehmen wir die Implementierung eines Verkaufsmanagementsystems, das in der Vergangenheit umgesetzt wurde und dessen Projektlaufzeit 8 Monate betrug und 1.000.000 Euro kostete.

Zusätzlich gehen wir davon aus, dass das neue Projekt zum Transaktionsüberwachungssystem hinsichtlich Komplexität und Umfang dem vorherigen Verkaufsmanagementprojekt ähnelt. Basierend auf dieser Annahme könnten 8 Monate und 1.000.000 Euro als grobe Top-Down-Schätzung dienen. Sollten wir jedoch zu der Einschätzung kommen, dass das Transaktionsüberwachungssystem aufgrund der Einbeziehung von Lieferanten doppelt so komplex ist, wäre eine Anpassung der Schätzung auf 16 Monate und 2 Millionen Euro angebracht.

Ein Beispiel für die Anwendung der parametrischen Modellierung bei der Schätzung eines Arbeitspakets könnte so aussehen: Angenommen, die Implementierung eines Online-Berichts erfordert einen Aufwand von 10 Stunden, nimmt eine Dauer von 2 Tagen in Anspruch und verursacht Kosten in Höhe von 2.000 Euro. Basierend auf dieser Schätzung würde die Implementierung von 5 solcher Online-Berichte einen Gesamtaufwand von 50 Stunden, eine Gesamtdauer von 10 Tagen und Gesamtkosten von 10.000 Euro bedeuten.

Die Delphi-Technik involviert mehrere Experten, die jeweils aufgefordert werden, unabhängig voneinander eine Schätzung abzugeben, um gegenseitige Beeinflussungen zu vermeiden. Die Ergebnisse werden anschließend allen Experten des Panels anonymisiert mitgeteilt, um den Einfluss, den die Reputation oder Autorität einzelner Experten ausüben könnte, zu minimieren. Die Experten werden daraufhin gebeten, ihre Schätzungen zu überdenken und erneut abzugeben. Dieser Prozess wird mehrfach wiederholt, bis schließlich der Durchschnitt der letzten Schätzrunde als Ergebnis verwendet wird.

Risikozuschlag.

Die Festlegung eines Risikozuschlags basiert auf der Genauigkeit und Zuverlässigkeit der durchgeführten Schätzungen. Bei Projekten, mit denen man bereits Erfahrung hat und bei denen mehrere Schätzungstechniken zum Einsatz kommen, sind die Schätzungen in der Regel zuverlässiger. Dies führt zu einem niedrigeren Unsicherheitsniveau und ermöglicht einen geringeren Risikozuschlag. Im Gegensatz dazu erfordern Projekte mit höherer Unsicherheit einen größeren Risikozuschlag, um potenzielle Abweichungen abzudecken.

Die grundlegende Regel bei der Festlegung eines Risikozuschlags lautet: Je weniger zuverlässig die Schätzung, desto höher der Risikozuschlag. Ein Zuschlag von 10% impliziert eine 90%ige Sicherheit, dass das Projekt den definierten Umfang innerhalb der geplanten Zeit und des geschätzten Budgets erreichen kann. Eine derart hohe Sicherheit erfordert ein erhebliches Maß an Selbstvertrauen und setzt voraus, dass das Projekt äußerst vorhersehbar und sorgfältig geschätzt wurde.

Stimmen Sie dieser Einschätzung zu?

Wie man eine gute Schätzung erstellt.

Die Erstellung einer guten Projektschätzung gleicht der Planung einer morgendlichen Fahrt zur Arbeit: Wir legen die Abfahrtszeit so fest, dass wir mit hoher Wahrscheinlichkeit pünktlich ankommen. An einigen Tagen ist die Fahrt zügig, vielleicht 30 Minuten, an den meisten Tagen benötigen wir jedoch 45 Minuten. Ein unerwarteter Unfall kann die Fahrtzeit auf eine Stunde erhöhen. Deshalb planen wir einen Zeitpuffer ein, um auch bei Überraschungen rechtzeitig zu erscheinen, nicht wahr? Die Größe dieses Puffers hängt davon ab, wie wichtig es ist, pünktlich zu sein. Für ein Vorstellungsgespräch bei einem Traumjob beispielsweise ist Pünktlichkeit unerlässlich, und wir würden eher einen größeren Zeitpuffer einplanen als für ein zwangloses Treffen mit Freunden.

Betrachten wir einen ähnlichen, jedoch systematischeren Ansatz, um aus verschiedenen Schätzwerten effektiv auszuwählen. Stellen Sie sich vor, Sie würden die Wahrscheinlichkeiten Ihrer täglichen Fahrtzeiten grafisch darstellen. Das Ergebnis ähnelte wahrscheinlich einer Glockenkurve, mit der durchschnittlichen Fahrtzeit im Zentrum. Diese Kurve, bekannt als Normalverteilung oder Gauss’sche Verteilung, benannt nach Carl Friedrich Gauss, einem bedeutenden deutschen Mathematiker des frühen 19. Jahrhunderts, bietet nützliche Einsichten für die Erstellung von Projektschätzungen. Eine charakteristische Eigenschaft der Normalverteilung ist, dass 50% der Werte unter und 50% über dem Mittelwert liegen. Das impliziert, dass der Durchschnittswert eine 50%ige Wahrscheinlichkeit bietet, dass die tatsächlichen Ergebnisse gleich oder besser als die Schätzung ausfallen.

An diesem Punkt ist es wichtig, innezuhalten. Wenn Sie einem Kunden Ihre Durchschnittsschätzung vorlegen, besteht eine ebenso hohe Wahrscheinlichkeit für Erfolg wie für Misserfolg. Es wäre riskant, die Erfolgsaussichten Ihrer Karriere auf eine 50-50-Chance zu setzen. Zwar bietet die Schätzung des schlechtesten Szenarios die höchste Erfolgschance, doch könnte diese so konservativ ausfallen, dass der Kunde das Projekt möglicherweise nicht weiterverfolgt.

Es ist bekannt, dass Kunden oft Angebote bevorzugen, die auf optimistischen Annahmen basieren. Es ist jedoch wichtig, dieser Versuchung zu widerstehen. Die Präsentation Ihrer optimistischsten Schätzung, beispielsweise einer Fertigstellung innerhalb von sechs Monaten, kann trügerisch sein. Kunden neigen dazu, sich auf die Zeitangabe zu konzentrieren und die zugrunde liegenden Annahmen zu überhören. Ein solches Vorgehen könnte das Projekt von vornherein zum Scheitern verurteilen, da es alle weniger optimistischen und realistischeren Schätzungen außer Acht lässt.

Sie fragen sich nun wahrscheinlich, welchen Wert Sie für Ihre Schätzung verwenden sollten. Die ideale Zahl befindet sich irgendwo zwischen dem Durchschnittswert und dem pessimistischsten Szenario. Wenn wir zur Glockenkurve zurückkehren, könnten wir den Wert wählen, der genau zwischen dem Mittelwert und dem schlimmsten Fall liegt. Anstatt in die komplexen mathematischen Details der sogenannten PERT-Analyse einzutauchen, gibt es eine einfache Methode, die eine hohe Wahrscheinlichkeit für eine treffende Schätzung bietet.

Diese Methode bietet eine hohe Erfolgswahrscheinlichkeit und der berechnete Wert ist einfach zu ermitteln. Zusätzlich besteht die Möglichkeit, den vorgeschlagenen Wert zu erhöhen, um das Risiko weiter zu minimieren. Diese Strategie ähnelt der Entscheidung, für ein wichtiges Vorstellungsgespräch früher loszufahren als üblich. Umgekehrt kann das Risiko in Situationen wie einer preisbasierten Ausschreibung gesteigert werden, indem man weniger Puffer einplant und einen Wert wählt, der näher am Durchschnitt liegt – und somit ein höheres Risiko in Kauf nimmt.

Der entscheidende Faktor ist die Auswahl einer Schätzung, die unter Berücksichtigung der spezifischen Bedingungen des Projekts eine angemessene Erfolgswahrscheinlichkeit bietet. Betrachten wir zur Veranschaulichung unser Fallbeispiel eines Online-Systems zur Überwachung von Transaktionen, das darauf abzielt, deren Transparenz zu erhöhen.

Beispiel.

Um eine erste Schätzung für das Online-Überwachungssystem zu erhalten, konsultieren wir verschiedene Anbieter von Überwachungssystemen und erfragen die geschätzte Dauer und die Kosten für die Anpassung und Implementierung ihrer Systeme. Jeder Anbieter bietet drei verschiedene Schätzungen an: eine für eine Standardimplementierung ohne spezifische Anpassungen, eine für eine Implementierung mit typischen Anpassungen und eine dritte für eine Implementierung mit umfangreichen Anpassungen.

Nachfolgende Tabelle stellt diese drei Schätzungen einander gegenüber.

	Kosten in €			Dauer in Monaten
Lieferan-ten	Ohne Anpassung	Typische Anpassung	Erweitert Anpassung	Ohne Anpassung	Typische Anpassung	Erweiterte Anpassung
Lieferant 1	800.000	900.000	1.100.000	8	10	12
Lieferant 2	600.000	750.000	1.000.000	8	11	13
Lieferant 3	500.000	650.000	900.000	7	11	15
Durchschnittswerte der Lieferanten 1 und 2		825.000	1.050.000		10,5	12,5
Schätzung auf halbem Weg zwischen den durchschnittlichen und schlechtesten Werten		937.500			11,5
Risikozuschlag von 15%		140.625			1,725
Schätzung inklusive 15% Risikozuschlag		1.078.125			13,225
Auf-/Abrundung der Schätzung inklusive Risikozuschlag		1.000.000			13
Risikozuschlag enthalten in der gerundeten Schätzung		62.500			1,5

Angenommen, Lieferant 3 kann viele der benötigten Funktionen weder in seinem Standardangebot bereitstellen noch gibt es eine realistische Möglichkeit, diese durch Anpassungen zu integrieren. Aus diesem Grund schließen wir, dass dieses System nicht den funktionalen Anforderungen entspricht. Deshalb entscheiden wir uns, Lieferant 3 nicht weiter zu berücksichtigen und stattdessen die fortgeschrittenen Systemangebote der Lieferanten 1 und 2 näher zu betrachten.

Lassen Sie uns nun detailliert betrachten, wie wir diese Entscheidung umsetzen:

• Beginnen wir mit der Berechnung des Durchschnitts für Zeit und Kosten einer typischen Anpassung bei beiden Lieferanten. Für eine typische Implementierung ergibt sich ein Durchschnitt von 10,5 Monaten Dauer und 825.000 Euro Kosten.
• Anschließend ermitteln wir den Durchschnitt für Dauer und Kosten einer erweiterten Anpassung, wiederum für beide Lieferanten. Die Ergebnisse zeigen eine durchschnittliche Dauer von 12,5 Monaten und durchschnittliche Kosten in Höhe von 1.050.000 Euro für eine erweiterte Anpassung.
• Nun berechnen wir einen Zwischenwert, der genau zwischen dem Durchschnitt der typischen und der erweiterten Anpassung liegt. Dies führt uns zu einer geschätzten Dauer von 11,5 Monaten und Kosten von 937.500 Euro.
• Abschließend berücksichtigen wir einen Risikozuschlag von 15%. Nach Anwendung des Zuschlags und Abrundung der Werte ergibt sich eine finale Schätzung von 13 Monaten Dauer und einem Budget von 1.000.000 Euro, was einem Risikopuffer von 1,5 Monaten und 62.500 Euro entspricht.

Ein letztes Wort über Schätztechniken bei agilen Teams.

Agile Teams nutzen zwar ähnliche Schätztechniken wie traditionelle Teams, benennen und strukturieren diese jedoch oft anders. Statt exakter Maße setzen sie auf relative Größenschätzungen, die an T-Shirt-Größen erinnern: von sehr klein bis sehr groß. Die kleinste Kategorie innerhalb dieser Klassifizierung erhält den Basiswert 1.

Nachdem der Basiswert festgelegt wurde, ordnen agile Teams die folgenden Anforderungskategorien gemäß der Fibonacci-Sequenz ein. Die nächstgrößere Kategorie erhält den Wert 2, gefolgt von 3, dann 5 und schließlich 8 für die größte vordefinierte Kategorie. Anforderungen, die über ‘XL’ hinausgehen, müssen in kleinere, handhabbare Teile untergliedert werden, um genaue Schätzungen zu ermöglichen. Diese Methode basiert auf der Annahme, dass es leichter ist, den Aufwand für kleinere Komponenten zu schätzen als für umfangreichere. Ein kleines Feature könnte beispielsweise innerhalb einer Woche entwickelt werden, während ein ‘XL’-Feature bis zu 8 Wochen in Anspruch nehmen könnte.

Unabhängig vom gewählten Projektmanagement-Ansatz erwarten Sponsoren oft eine Schätzung der Projektlaufzeit in konventionellen Kalenderzeiten und nicht in agilen Einheiten wie Story Points. Story Points sind eine agile Maßeinheit zur Abschätzung des Aufwands, der zur Implementierung eines Produkt-Backlog-Elements erforderlich ist. Sie bieten eine abstrakte Bewertung der Komplexität und des benötigten Aufwands für ein Feature oder eine Aufgabe, ohne sich auf spezifische Stunden oder Tage festzulegen.

Zusammenfassend ist es wichtig zu betonen, dass Schätzungen nicht von Anfang an perfekt sein müssen. Es ist durchaus üblich, mit einer groben Top-Down-Schätzung zu beginnen und diese im Laufe der Zeit zu verfeinern, sobald zusätzliche Informationen und Expertenmeinungen verfügbar sind. Eine angemessene Schätzung zu erstellen, ist von entscheidender Bedeutung, da unsere Schätzungen darüber entscheiden können, ob die Durchführung eines Projekts sinnvoll ist. Darüber hinaus bilden die erstellten Schätzungen den Grundstein für den Basisplan, der zur Messung des Projektfortschritts dient, indem die Zeit- und Kostenschätzungen in den Termin- bzw. Kostenbasisplan einfließen.

 

 

 

 

 

2.5.7 Entwicklung des Terminbasisplans hin zum Projektterminplan

Dieser Abschnitt beschreibt den Prozess der Entwicklung des Terminbasisplans in sechs Schritten.

Schritt 1: Definieren der Aktivitäten.

Die Erstellung eines Terminplans beginnt mit der Ausarbeitung des Projektstrukturplans, in dem das Team die zu erledigenden Arbeiten bis hin zu den Arbeitspaketen festlegt. Anschließend gilt es, jedes Arbeitspaket in die spezifischen Aktivitäten aufzuteilen, die zur Fertigstellung der darin enthaltenen Liefergegenstände notwendig sind.

Bei umfangreichen Projekten oder wenn der Projektmanager eine eher zusammengefasste Sichtweise bevorzugt, kann die Detaillierung der Arbeitspakete in einzelne Aktivitäten den jeweiligen Arbeitspaketleitern überlassen werden. In solchen Fällen beschränkt sich der Projektterminplan auf die Darstellung der Arbeitspakete, wobei jedes Paket einem zuständigen Leiter oder Verantwortlichen zugewiesen wird.

Für kleinere Projekte oder wenn der Projektmanager eine detailliertere Kontrolle über die Arbeiten bevorzugt, können die einzelnen Aktivitäten innerhalb der Arbeitspakete direkt im allgemeinen Projektterminplan dargestellt werden. Der Plan zur Steuerung des Terminplans, der später im Zusammenhang mit Hilfsplänen besprochen wird, legt das erforderliche Detaillierungsniveau für die Erstellung des Terminplans fest. In den nachfolgenden Ausführungen wird davon ausgegangen, dass der Projektterminplan die einzelnen Aktivitäten umfasst, die zu den Arbeitspaketen gehören. Diese Methodik lässt sich jedoch ebenso anwenden, wenn das Detailniveau auf Arbeitspaketebene beibehalten wird.

Bevor mit der zeitlichen Planung der Arbeiten begonnen wird, ist es essentiell, die zu erledigenden Arbeiten klar zu identifizieren. Dies geschieht üblicherweise anhand des Projektstrukturplans oder, bei Anwendung agiler Methoden, mithilfe eines Produkt-Backlogs. Unabhängig davon, ob ein prädiktiver oder ein agiler Ansatz verfolgt wird, besteht stets die Möglichkeit, dass im Verlauf des Projekts zusätzliche

Arbeiten notwendig werden. Um solche Eventualitäten abzudecken, ist es wichtig, einen angemessenen Risikozuschlag einzuplanen.

Die Bestimmung der für die Erstellung der in einem Arbeitspaket definierten Liefergegenstände erforderlichen Aktivitäten gelingt am effektivsten in Kooperation mit einem Team von Fachexperten. Brainstorming-Sitzungen sind hierbei ein bewährtes Mittel. Diese Experten verfügen über das notwendige Wissen, um festzulegen, welche Schritte in welcher Reihenfolge unternommen werden müssen, um jedes Lieferobjekt erfolgreich zu erstellen.

Für ein praktisches Beispiel der Unterteilung eines Arbeitspakets in Aktivitäten können Sie sich den Abschnitt zur Definition von Arbeitspaketen ansehen, der anhand eines Fallbeispiels einer Online-Lösung zur Überwachung des Status von Transaktionen illustriert wird.

Schritt 2: Sequenzieren der Aktivitäten.

Nachdem die erforderlichen Aktivitäten zur Erstellung der Liefergegenstände definiert wurden, ist der nächste Schritt, diese Aktivitäten in eine logische Reihenfolge zu bringen. Dies beinhaltet das Festlegen von Abhängigkeiten zwischen den Aktivitäten und die Dokumentation dieser Beziehungen im Projektterminplan.

Die am häufigsten vorkommende Beziehung ist die Ende-zu-Beginn-Verbindung. Diese besagt, dass eine Aktivität nicht starten kann, bevor die vorherige abgeschlossen ist. Ein praktisches Beispiel hierfür ist, dass eine Wand fertig gebaut sein muss, bevor mit dem Streichen begonnen werden kann.

Neben der Ende-zu-Beginn-Verbindung gibt es auch andere Beziehungstypen, wie die Beginn-zu-Beginn-Verbindung. Diese legt fest, dass der Beginn einer Aktivität mit dem Start einer anderen verknüpft ist. Eine weitere Beziehungsart ist die Ende-zu-Ende-Verbindung, bei der der Abschluss zweier Aktivitäten miteinander verbunden ist. Sie müssen nicht gleichzeitig enden, aber ihr Abschluss ist voneinander abhängig. Zum Beispiel könnte es erforderlich sein, dass Aktivität A zwei Wochen vor Aktivität B abgeschlossen wird.

Schritt 3: Abschätzen der für die Aktivitäten benötigten Ressourcen.

Der dritte Schritt im Prozess ist die Bestimmung der benötigten Ressourcenarten und -mengen für die im Terminplan aufgeführten Aktivitäten. Diese Ressourcen umfassen sowohl menschliche als auch materielle Ressourcen wie Ausrüstung und Materialien, die für die Durchführung jeder Aktivität oder jedes Arbeitspakets erforderlich sind.

Nach der anfänglichen Zuweisung dieser Ressourcen und der darauffolgenden Schätzung der Aktivitätsdauern kann es notwendig werden, zu diesem Schritt zurückzukehren und die Ressourcenzuweisungen anzupassen, falls die ursprünglich geschätzten Zeiträume nicht realistisch sind. Es ist wichtig zu beachten, dass nicht alle Arbeitsarten durch zusätzliche Ressourcen beschleunigt werden können.

Die Ressourcenschätzung ist eng mit der Kostenschätzung verbunden. Beispielsweise muss ein Bauprojektteam die lokalen Bauvorschriften kennen. Fehlt dem Team die Erfahrung mit speziellen Bautechniken, könnte es erforderlich sein, zusätzliche Kosten für spezialisierte Berater einzuplanen. Ähnlich könnte ein Automobildesign-Team, das sich mit modernen Montagetechniken auseinandersetzen muss, einen externen Experten hinzuziehen oder Teammitglieder zu spezifischen Schulungen entsenden.

Schritt 4: Schätzen der Dauer der Aktivitäten.

Nach der Zuweisung der Ressourcen besteht der nächste Schritt darin, für jedes Element im Terminplan die Dauer zu schätzen, die mit den zugewiesenen Ressourcen benötigt wird. Die Dauer bezieht sich auf die Anzahl der Arbeitsperioden, die nötig sind, um eine Aufgabe abzuschließen. Je nach Projektumfang kann die Dauer in Tagen, Wochen oder Monaten angegeben werden.

Bei aufwandsabhängigen Tätigkeiten lässt sich die Dauer durch die Zuweisung zusätzlicher Ressourcen potenziell verkürzen. Ein Beispiel hierfür wäre, dass das Interviewen von 100 Personen weniger Zeit beansprucht, wenn 5 Interviewer parallel eingesetzt werden, im Vergleich zu nur einem Interviewer.

Jedoch gibt es auch Tätigkeiten, deren Dauer nicht direkt vom Aufwand abhängt. In solchen Fällen führt die Zuweisung weiterer Ressourcen nicht zu einer Verkürzung der Dauer. Ein Beispiel hierfür wäre der Transport eines Gegenstands per Schiff, der unabhängig von der Anzahl der beauftragten Spediteure 20 Tage dauert.

Es ist wichtig zu berücksichtigen, dass Teammitglieder möglicherweise nicht zu 100% für das Projekt verfügbar sind und selbst bei Vollzeitarbeit niemand durchgehend zu 100% produktiv ist. Erfahrene Projektmanager kalkulieren daher mit einer durchschnittlichen Produktivität von etwa 70% in effizienten Arbeitsumgebungen. Das bedeutet, dass eine Tätigkeit, die auf 40 Stunden geschätzt wird, tatsächlich eine Dauer von 57 Stunden benötigt. Diese Zahl ergibt sich, wenn man die geschätzten 40 Stunden durch den Produktivitätsfaktor 0,7 teilt. Umgerechnet auf eine 8-Stunden-Arbeitstag entspricht dies etwa 7 Arbeitstagen – im Gegensatz zu den 5 Tagen, die man bei einer 40-Stunden-Woche erwarten könnte.

Zudem können externe Faktoren wie Feiertage, Urlaube oder Krankheitstage sowie das Auftreten anderer prioritärer Aufgaben die tatsächliche Dauer weiter verlängern. In einigen Fällen kann eine Aufgabe, die ursprünglich auf 7 Arbeitstage geschätzt wurde, tatsächlich bis zu drei Wochen in Anspruch nehmen. Diese realistische Betrachtung der Produktivität, die in manchen Umgebungen sogar unter 50% liegen kann, ist weitaus praktikabler als die unrealistische Annahme einer 100% Produktivität. Wenn frühere Projekte regelmäßig deutlich länger dauerten als ursprünglich geplant, könnte dies ein Hinweis darauf sein, dass die tatsächliche Produktivitätsrate geringer ist als angenommen, was eine Anpassung der Planung an die realen Gegebenheiten erfordert.

Schritt 5: Modellierung eines Terminplans.

Nachdem alle Arbeitspakete verknüpft, die notwendigen Ressourcen zugewiesen und die Dauern der einzelnen Aktivitäten geschätzt wurden, ist es möglich, eine erste Version des Terminplans zu erstellen. Der folgende Schritt beinhaltet die Analyse und Modellierung dieses Terminplans. Dabei kann es vorkommen, dass bestimmten Ressourcen in manchen Wochen zu viele und in anderen zu wenige Stunden zugewiesen sind.

Um solche Fälle von Über- oder Unterlastung zu lösen, kommt der “Ressourcenausgleich” zum Einsatz. Dieser ist erforderlich, wenn dieselben Ressourcen gleichzeitig für zwei Aktivitäten eingeplant sind, was zu einer Überbeanspruchung führen kann. Ein Beispiel hierfür wäre, wenn eine Person in einer Woche gleichzeitig in Vollzeit an zwei verschiedenen Aktivitäten arbeiten soll, was praktisch nicht umsetzbar ist.

Um dieses Problem zu beheben, könnte entweder die Dauer einer der Aktivitäten verlängert oder die überlastete Ressource durch eine verfügbare ersetzt werden. Als Ressource kann hierbei sowohl Personal, Ausrüstung als auch ein Raum in Betracht gezogen werden.

Nachdem die Ressourcen ausgeglichen wurden, liegt ein erster Entwurf des Terminplans vor. Dieser Entwurf muss nun daraufhin überprüft werden, ob er mit den zu Projektbeginn festgelegten zeitlichen Einschränkungen übereinstimmt. Bei Vorliegen fester Fristen, wie beispielsweise einer internationalen Messe im September, und sollte der Terminplan einen Projektabschluss im November vorsehen, ist eine Überarbeitung des Terminplans unausweichlich.

Um den Terminplan anzupassen, stehen verschiedene Optionen zur Verfügung, darunter die Zuweisung zusätzlicher Ressourcen, die Anordnung von Überstunden oder eine erneute Überprüfung der Abhängigkeiten zwischen den Aktivitäten. Es ist möglich, dass einige Aktivitäten, die zunächst als sequenziell geplant waren, parallel durchgeführt werden können, was eine erhebliche Verkürzung der Projektlaufzeit ermöglichen würde, ohne Überstunden in Anspruch zu nehmen.

Sollten diese Maßnahmen nicht ausreichen, bleibt als letzte, wenn auch suboptimale Lösung, Teile der im Projektstrukturplan definierten Arbeiten zu streichen, insbesondere wenn die zeitlichen Einschränkungen den Projektumfang überwiegen und sich das Problem der Projektdauer nicht anders lösen lässt.

Es ist wichtig, am Ende eine solide Projektdauerschätzung vorliegen zu haben, idealerweise mit einer Zuversicht von 85%, was einen Puffer für Unvorhergesehenes von 15% einschließt. Bedenken Sie, dass Stakeholder, insbesondere einflussreiche, Ihre Schätzungen hinterfragen könnten. Sollten Sie Ihre Schätzungen nicht überzeugend verteidigen können, ist es ratsam, zusätzliche Zeit in die Verbesserung der Schätzungen zu investieren, um eine sichere Grundlage zu schaffen.

Schritt 6: Meilensteine und Phasen festlegen.

Nun überprüfen wir den Entwurf des Terminplans, um festzustellen, bis wann die wesentlichen Liefergegenstände fertiggestellt sein sollten. Wir kennzeichnen diese Schlüsselmomente als Meilensteine. Meilensteine sind markante Punkte ohne eigene Dauer, die den Abschluss wichtiger Liefergegenstände symbolisieren und insbesondere für das Management von Bedeutung sind. In einem Zusammenfassungsbericht, der üblicherweise für Lenkungsausschüsse vorgesehen ist und lediglich die Meilensteine auflistet, lässt sich auf einen Blick erkennen, ob das Projekt im Terminplan liegt, Verzögerungen aufweist oder sogar vor dem Terminplan ist, ohne dass die Details jedes Arbeitspakets betrachtet werden müssen.

Außerdem planen wir Projektreviews zu den Zeitpunkten, an denen wesentliche Meilensteine erreicht werden, etwa am Ende von Projektphasen. Diese Überprüfungen werden als Revisionen an Phasenübergängen bezeichnet; ihre genauere Betrachtung erfolgt im Abschnitt über Controlling der Phasenübergänge als Teil der Unit über Projektcontrolling.

Der aktuelle Terminplanentwurf dient als vorläufige Version. Es ist zu beachten, dass dieser Entwurf noch nicht die endgültige Fassung darstellt.

Weitere Elemente wie Risikomanagementstrategien, Kommunikationspläne, Qualitätsmanagementmaßnahmen und Teambuildingaktivitäten müssen noch integriert werden. Der Projektablaufplan wird also schrittweise erweitert, indem Managementaktivitäten den Produktentwicklungsaktivitäten hinzugefügt werden. Erst nach der Genehmigung der vollständig integrierten Version des Terminplans erhalten wir den endgültigen Terminbasisplan.

Agile Überlegungen zur Erstellung des Terminplans.

In agilen Projekten kommen andere Begriffe und Methoden zum Einsatz. Statt eines Projektstrukturplans spricht man von einem Produktbacklog; Iterationen oder Sprints ersetzen die klassischen Meilensteine und Phasen. Die Schätzung basiert manchmal auf Story Points und man verwendet häufig relative Größen für die Aufwandsschätzungen. Zudem liegt der Fokus auf der Priorisierung von Backlogelementen, anstatt auf einer fortschreitenden detaillierten Aufschlüsselung des Projektstrukturplans wie in der traditionellen Wellenplanung.

Agile Teams verzichten in der Regel darauf, eine Gesamtdauer des Projekts zu schätzen, da sie einen flexiblen Ansatz verfolgen. Dennoch kann es vorkommen, dass der Produktverantwortlicher oder andere Schlüsselstakeholder einen konkreten Fertigstellungstermin erwarten, zumindest für die initial definierten Anforderungen. Um solchen Anforderungen gerecht zu werden, könnten agile Teams folgenden Prozess anwenden:

1. Liste der Anforderungen und Funktionen erstellen: Das Projektteam und der Produktverantwortlicher arbeiten zusammen, um die Produktanforderungen und -funktionen zu definieren. Diese werden in einem Backlog erfasst, das alle ausstehenden Arbeiten umfasst.
2. Priorisierung der Backlogelemente: Der Produktverantwortlicher ordnet die Elemente im Backlog nach ihrer Wichtigkeit und Dringlichkeit.
3. Aufwandsschätzung: Das Team bewertet den erforderlichen Aufwand für jedes Backlogelement, wobei die Maßeinheit verwendet wird, die vom Team bevorzugt und vom Produktverantwortlichen akzeptiert ist, wie z.B. Story Points, relative Größen oder Arbeitsstunden.
4. Anzahl der Iterationen festlegen: Basierend auf einer groben Schätzung der Arbeitsmenge, die in einer Iteration abgeschlossen werden kann (bekannt als “Teamgeschwindigkeit”), bestimmt das Team die benötigte Anzahl von Iterationen, um den initialen Satz von Anforderungen oder Funktionen zu erfüllen. Eine Iteration ist ein definierter Zeitrahmen (üblicherweise zwischen einer und vier Wochen), in dem ein Set von priorisierten Funktionen entwickelt und ausgeliefert wird. Während der Planung einer Iteration nimmt das Team die obersten priorisierten Backlogelemente, die vom Produktverantwortlichen festgelegt wurden, in Angriff.
5. Überwachung und Anpassung: Das Team überwacht den Fortschritt jeder Iteration und passt die verbleibende Arbeit entsprechend an, basierend auf neuen Anforderungen und den Erfahrungen mit der tatsächlichen Teamgeschwindigkeit. In den Backlog-Verfeinerungsbesprechungen werden die verbleibenden Backlogelemente überprüft, detaillierter aufgeschlüsselt, neu geschätzt und aktualisiert, um die Planung für die nächste Iteration zu verfeinern. Änderungen in Anforderungen und Prioritäten führen zu einer fortlaufenden Anpassung des Terminplans.

Abschließende Bemerkungen zu Planungswerkzeugen.

Für die effektive Erstellung und Steuerung Ihres Projektterminplans ist der Einsatz einer Projektmanagementsoftware oft unerlässlich. Der Markt bietet eine Vielzahl an Tools, darunter bekannte Lösungen wie Microsoft Project, Oracle Primavera, Liquid Planner und Smartsheet. Einige Projektteams setzen auch auf angepasste Excel-Tabellen mit Makros, um ihren Bedürfnissen gerecht zu werden. Es empfiehlt sich, eine gründliche Recherche durchzuführen, um eine passende Software zur Steuerung der Termine zu finden, die sowohl zu Ihren spezifischen Anforderungen als auch zu Ihrem Budget passt.

Zusammenfassung der Schritte zur Erstellung eines Projektterminplans:

1. Aktivitäten definieren: Ermitteln Sie die spezifischen Aufgaben, die für das Projekt erforderlich sind.
2. Aktivitäten sequenzieren: Ordnen Sie die Aktivitäten in logischer Reihenfolge an und definieren Sie ihre Abhängigkeiten.
3. Ressourcen schätzen: Bestimmen Sie die notwendigen Ressourcen für jede Aktivität.
4. Dauer schätzen: Schätzen Sie, wie lange jede Aktivität dauern wird.
5. Terminplan modellieren: Erstellen Sie auf Basis der vorherigen Schritte einen ersten Entwurf des Terminplans.
6. Meilensteine und Phasen festlegen: Bestimmen Sie wichtige Meilensteine und unterteilen Sie das Projekt in Phasen.

Für agile Projekte mit festem Enddatum könnte der Prozess folgendermaßen aussehen:

• Anforderungen und Funktionen auflisten: Erfassung aller Produktanforderungen und der gewünschten Funktionen, die dann im Produktbacklog registriert werden.
• Backlog-Elemente priorisieren: Ordnen Sie die Projektanforderungen nach ihrer Bedeutung.
• Aufwand schätzen: Bewerten Sie den erforderlichen Aufwand für jedes Backlog-Element, typischerweise in Story Points oder relativen Größen.
• Anzahl der Iterationen festlegen: Schätzen Sie, wie viele Sprints oder Iterationen benötigt werden, um die Anforderungen zu erfüllen.
• Kontinuierliche Überwachung und Anpassung: Passen Sie den Plan regelmäßig an, basierend auf dem Projektfortschritt und eventuellen Änderungen.

 

 

 

 

2.5.8 Entwicklung des Kostenbasisplans hin zum Projektbudget

In diesem Abschnitt erfahren Sie, wie Sie auf Basis von Kostenschätzungen ein Projektbudget erstellen. Neben Zeit und Umfang gehört das Budget zu den drei Kerneinschränkungen eines Projekts, wobei die Kostenprognose den Ausgangspunkt bildet.

Ein realistisch kalkuliertes Projektbudget setzt eine sorgfältige Bewertung aller erforderlichen Ausgaben voraus. Übersteigt die Kostenschätzung den Betrag, der angemessen wäre, könnte das die Genehmigung des Projekts gefährden. Ist die Schätzung jedoch zu niedrig, riskiert man, dass die tatsächlichen Kosten das Budget sprengen, was die Durchführungsentscheidung im Nachhinein als unklug erscheinen lassen könnte.

Die Erstellung des Projektbudgets beginnt mit groben Schätzungen für die obersten Ebenen des Projektstrukturplans. Mit zunehmendem Projektverständnis können diese Schätzungen präzisiert werden. Ähnlich wie beim Terminplan basiert auch das Budget auf dem Projektstrukturplan, der die Arbeitspakete definiert. Der Detaillierungsgrad des Budgets orientiert sich dabei an der Granularität, die der Projektmanager für die Überwachung und Steuerung des Projekts benötigt.

Während manche Arbeitspakete detailliert in die einzelnen zugrundeliegenden Aktivitäten aufgegliedert werden, können andere in aggregierter Form belassen werden. Die weiteren Ausführungen gehen davon aus, dass die Kosten bis auf die Ebene der Einzelaktivitäten heruntergebrochen werden. Diese Methodik lässt sich jedoch gleichermaßen anwenden, wenn die Kostenschätzungen auf der Ebene der Arbeitspakete verbleiben.

Bei der Bestimmung des Projektbudgets geht es darum, einzelne Kostenschätzungen zu einem kohärenten Gesamtbudget zusammenzuführen. Ein zentraler Aspekt dieses Prozesses ist die Festlegung von Risikozuschlägen für bekannte Risiken, um auf identifizierte Unsicherheiten reagieren zu können. Darüber hinaus ist es empfehlenswert, dass der Projektsponsor zusätzlich einen Risikozuschlag für unvorhergesehene Risiken einkalkuliert, um auf Herausforderungen vorbereitet zu sein, die im Vorfeld nicht erkannt wurden.

Dieses Vorgehen ähnelt der Methode zur Schätzung der Projektdauer. Weiterhin ist es entscheidend zu planen, wann im Projektverlauf welche Finanzmittel benötigt werden. Ein Gesamtbudget von beispielsweise 1.000.000 Euro wird nicht vollständig zu Projektbeginn benötigt, sondern verteilt sich auf die gesamte Projektdauer. Daher ist es wichtig, die Frage zu klären: Zu welchen Zeitpunkten werden welche Geldmittel benötigt? Dies ist einer der Gründe, weshalb der Projektterminplan vor der endgültigen Budgetierung erstellt wird, um eine präzise Finanzplanung zu ermöglichen.

Die Komponenten des Projektbudgets.

Das anschließende Diagramm veranschaulicht die Kostenschätzungen für verschiedene Projektaktivitäten, inklusive der Risikozuschläge für unvorhergesehene Ereignisse. Die Kostenschätzungen für einzelne Aktivitäten werden aggregiert, um die Gesamtkosten der Arbeitspakete zu berechnen, zu denen sie gehören. Hierbei werden auch Risikozuschläge auf der Ebene der Arbeitspakete berücksichtigt.

Zur Vereinfachung der Leistungsbewertung können die Kostenschätzungen der Arbeitspakete in Kostenstellen gruppiert werden.

Die Genehmigung des Kostenbasisplans steht allerdings noch aus, da zusätzliche Kosten für Aktivitäten ermittelt werden müssen, die aus den Hilfsplänen und den Risikobewältigungsmaßnahmen resultieren. Nachdem diese Ergänzungen vorgenommen wurden, entsteht ein finaler Entwurf des Kostenbasisplans. Die Genehmigung dieses finalen Entwurfs, der sowohl die Kostenschätzungen für die Produktentwicklung als auch für das Projektmanagement inklusive Risikozuschläge umfasst, bildet den verbindlichen Kostenbasisplan.

Das Projektbudget setzt sich aus dem Kostenbasisplan und einer Managementreserve für unvorhergesehene Ereignisse zusammen, die außerhalb der Einflusssphäre des Projektmanagers liegt. Idealerweise definiert die Unternehmensleitung diese Managementreserve proaktiv als Vorsorge für zukünftige, zu Projektbeginn unbekannte Herausforderungen und Veränderungen, um so unbekannte Risiken zu adressieren.

Während der Projektmanager für die Führung des Projekts anhand des Kostenbasisplans zuständig ist, der die Risikozuschläge für bekannte Risiken einschließt, ist er nicht direkt für die Managementreserve verantwortlich. Diese liegt in der Verantwortung des Projektsponsors, was eine klare Trennung der Zuständigkeiten im Umgang mit bekannten und unbekannten Risiken gewährleistet.

Das Gesamtbudget eines Projekts setzt sich aus mehreren Schlüsselkomponenten zusammen:

Managementreserve: Dieser Betrag ist für unvorhersehbare Ereignisse vorgesehen, die außerhalb des Einflussbereichs des Projektmanagements liegen.

Kostenbasisplan (Cost Baseline): Dieses genehmigte Budget basiert auf den detaillierten Kostenschätzungen der Projekttätigkeiten. Es beinhaltet Risikozuschläge für bekannte Risiken, jedoch ohne die Managementreserve.

Innerhalb des Kostenbasisplans wird weiter differenziert:

• Geschätzte Kosten der Arbeitspakete: Dies sind die prognostizierten Kosten für jedes einzelne Arbeitspaket, welche die Basis für den Kostenbasisplan bilden.
• Risikozuschläge für Arbeitspakete: Dies sind Mittel, die zusätzlich für die Absicherung gegen bekannte Risiken in den Arbeitspaketen reserviert sind.
• Kostenstellen: Sie stellen Gruppierungen von Arbeitspaketen oder Aktivitäten dar und dienen der erleichterten Überwachung und Kontrolle der Kosten.
• Kostenschätzungen der Aktivitäten: Dies sind die geschätzten Kosten für jede einzelne Aktivität, die zur Fertigstellung der Arbeitspakete benötigt werden.
• Risikozuschläge für Aktivitäten: Diese Zuschläge beziehen sich auf die Ebene der individuellen Aktivitäten und dienen ebenfalls zur Absicherung gegen bekannte Risiken.

Zusammenfassend ist das Gesamtbudget die Summe aus dem Kostenbasisplan, einschließlich aller Risikozuschläge, und der Managementreserve.

Die Finanzierungsanforderungen.

Die anschließende Graphik veranschaulicht den Kostenbasisplan in einer zeitlichen Perspektive. Die Kostenschätzungen, die den Kostenbasisplan bilden, sind direkt mit den Aktivitäten des Terminplans verknüpft und ermöglichen dadurch eine chronologisch abgestufte Darstellung der Kostenplanung. Der Begriff ‘Budget at Completion’ (BAC) bezeichnet die ursprünglich geplanten Gesamtkosten des Projekts und repräsentiert den Teil des Gesamtbudgets, der ohne Managementreserve für die Bewertung der Leistung des Projektmanagers herangezogen wird. Die klare Abgrenzung zwischen dem Kostenbasisplan, einschließlich Risikozuschlägen, und dem Gesamtbudget, das auch die Managementreserve umfasst, ist entscheidend.

Die Graphik zeigt die kumulativen Projektkosten über den Zeitverlauf und stellt die Finanzierungsanforderungen dar. Diese verdeutlichen, wie viel Finanzmittel zu bestimmten Zeitpunkten benötigt werden, um sowohl den geplanten Projektfortschritt als auch die korrespondierenden Kosten abzudecken. Die Finanzierungsanforderungen sind üblicherweise gestaffelt, was bedeutet, dass sie in festgelegten Intervallen festgelegt werden, um eine fließende Finanzierung im Einklang mit dem Fortschrittsrhythmus des Projekts zu gewährleisten. Übermäßige Finanzierungsanforderungen könnten unnötig Kapital binden, das andernorts in der Organisation genutzt werden könnte, während zu niedrigen Anforderungen das Risiko bergen, dass das Projekt aufgrund von Finanzierungslücken ins Stocken gerät. Es ist daher entscheidend, die Finanzierungsanforderungen sorgfältig zu planen, um sicherzustellen, dass sie realistisch über der Kostenbasis angesiedelt sind und den Projektfortschritt unterstützen, ohne Ressourcen zu verschwenden.

Die gestaffelte Budgetierung ist essenziell, um Cashflow-Probleme während des Projektverlaufs zu vermeiden. Wenn im Abschnitt über Annahmen festgehalten wird, dass die Finanzmittel entsprechend den Finanzierungsanforderungen bereitstehen werden, bedeutet dies, dass die sponsernde Organisation – vertreten durch den Projektsponsor – die nötigen Mittel gemäß der geplanten Finanzierungsanforderungen sowohl in der Höhe als auch zum richtigen Zeitpunkt bereitstellt.

Sollte es nicht möglich sein, die erforderlichen Mittel rechtzeitig und in voller Höhe zur Verfügung zu stellen, stehen wir vor einer kritischen Einschränkung. Falls Zweifel bestehen, ob diese Annahme von der sponsernden Organisation eingehalten wird, handelt es sich dabei nicht um eine Annahme, sondern um ein Risiko. In einem solchen Fall ist eine Überprüfung und eventuell eine Anpassung der Terminplanung erforderlich, um die finanziellen Rahmenbedingungen zu berücksichtigen. Diese Verbindung zu den im Projektmanagementplan definierten “Annahmen und Einschränkungen” stellt sicher, dass alle Aspekte der Projektfinanzierung im Einklang mit den verfügbaren Ressourcen und den Projektzielen stehen.

Für detailliertere Informationen zu den verschiedenen Techniken der Kostenschätzung empfehlen wir, den Abschnitt über Dauer- und Kostenschätzungen zu konsultieren. Im Folgenden diskutieren wir die verschiedenen Arten von Projektkosten und ihre Gruppierung. Es gilt, alle Kosten, die mit dem Projekt in Verbindung stehen – darunter fallen Arbeitskräfte, Materialien und weitere Ausgaben wie Reisekosten – genau zu schätzen.

• Arbeitskosten stellen häufig einen signifikanten Anteil der Gesamtprojektkosten dar. Diese umfassen nicht nur die Kosten für externe Lieferanten und Auftragnehmer, sondern auch die Gehälter und Sozialleistungen der internen Mitarbeiter. Ein Gehalt von 1.000 könnte auf 1.400 inklusive Sozialleistungen ansteigen und sogar 2.000 oder mehr erreichen, wenn man die indirekten Kosten wie Gebäude- und Ausrüstungsnutzung hinzurechnet. Es ist ratsam, sich bei der Buchhaltungs- oder Personalabteilung zu informieren, welche Kostensätze für Mitarbeiter angewandt werden sollen, die am Projekt beteiligt sind. Dies ist besonders relevant, wenn interne, nicht monetäre Kosten einbezogen werden müssen, die zwar keine unmittelbaren Ausgaben verursachen, da sie bereits über die Gehälter abgedeckt sind, aber dennoch einen Wert darstellen. Manche Projekte fokussieren ausschließlich auf externe, monetäre Kosten, die zu tatsächlichen Ausgaben führen. Dies vereinfacht das Management, birgt jedoch das Risiko, dass die tatsächlichen Gesamtkosten des Projekts, einschließlich der Zeit des internen Personals und der Nutzung von Unternehmensressourcen, nicht vollständig erfasst werden.
• Materialkosten umfassen Ausgaben für notwendige Rohstoffe oder für die Anschaffung bzw. Anmietung von Ausrüstung wie Computern. Der Umgang mit diesen Kosten sollte im Kostenmanagementplan festgelegt werden. Während manche Projekte den vollen Kaufpreis als Projektkosten verbuchen, wählen andere die Abschreibung als Berechnungsgrundlage, was die Kostenberechnung komplexer gestaltet.
• Zusätzlich können Kosten für temporäre Ressourcen anfallen, die nicht zu den Arbeitskosten zählen. Dazu gehören beispielsweise Mieten für genutzte Räumlichkeiten.
• Unter der Kategorie “Sonstige Kosten” werden alle Ausgaben erfasst, die sich nicht eindeutig den Arbeits- oder Materialkosten zuordnen lassen. Hierunter fallen zum Beispiel Reisekosten, Schulungsgebühren und andere diverse Ausgaben.

Agile Überlegungen zur Erstellung des Projektbudgets.

In agilen Projekten gibt es ebenfalls spezifische Überlegungen bei der Budgeterstellung. Obwohl agile Methoden Flexibilität und Anpassungsfähigkeit gegenüber präzisen Kostenvoranschlägen bevorzugen, ist es nachvollziehbar, dass Produktverantwortliche eine Einschätzung der Projektkosten wünschen. Nachfolgend wird ein Ansatz dargestellt, der dabei helfen kann, dieses Bedürfnis zu erfüllen:

1. Anforderungen und Funktionen auflisten: In Analogie zum Prozess der Erstellung eines agilen Terminplans arbeitet das Projektteam mit dem Produktverantwortlichen zusammen, um die Anforderungen und Funktionen des Produkts zu definieren und in einem Produkt-Backlog festzuhalten.
2. Priorisierung des Backlogs: Der Produktverantwortlicher ordnet die Elemente des Backlogs nach ihrer Wichtigkeit und Relevanz, unter Berücksichtigung der Projektziele und Kundenbedürfnisse.
3. Aufwand und Kosten schätzen: Das Projektteam nutzt agile Schätzmethoden, wie Story Points oder relative Größen, um den notwendigen Aufwand für jedes Element des Backlogs zu bestimmen. Diese Aufwandsschätzungen werden dann mit den entsprechenden Kosten verknüpft, indem die benötigten Ressourcen wie Teamzeit, Infrastrukturkosten und andere operative Kosten berücksichtigt werden.
4. Anzahl der Iterationen festlegen: Ähnlich dem Vorgehen bei der Erstellung des agilen Terminplans schätzt das Projektteam die Teamgeschwindigkeit, also die Menge an Arbeit, die in einer Iteration abgeschlossen werden kann. Basierend darauf wird die ungefähre Anzahl an Iterationen ermittelt, die benötigt werden, um den initialen Satz an Anforderungen oder Funktionen zu realisieren, was wiederum eine Kostenschätzung bis zum Projektabschluss ermöglicht. Die Bereitstellung der finanziellen Mittel wird dabei an den Rhythmus der Iterationen angepasst, die in einem agilen Projekt üblicherweise kurz und von konstanter Dauer sind. In einigen agilen Projekten wird alternativ eine feste Anzahl an Iterationen im Voraus festgelegt, ähnlich dem Konzept, ein Taxi zu nehmen und dem Fahrer zu sagen: “Fahren Sie mich so weit, wie diese 100 Euro reichen.”
5. Anpassungen und Verfeinerungen: Im Verlauf des Projekts überwacht das Team regelmäßig den Fortschritt und die tatsächlichen Kosten. In sogenannten Backlog-Verfeinerungstreffen werden der Backlog analysiert, aufgegliedert, neu geschätzt und aktualisiert. Veränderungen in den Anforderungen und Prioritäten können kontinuierliche Anpassungen des Budgets erforderlich machen.

Es ist wesentlich zu erkennen, dass das Budget in einem agilen Projekt – ähnlich dem agilen Terminplan – dynamisch ist und sich mit zunehmendem Projektverständnis und -fortschritt anpasst. Eine fortlaufende, offene Kommunikation mit dem Produktverantwortlichen und weiteren Stakeholdern ist essenziell, um sie kontinuierlich über Budgetentwicklungen und kostenbezogene Entscheidungen auf dem Laufenden zu halten. Diese Notwendigkeit der Informationsweitergabe und Transparenz ist nicht ausschließlich auf agile Projekte beschränkt, sondern gilt ebenso für hybride und traditionelle Projekte.

Zusammenfassend ist es von wesentlicher Bedeutung, alle Kosten, die mit der Durchführung und dem Management des Projekts einhergehen – einschließlich der Kosten für Personal, Materialien und sonstige Ausgaben – zu identifizieren und anhand der erläuterten Schätztechniken zu kalkulieren.

Die Kostenschätzungen für individuelle Aktivitäten werden zunächst zu den Gesamtkosten der jeweiligen Arbeitspakete zusammengefasst. Dabei ist es essenziell, Risikozuschläge sowohl auf Aktivitäten- als auch auf Arbeitspaketebene einzubeziehen, um auf identifizierte Risiken adäquat reagieren zu können. Diese Arbeitspaketkosten werden nachfolgend in Kostenstellen gruppiert, wenn es angebracht ist, die Leistung auf einer zusammengefassteren Ebene als der der Arbeitspakete zu messen.

Die konsolidierten Kosten dieser Kostenstellen bilden den Kostenbasisplan, der die Genehmigung des Projektgovernancegremiums benötigt. Der Kostenbasisplan legt das Verantwortlichkeitsniveau des Projektmanagers fest. Abschließend sollte die sponsernde Organisation eine Managementreserve für unvorhersehbare Ereignisse einkalkulieren, um auf potentielle, zum Zeitpunkt der Planung unbekannte Risiken vorbereitet zu sein. Diese Managementreserve liegt außerhalb der Verantwortung des Projektmanagers und wird vom Projektsponsor verwaltet.

In agilen Projekten wird der Aufwand für die anfangs definierten Funktionen mithilfe agiler Schätzmethoden ermittelt, um die Arbeitskosten zu kalkulieren. Die Teamgeschwindigkeit, also die Menge an Arbeit, die in einer typischen Iteration abgeschlossen werden kann, gibt Aufschluss über den erforderlichen Arbeitsaufwand und die Anzahl der Iterationen, die nötig sind, um die initialen Funktionalitäten umzusetzen. Die Schätzung von Materialkosten und anderen Ausgaben unterscheidet sich nicht grundsätzlich zwischen agilen, hybriden oder prädiktiven Projekten. Allerdings ist in agilen Projekten aufgrund möglicher Änderungen bei Anforderungen und Prioritäten mit dem Bedarf nach kontinuierlichen Budgetanpassungen zu rechnen.

 

 

2.6 Entwicklung von Hilfsmanagementplänen

In diesem Abschnitt werden Managementhilfspläne erläutert, der integrale Bestandteil des Projektmanagementplans sind. Sie umfassen Pläne für das Management von Kommunikation, Risiken, Qualität, Ressourcen, Inhalt und Umfang, Terminen, Kosten, Problemen und Änderungen.

Zu diesem Zeitpunkt bei der Erstellung eines integrierten Projektmanagementplans haben wir bereits zahlreiche wichtige Fragen geklärt: das Problem oder den spezifischen Problemteil, den wir adressieren möchten, und was das Projekt erreichen soll. Eine Strategie zur Zielerreichung wurde nach der Analyse verschiedener Optionen gewählt und zeigt auf, wie wir das Ziel erreichen wollen. Basierend auf der gewählten Strategie sowie auf eruierten Anforderungen wurde die Gesamtlösung definiert und ihre Komponenten als Liefergegenstände identifiziert. Schließlich haben wir darauf basierend die zu erledigende Arbeit bestimmt und darauf aufbauend sowohl einen ersten Entwurf des Terminplans als auch des Budgets erstellt. Der Leistungsmessungsbasisplan ist noch nicht fertig, da noch Aktivitäten, Aufwand und Kosten aus den Hilfsmanagementplänen hinzukommen, die wir jetzt identifizieren müssen. Darum geht es in den nächsten Absätzen.

Jetzt wollen wir festlegen, wie verschiedene Managementaspekte unseres Projekts funktionieren sollen. Fragen wie: “Wie werden wir kommunizieren?”, “Wie gehen wir mit Problemen und Änderungen um?”, “Wie detailliert muss unser Projektstrukturplan sein?”, “Was wird als hohe Risikowahrscheinlichkeit angesehen?” und “Wie bestimmen wir, wann Risiken ernst genug sind, um die Entwicklung aktiver Risikobewältigungsstrategien darauf zu rechtfertigen?”, müssen beantwortet werden. Es besteht Konsens darüber, dass die Lösung ein akzeptables Qualitätsniveau erreichen muss, doch wie wird dieses Qualitätsniveau bestimmt? Nach welchen Standards? Wie werden die Stakeholder eingebunden und wie gestaltet sich die Zusammenarbeit mit der Beschaffungsabteilung?

Die Managementhilfspläne sollen Antworten auf all diese Fragen liefern. Sie werden als “Hilfspläne” bezeichnet, da sie integraler Bestandteil des umfassenden Projektmanagementplans sind.

Beginnen wir mit dem Kommunikationsmanagementplan.

Effektive Kommunikation ist ein wesentlicher Erfolgsfaktor für jedes Projekt. Sollten wichtige Stakeholder nicht ausreichend über den Projektfortschritt informiert sein und die Kommunikation mangelhaft sein, ist die Wahrscheinlichkeit für Probleme hoch. Alle Projekte müssen ihren Fortschritt kommunizieren, wobei Sitzungen und Berichte typische Instrumente sind. Ein einfacher Kommunikationsplan legt fest, wann und wie das Team zusammentritt und wie der Fortschritt berichtet wird. Die Verwendung eines Kollaborationstools kann die Kommunikation erheblich erleichtern, und wenn das Team am gleichen physischen Ort arbeitet, wie es bei agilen Teams oft der Fall ist, wird die Kommunikation noch weiter vereinfacht. Bei der Planung der Kommunikation sollte man die Formate der zu verwendende Berichte vorbereiten und das Kollaborationstool bereitstellen.

Bei größeren Projekten oder solchen, die einen kulturellen Wandel bewirken sollen, ist ein vielschichtiger Kommunikationsansatz ratsam. Dies könnte etwa die Einrichtung einer speziellen Projektwebsite, die Durchführung regelmäßiger Veranstaltungen zur Kommunikation mit einem breiten Publikum und weitere Maßnahmen zur Förderung des Projekts beinhalten, ähnlich einer Marketingkampagne.

Risikomanagementplan.

Der Risikomanagementplan legt die Grundlagen für eine einheitliche Risikobewertung fest, um unterschiedliche individuelle Wahrnehmungen innerhalb des Projektteams und der Stakeholder zu vereinheitlichen. Während einige eine Verzögerung von zehn Minuten noch als pünktlich ansehen, könnte dies für andere inakzeptabel sein. Diese unterschiedlichen Sichtweisen auf das, was als akzeptabel oder inakzeptabel, wahrscheinlich oder unwahrscheinlich gilt, fließen als grundlegende Überzeugungen in das Projekt ein.

Um diese divergierenden Wahrnehmungen zu harmonisieren, ist es erforderlich, eine gemeinsame Grundlage für die Bewertung von Wahrscheinlichkeiten und Auswirkungen zu schaffen, die bei der Analyse zukünftiger Risikoereignisse zur Anwendung kommt. Darüber hinaus muss festgelegt werden, wie die Auswirkungen verschiedener Arten von Ereignissen – beispielsweise solche, die den Terminplan oder die Qualität betreffen oder zu Kostensteigerungen führen – gegeneinander abgewogen werden. So könnte beispielsweise diskutiert werden, ob eine zweiwöchige Verzögerung schwerwiegender ist als eine Kostenerhöhung von 10.000 Euro oder ein Qualitätsproblem, das eine wesentliche Funktionalität beeinträchtigt.

Der Risikomanagementplan sollte daher ein Bewertungssystem etablieren, das es ermöglicht, auch nicht direkt vergleichbare Ereignisse und ihre Auswirkungen bewertbar zu machen. Diese methodische Herangehensweise wird im Abschnitt über Risikomanagement detaillierter beschrieben, gehört aber konzeptionell bereits zum Risikomanagementplan, der als einer der Managementhilfspläne fungiert.

Qualitätsmanagementplan.

Der Qualitätsmanagementplan legt die Standards fest, die während der Lösungsentwicklung angewendet werden sollen. Dabei steht nicht die detaillierte Festlegung der Akzeptanzkriterien für jedes Arbeitspaket im Vordergrund, da diese auf der Ebene jedes einzelnen Arbeitspakets spezifiziert werden. Vielmehr gilt es, auf der Ebene der Gesamtlösung oder bei ausgewählten, bedeutenden Liefergegenständen die anzuwendenden Standards zu bestimmen. Dabei stehen oft mehrere Standards zur Verfügung. Die Auswahl der maßgeblichen Standards ist ein entscheidender Schritt im Qualitätsmanagement und erfordert sorgfältige Überlegung.

Ein weiterer bedeutender Aspekt betrifft die Qualität des Projektmanagements selbst. Hierbei stehen verschiedene Standards und Referenzwerke zur Verfügung, die als Grundlage für das Qualitätsmanagement dienen können. Der Projektmanagementplan umfasst zudem einen spezifischen Abschnitt, der die Anforderungen für das Projektmanagement festlegt. Diese Qualitätsanforderungen lassen sich durch die Orientierung an einem der anerkannten Projektmanagementstandards präzisieren. Eine Qualitätsprüfung des Projektmanagements würde dann untersuchen, inwieweit das Projekt gemäß dieser Norm geleitet wird. International anerkannte Standards für Projektmanagement sind die ISO 21502, der PMBOK Guide (A Guide to the Project Management Body of Knowledge) zusammen mit den Leitlinien der “Process Groups: A Practice Guide”, sowie Prince2 (Projects in Controlled Environments). Für das deutschsprachige Publikum kommt vor allem die DIN 69901 in Frage.

Ressourcenmanagementplan.

Ein Ressourcenmanagementplan könnte festlegen, wie das Projekt ungewöhnliche Ressourcen beschaffen möchte, beispielsweise durch die Nutzung von LinkedIn, Anzeigen in Zeitungen oder die Inanspruchnahme von Arbeitsvermittlungsagenturen. Des Weiteren würde der Ressourcenmanagementplan auch definieren, was mit den Vollzeitressourcen geschehen soll, sobald das Projekt abgeschlossen ist. Sollte das Team belohnt werden, falls das Projekt rechtzeitig, innerhalb des Budgets und mit einem guten Qualitätsniveau abgeschlossen wird? Falls ja, könnte der Ressourcenmanagementplan ein geeigneter Ort sein, um dies zu erwähnen.

Managementpläne für den Fortschrittsmessungsbasisplan.

• Ein Inhalts- und Umfangsmanagementplan sollte im Voraus den Detaillierungsgrad des Projektstrukturplans definieren.
• Ein Kostenmanagementplan würde festlegen, in welcher Währung die Kosten berechnet werden und welches Kostenniveau eine besondere Berichterstattung an das Leitungsgremium des Projekts auslöst.
• Ein Terminmanagementplan würde das Detailniveau festlegen, das für den Terminbasisplan verwendet wird, und sich mit dem Kommunikationsmanagementplan integrieren, indem die Häufigkeit regelmäßiger Berichte oder spezieller Berichte am Ende bestimmter Meilensteine, wie in den Phasenübergängen, definiert wird.

Pläne für das Problemmanagement und das Änderungsmanagement.

Der Plan oder das Verfahren zur Behandlung von Problemen und Änderungen sollte deutlich machen, wie mit diesen unvermeidlichen Situationen umgegangen wird. Die Kontrolle von Änderungen an den Basisplänen für Umfang, Terminplan und Kosten könnte in den entsprechenden Managementplänen für diese Elemente erläutert werden. Alternativ könnten sie auch in einem einheitlichen Änderungsmanagementprozess beschrieben werden, der festlegt, wie Änderungen an einem der Basispläne behandelt werden sollen.

Im Allgemeinen erfordern die Lösung von Problemen mit Auswirkungen auf die Basispläne und jede Änderung dieser Basispläne die Genehmigung des Projektleitungsgremiums, sei es des Sponsors oder, je nach Änderung und Auswirkung, sogar des Projektvorstands, sofern vorhanden. In extremen Fällen kann der Eskalationsprozess bis zur Unternehmensebene reichen, wenn das Problem oder die Änderung die Befugnisse des Projektleitungsgremiums übersteigt.

Es gehört zu bewährten Managementpraktiken des mittleren Managements, Alternativen zu definieren und ihre jeweiligen Auswirkungen zu analysieren, bevor eine Entscheidung über größere Probleme oder Änderungen von einer höheren Managementebene getroffen wird. Dieses Prinzip ist auch auf den Projektbereich anwendbar und wird in der Regel in den Verfahren zur Handhabung von Problemen und Änderungen festgelegt. Es erfordert die Berücksichtigung und Analyse verschiedener Optionen sowie die Bewertung ihrer Auswirkungen auf Inhalt, Umfang, Terminplan, Kosten, Qualität und Risiken. Bei der Präsentation eines größeren Problems oder eines Änderungsantrags vor dem Projektvorstand werden nicht nur das Problem oder der Bedarf an einer Änderung an einem Basisplan erläutert, sondern auch die Auswirkungen der Optionen sowie ein Vorschlag für den als am geeignetsten erachteter Lösungsweg.

Basierend auf dieser Grundlage kann das Projektleitungsgremium eine fundierte Entscheidung treffen. Wenn das Gremium den Vorschlag des Projektmanagers genehmigt, werden die erforderlichen Änderungen an den Basisplänen des Inhalts- und Umfangs, der Termine und der Kosten entsprechend der in der Optionsanalyse vorgelegten Entscheidungsfindung mitgenehmigt und diese Basisplänen werden entsprechend aktualisiert.

Zur Problematik der Managementpläne.

Zusätzlich zu den genannten Managementplänen können weitere Managementhilfspläne erforderlich sein, wie beispielsweise für das Beschaffungsmanagement, die Prozessverbesserung, das Anforderungsmanagement, usw. Es ist jedoch wichtig zu beachten, dass der Aufwand für die Planung in angemessenem Verhältnis zur Größe des Projekts stehen sollte. Befürworter agiler Ansätze kritisieren oft, dass traditionelles Projektmanagement zu viel Bürokratie erzeugt. In vielen Fällen ist diese Kritik durchaus berechtigt.

Auf der anderen Seite ist anzuerkennen, dass für eine agile Steuerung mit wenigen Plänen bestimmte Bedingungen erforderlich sind, die nicht alle Projekte erfüllen können. Eine agile Steuerung erfordert in der Regel ein kleines Team, das im selben Raum arbeitet und täglich kurze Meetings abhält, um den Fortschritt zu besprechen. Darüber hinaus erwartet der Kunde am Ende jeder kurzen Iteration, die normalerweise zwei Wochen dauert, ein fertiges und einsatzbereites Ergebnis einer Funktion und gibt Feedback für den weiteren Verlauf. Dies setzt voraus, dass das Produkt eine schrittweise Definition der Anforderungen ermöglicht und dass der Produktverantwortlicher kontinuierlich in das Projekt eingebunden ist. Wenn all diese Bedingungen erfüllt sind, sind viele der Managementhilfspläne möglicherweise nicht erforderlich, da das Team immer im gleichen Raum Vollzeit für das Projekt arbeitet, ständig informiert ist und der Produktverantwortlicher per Definition dauerhaft eingebunden ist.

Aber nicht alle Produkte können mit einem agilen Ansatz entwickelt werden, und nicht alle Organisationen wollen diesen Ansatz anwenden. Daher sind hybride Ansätze am häufigsten anzutreffen.

Eine der Verantwortlichkeiten eines guten Projektmanagers ist es, den Stil des Projektmanagements an die spezifischen Umstände des jeweiligen Projekts anzupassen und das angemessene Niveau der Managementpläne zu ermitteln.

Der Einfluss der Managementhilfspläne des Fortschrittsmessungsbasisplans.

Der Einfluss der Managementhilfspläne auf den Fortschrittsmessungsbasisplan ist von entscheidender Bedeutung. Diese Hilfspläne beeinflussen maßgeblich den Gesamtumfang des Projekts, die Kosten und den Terminplan. Daher bleiben die Elemente der Dreifachbeschränkung – also Aussagen über den Inhalt und Umfang, den Termin- und den Kostenplan – fortgeschrittene Entwürfe, die noch Beiträge aus den Managementhilfsplänen erhalten müssen.

Einige Beispiele für solche Ergänzungen sind die Kosten, der Aufwand und die Dauer von Aktivitäten, die sich aus einem Kommunikationsmanagementplan ergeben, wie Veranstaltungen, Reisen und Marketing. Ein weiteres Beispiel könnten die Kosten eines Auditdienstes und anderer Qualitätssicherungsaktivitäten sein. Darüber hinaus könnten Kosten für die Abdeckung von Währungsrisiken oder für die Beauftragung einer Arbeitsvermittlungsagentur zur Beschaffung bestimmter knapper Ressourcen anfallen. Auch die Kosten einer Bonuszahlung an das Team, falls ein Bonus im HR-Managementplan beschlossen wird, sind zu berücksichtigen.

Folglich ist es sehr wahrscheinlich, dass die fortgeschrittenen Entwürfe der Basispläne für den Inhalt und Umfang, die Termine und die Kosten während der Entwicklung dieser Managementhilfspläne aktualisiert werden müssen.

Zusammenfassend lässt sich sagen, dass eine angemessene Organisation der Projektkommunikation von entscheidender Bedeutung ist. Eine effektive Kommunikation trägt dazu bei, dass die meisten Aspekte des Projekts reibungslos funktionieren. Im Gegensatz dazu kann eine mangelhafte Kommunikation dazu führen, dass nichts im Projekt richtig läuft.

Was die anderen Nebenpläne für das Management betrifft, konsultieren Sie bitte das zusätzliche Material, das dieser Lektion beigefügt ist. Es enthält zusätzliche Erklärungen und Beispiele für die verschiedenen Nebenpläne für das Management.

 

2.7 Risikomanagement

Risikomanagement im Projektmanagement ist ein systematischer Prozess zur Identifikation, Analyse und Bewältigung von Risiken, die ein Projekt beeinflussen könnten. Der Zweck des Risikomanagements ist es, potenzielle Probleme zu erkennen, bevor sie auftreten, sodass vorbeugende Maßnahmen ergriffen werden können, um das Risiko zu mindern oder ganz zu eliminieren. Hierdurch können Projekte erfolgreicher abgeschlossen werden, indem Zeitverzögerungen, Kostenüberschreitungen und Qualitätsprobleme minimiert werden.

Die Hauptaspekte des Risikomanagements im Projektmanagement umfassen vier Planungsprozesse, gefolgt von einem Ausführungsprozess und einem Controllingprozess:

• Planung des Risikomanagements: Dieser erste Schritt umfasst die Erstellung eines Risikomanagementplans, welcher in diesem Abschnitt im Detail beschrieben wird.
• Identifizierung der Risiken: Dabei geht es darum, zu erkennen, welche Risiken potenziell das Projekt beeinflussen könnten.
• Analyse der identifizierten Risiken: Nach der Identifizierung erfolgt eine sorgfältige Analyse, um die kritischsten Risiken zu bestimmen und deren kombinierte Auswirkung auf die Projektziele zu evaluieren.
• Entwicklung von Risikobewältigungsstrategien: Auf Basis der Risikoanalyse bestimmen Sie Maßnahmen, um das Auftreten von Bedrohungen zu vermeiden oder deren Wahrscheinlichkeit und/oder Auswirkungen zu minimieren.
• Umsetzung der Risikobewältigungsstrategien: Die entwickelten Strategien werden im Rahmen der Projektdurchführung implementiert. Thematisch gehören diese Aktivitäten zur Projektausführung.
• Kontinuierliche Überwachung und Anpassung: Das Risikomanagement wird regelmäßig als Teil der Überwachung und Kontrolle des Projekts durchgeführt. Zu Beginn jeder neuen Projektphase ist es besonders wichtig, um neu auftretende Risiken frühzeitig zu erkennen und die Effektivität der umgesetzten Strategien zu überprüfen und gegebenenfalls anzupassen. Thematisch gehören diese Aktivitäten zum Projektcontrolling.

 

 

 

 

 

2.7.1 Risikomanagement planen

Dieser Abschnitt widmet sich dem Einstieg in das Risikomanagement, welcher mit dessen sorgfältiger Vorbereitung einhergeht.

Nachdem bereits erhebliche Anstrengungen in die Planung Ihres Projekts geflossen sind, stellt die Identifikation potenzieller Risiken, die die fristgerechte Lieferung im vereinbarten Umfang und Qualitätsniveau sowie innerhalb des Budgetrahmens gefährden könnten, einen wesentlichen Bestandteil dieser Planungsphase dar. Ziel ist es, solche Szenarien zu vermeiden.

Was verstehen wir unter Risiko?

Ein Risiko ist eine potenzielle Bedrohung, die sich zu einem zukünftigen Problem entwickeln könnte, auch wenn sie derzeit noch nicht aufgetreten ist. Es handelt sich um mögliche zukünftige Ereignisse oder Zustände, die negative Auswirkungen auf das Projekt haben könnten, wobei stets eine gewisse Unsicherheit über ihr Eintreten besteht.

Es ist wesentlich, zwischen einem Risiko und einem Problem zu unterscheiden:

• Ein Problem ist ein bereits eingetretenes negatives Ereignis, das einer Lösung bedarf.
• Ein Risiko hingegen ist ein potenzielles negatives Ereignis, das noch nicht eingetreten ist, aber eintreten könnte und somit die Erreichung der Projektziele beeinträchtigen würde.

Es ist ebenfalls wichtig, einen Aspekt des Risikomanagements hervorzuheben, der sich mit sogenannten positiven Risiken befasst, die wir vorzugsweise als Chancen betrachten. Ziel ist es, die Wahrscheinlichkeit des Eintritts dieser Chancen zu erhöhen, um sie zu unserem Vorteil zu nutzen. In diesem Abschnitt liegt unser Fokus jedoch auf den negativen Risiken, die wir als Bedrohungen identifizieren.

Das Risikomanagement, oder Bedrohungsmanagement, umfasst die folgenden Schritte:

1. Zunächst erfolgt die Vorbereitung des Risikomanagements. Dieser Schritt wird durch die Erstellung eines Risikomanagementplans durchgeführt, der in diesem Abschnitt ausführlich erklärt wird.
2. Als nächstes identifizieren wir die Risiken. Hier stellt sich die Frage: Welche Risiken könnten mein Projekt beeinflussen?
3. Nach der Identifizierung der Risiken folgt deren Analyse. In dieser Phase wird die Frage beantwortet: Welche dieser identifizierten Risiken sind am kritischsten und wie groß ist ihr kombinierter Einfluss auf die Projektziele?
4. Der vierte Schritt besteht darin, Antworten auf die im vorherigen Schritt identifizierten Risiken zu entwickeln. In dieser Phase wird festgelegt, welche Maßnahmen ergriffen werden, um die Auftreten von Bedrohungen zu vermeiden oder ihre Wahrscheinlichkeit oder ihren Einfluss zu minimieren.
5. Danach werden diese Antworten als Teil der Projektdurchführung umgesetzt.
6. Schließlich wird das Risikomanagement regelmäßig als Teil der Überwachung und Kontrolle der Projektausführung durchgeführt. Ein günstiger Zeitpunkt für die Durchführung dieses Managements ist zu Beginn einer neuen Projektphase. Der Zweck dieser Risikokontrolle besteht darin, neue Risiken zu erkennen und die Wirksamkeit der entworfenen und umgesetzten Antworten zu überprüfen und anzupassen.

Die Planung des Risikomanagements setzt die Erstellung oder Bereitstellung von drei essenziellen Elementen voraus, die für die Identifizierung und Analyse von Risiken unerlässlich sind:

• Risikoregister: Ein zentrales Dokument oder System zur Erfassung und Verfolgung aller identifizierten Risiken.
• Liste generischer Risiken oder Risikokategorien: Eine Übersicht über häufige Risiken, die in Projekten auftreten können, unterteilt in Kategorien, um die Identifizierung spezifischer Risiken zu erleichtern.
• Definition von Wahrscheinlichkeiten und Auswirkungen: Ein Rahmenwerk, das Ihrem Team hilft, die Risiken konsistent zu bewerten, indem es klare Parameter für die Bewertung von Wahrscheinlichkeiten des Eintretens und von potenziellen Auswirkungen auf das Projekt vorgibt.

Diese Elemente bilden die Grundlage für ein systematisches Risikomanagement und ermöglichen eine strukturierte Herangehensweise bei der Bewältigung von Projektunsicherheiten.

Im Folgenden wird eine generische Liste von Risiken oder Risikokategorien präsentiert:

Technische Risiken	Definition des Umfangs Anforderungsdefinition Schätzungen, Annahmen und Einschränkungen Technische Prozesse Technologie Technische Schnittstellen	Administrative Risiken	Projektmanagement Programm-/Portfolio- Management Funktionale Manager Ressourcen Organisation Kommunikation
Geschäfts Risiken	Vertragliche Bedingungen Interne Beschaffungen Lieferanten Subunternehmer Kunde Partnerschaften	Externe Risiken	Gesetzgebung Wechselkurse Standorte, Einrichtungen Klima, Umwelt Wettbewerb

Die Anwendung generischer Risikokategorien erleichtert es dem Projektteam, häufig auftretende Risiken, die spezifisch für die Art des Projekts sind, systematisch zu identifizieren. Diese methodische Herangehensweise ist wesentlich effizienter als ein unstrukturiertes Brainstorming. Durch die Analyse von Erfahrungen aus früheren Projekten kann Ihre Organisation wertvolles Wissen über häufige Stolpersteine sammeln. Dies ermöglicht eine individuelle Anpassung und Verfeinerung der Liste generischer Risiken, um sie noch besser auf das aktuelle Projekt abzustimmen.

Das zweite wesentliche Element im Risikomanagement ist das Risikoregister, das üblicherweise als Tabelle strukturiert ist. Es dient als zentrale Sammelstelle, in der alle identifizierten Risiken erfasst werden. Dieses Register kann als physisches Dokument, digitale Datei oder Datenbankeintrag gestaltet sein. Das Ziel ist es, einen strukturierten Überblick zu bieten, in dem Risiken nicht nur festgehalten, sondern auch fortlaufend mit zusätzlichen Informationen angereichert werden können, die während der Risikoanalyse und beim Entwickeln von Bewältigungsstrategien entstehen.

Ein Beispiel für das anfängliche Layout eines Risikoregisters könnte wie folgt aussehen:

Name des Risikos	Risiko nummer	Wahrscheinlichkeit 1 bis 5	Auswirkung 1 bis 5	Art der Strategie	Bewältigungs- Strategie	Risiko Verantwortlicher

Die präzise Festlegung von Wahrscheinlichkeiten und Auswirkungen ist entscheidend, um eine konsistente Risikobewertung im Team zu gewährleisten. Dieser Ansatz zielt darauf ab, den Einfluss subjektiver Einschätzungen in Diskussionen zu minimieren. So stellt sich beispielsweise die Frage, ob eine Budgetüberschreitung von 10.000 € schwerwiegender ist als eine Verzögerung von zwei Wochen. Zur Veranschaulichung und Unterstützung bei der Bewertung kann eine Matrix dienen, die Wahrscheinlichkeiten und Auswirkungen in Bezug auf die Projektziele kategorisiert.

Ein mögliches Format für eine solche Matrix könnte wie folgt aussehen:

Skala	Wahrscheinlichkeit	Auswirkung
		Terminplan	Kosten in €	Qualität
5 Sehr Hoch	>70%	> 6 Monate	> 500K	Sehr signifikanter Einfluss auf die Gesamtfunktionalität
4 Hoch	51% – 70%	3 ~ 6 Monate	100K ~ 500K	Signifikanter Einfluss auf die Gesamtfunktionalität
3 Mittel	31% – 50%	1 ~ 3 Monate	50K ~ 100K	Einige Auswirkungen auf wichtige funktionale Bereiche
2 Niedrig	11% – 30%	1 ~ 4 Wochen	10K ~ 50K	Geringfügige Auswirkungen auf die Gesamtfunktionalität
1 Sehr Niedrig	1% – 10%	1 Woche	<10K	Geringfügige Auswirkungen auf sekundäre Funktionen

Die Festlegung von Wahrscheinlichkeits- und Auswirkungsdefinitionen ist stark abhängig von der Risikotoleranz Ihrer Organisation und den spezifischen Anforderungen Ihres Projekts. Beispielsweise kann in einem zeitkritischen Projekt eine Verzögerung von einem Monat als besonders gravierend eingestuft werden, wohingegen in kostenorientierten oder kleineren Projekten ein finanzieller Verlust von 200.000 Euro als äußerst bedeutsam betrachtet werden könnte. Diese Bewertungsskalen müssen individuell für jedes Projekt angepasst und festgelegt werden, wobei bereits bestehende Richtlinien Ihrer Organisation als Orientierungshilfe dienen können.

Zusammenfassend ist es von entscheidender Bedeutung, sich auf die Identifikation und Analyse von Risiken vorzubereiten, indem folgende Elemente erstellt werden:

• Ein Risikoregister: Dient als zentrales Instrument zur Dokumentation aller identifizierten negativen Ereignisse.
• Eine Liste generischer Risiken oder Risikokategorien: Unterstützt das Team bei der systematischen Erkennung typischer negativer Ereignisse, die das Projekt beeinträchtigen könnten.
• Definitionen für verschiedene Wahrscheinlichkeits- und Auswirkungsebenen: Ermöglichen eine konsistente Bewertung der identifizierten Risiken.

Mit diesen Instrumenten kann Ihr Team beginnen, potenzielle negative Ereignisse zu identifizieren und zu klassifizieren, die ein Hindernis für das Erreichen der Projektziele darstellen könnten.

 

 

 

 

 

2.7.2 Risiken identifizieren

In diesem Abschnitt erhalten Sie eine praxisorientierte Anleitung zur effizienten Identifikation von Risiken. Bei kleineren Projekten, die sich durch kurze Laufzeiten, einen begrenzten Umfang und wenige Stakeholder auszeichnen, ist die Anzahl der Risiken üblicherweise geringer. In solchen Fällen kann der Projektmanager schnell offensichtliche Risiken identifizieren und gezielte Maßnahmen gegen die kritischsten Risiken ergreifen. Zudem wird ein allgemeiner Risikopuffer für unerwartete Ereignisse eingeplant. Bei größeren Projekten, die eine tiefergehende Analyse erfordern, werden Sie im Folgenden detailliertere Anleitungen finden.

Ein wirksamer Startpunkt für die Risikoidentifikation ist die frühzeitige Einbeziehung des gesamten Projektteams. Besonders wertvoll ist dabei die Mitwirkung des Projekt-Sponsors. Sein Verständnis des organisatorischen Kontexts des Projekts ermöglicht eine breitere Perspektive. Der Sponsor kann entscheidend dazu beitragen, die Vorgehensweise zu verfeinern und mögliche Hindernisse zu vermeiden, die aus seiner Sicht vielleicht offensichtlicher sind als aus der des Projektmanagers oder der anderen Teammitglieder.

Die Risikobewertung umfasst zwei wesentliche Schritte. Im ersten Schritt geht es darum, die inhärenten Risiken zu adressieren. Diese Risiken ergeben sich aus den grundlegenden Eigenschaften des Projekts und hängen nicht von dessen spezifischen Liefergegenständen ab. Sie können oft durch eine Liste generischer Risiken oder durch Risikokategorien identifiziert werden. Optimal ist die Verwendung einer organisatorischen Checkliste, die auf den Lernerfahrungen aus früheren Projekten aufbaut, um eine umfassende Identifikation sicherzustellen, wie bereits bei der Besprechung der Risikoplanung erwähnt.

Nachdem die inhärenten Risiken betrachtet wurden, ist es wichtig, die spezifischen Risiken Ihres Projekts zu erkennen. Diese Risiken sind einzigartig und lassen sich nicht vollständig durch allgemeine Listen abdecken. Beispiele hierfür könnten das Insolvenzrisiko eines Schlüssellieferanten oder wetterbedingte Probleme zu bestimmten Zeiten an spezifischen Orten sein. Auch das Auffinden von Ressourcen mit den benötigten speziellen Fähigkeiten kann ein Risiko darstellen.

Die Einbindung wichtiger Stakeholder in gemeinsame Besprechungen stellt die effektivste Methode zur Risikoidentifikation dar. Dabei sollten die Werkzeuge und Methoden angewandt werden, die bei der Risikoplanung entwickelt wurden. Abhängig von Umfang und Komplexität des Projekts kann dies eine oder mehrere Besprechungen erfordern.

Es ist empfehlenswert, die identifizierten Risiken thematisch zu gruppieren, bevor sie ins Risikoregister eingetragen werden. Zur Veranschaulichung dient unser Projekt, das darauf abzielt, die Transaktionstransparenz mittels einer Onlinelösung zu erhöhen. In diesem Rahmen berücksichtigen wir Liefergegenstände aus dem Projektstrukturplan sowie die vorläufigen Entwürfe der Basispläne für Termine und Kosten, die derzeit erarbeitet werden.

Betrachten wir als Beispiel die folgenden Arbeitspakete für die Entwicklung der Lösung:

• Funktionsspezifikationen für das gesamte Lösungsset
• Benutzeroberfläche
• Arbeitsabläufe
• Werkzeug zur Zustandsverfolgung
• Elektronische Zahlungen
• Onlinehilfe
• Schulungssitzungen

In den Brainstorming-Sitzungen zur Risikoidentifizierung wurden folgende Risiken erkannt:

• Funktionale Anforderungen: Es bestehen Unsicherheiten hinsichtlich der Robustheit der funktionalen Anforderungen für die Gesamtlösung.
• Werkzeug zur Zustandsverfolgung von Transaktionen: Der ausgewählte Anbieter ist im Land Z ansässig. Trotz seines attraktiven Preises und der professionellen Erscheinung sowie Sprachkenntnisse des Vertriebsmitarbeiters ist sein Ruf uns unbekannt, was eine detaillierte Überprüfung erforderlich macht.
• Elektronische Zahlungen: In Region X könnten strenge Genehmigungsprozesse die Abwicklung elektronischer Zahlungen in starken Währungen erschweren oder verhindern, was besonders relevant ist, da dort viele unserer Kunden ansässig sind.
• Onlinehilfe: Die aktuelle Inhalts- und Umfangsdefinition geht davon aus, dass die Onlinehilfe ausschließlich auf Englisch verfügbar sein wird. Es gibt jedoch Anzeichen dafür, dass die Verkaufsabteilung ebenfalls Versionen in Französisch, Spanisch, Deutsch und Arabisch anfordern wird.
• Schulungssitzungen: Die für die Standorte A, B und C budgetierten Reisekosten könnten sich als zu niedrig erweisen.
• Sponsor: Die Verfügbarkeit und Aufmerksamkeit des Projektsponsors könnten durch seine Beteiligung an anderen Projekten beeinträchtigt sein.

Der nächste Schritt besteht darin, die identifizierten Risiken ins Risikoregister einzutragen. Bitte nehmen Sie sich einen Moment Zeit, um das Risikoregister zu konsultieren.

Name des Risikos	Risikonummer	Wahrscheinlichkeit 1 bis 5	Auswirkung 1 bis 5	Kritikalität
Funktionale Anforderungen	1
Werkzeug zur Zustandsverfolgung von Transaktionen	2
Elektronische Zahlungen	3
Onlinehilfe	4
Schulungssitzungen	5
Sponsor	6

Zusammenfassend lässt sich sagen, dass die Risikoidentifizierung einen teamorientierten Ansatz verlangt, wobei die Einbindung des Sponsors von zentraler Bedeutung ist. Der Prozess unterteilt sich in zwei Hauptphasen: erstens die Erkennung generischer Risiken, die typisch für diesen Projekttyp sind, und zweitens die Identifizierung der spezifischen Risiken des eigenen Projekts. Nach ihrer Identifizierung werden die Risiken im Risikoregister verzeichnet, um sie späteren Analysen und Managementmaßnahmen zugänglich zu machen. Es ist anzumerken, dass mit wachsender Größe und Komplexität des Projekts ein formellerer Ansatz im Risikomanagement zu empfehlen ist.

 

 

 

 

 

2.7.3 Risiken analysieren

In diesem Abschnitt wird dargelegt, wie identifizierte Risiken praxisnah analysiert und klassifiziert werden, bevor Maßnahmen ergriffen werden. Nach der Identifikation der Risiken gilt es zuerst, die wichtigsten Risiken zu bestimmen, um dann deren mögliche Auswirkungen auf die Projektziele zu bewerten. Dieser Vorgang ist als Risikoanalyse bekannt.

Zur Analyse der erfassten Risiken wird zunächst das Risikoregister herangezogen. Danach werden die während der Risikomanagementplanung festgelegten Definitionen von Wahrscheinlichkeit und Auswirkung angewendet. Dies ermöglicht eine detaillierte Analyse und Bewertung jedes Risikos.

Skala	Wahrscheinlichkeit	Auswirkung
		Terminplan	Kosten in €	Qualität
5 Sehr Hoch	>70%	> 6 Monate	> 500K	Sehr signifikanter Einfluss auf die Gesamtfunktionalität
4 Hoch	51% – 70%	3 ~ 6 Monate	100K ~ 500K	Signifikanter Einfluss auf die Gesamtfunktionalität
3 Mittel	31% – 50%	1 ~ 3 Monate	50K ~ 100K	Einige Auswirkungen auf wichtige funktionale Bereiche
2 Niedrig	11% – 30%	1 ~ 4 Wochen	10K ~ 50K	Geringfügige Auswirkungen auf die Gesamtfunktionalität
1 Sehr Niedrig	1% – 10%	1 Woche	<10K	Geringfügige Auswirkungen auf sekundäre Funktionen

Risiko 1: Funktionale Anforderungen.

Obwohl die funktionalen Anforderungen des Lösungskonzepts umfassend erscheinen, äußern einige Teammitglieder Bedenken hinsichtlich der Qualität des Prozesses zur Ermittlung der Anforderungen für die Gesamtlösung. Die Befürchtung besteht, dass vage funktionale Anforderungen dazu führen könnten, dass die Bedürfnisse des Unternehmens nicht vollständig erfüllt werden. Das Risiko eines solchen Szenarios wird mit einer Wahrscheinlichkeit von über 70% als “sehr hoch” eingeschätzt, was einer Punktzahl von 5 entspricht. Auf den Terminplan bezogen könnten sich dadurch Verzögerungen von 3 bis 6 Monaten ergeben, was als “hoch” eingestuft und mit 4 Punkten bewertet wird. Die geschätzten Kostenfolgen werden auf 50.000 bis 100.000 € veranschlagt, was als “mittel” betrachtet und mit 3 Punkten versehen wird. In Bezug auf die Qualität könnte eine Unklarheit in den Anforderungen die Gesamtfunktionalität signifikant beeinträchtigen, was ebenfalls als “sehr hoch” angesehen und mit 5 Punkten bewertet wird.

Zusammenfassung der Bewertungen für Risiko Nummer 1:

• Wahrscheinlichkeitspunktzahl: 5
• Auswirkungspunktzahlen: Terminplan 4, Kosten 3, Qualität 5
• Gesamtauswirkungspunktzahl: 12 (4 + 3 + 5)
• Kritikalitätspunktzahl: 60 (5 x 12)

Die errechneten Punktzahlen sind in der folgenden Tabelle dargestellt:

Name des Risikos	Risikonummer	Wahrscheinlichkeit 1 bis 5	Auswirkung 1 bis 5	Kritikalität
Funktionale Anforderungen	1	5	12	69
Werkzeug zur Zustandsverfolgung von Transaktionen	2
Elektronische Zahlungen	3
Onlinehilfe	4
Schulungssitzungen	5
Sponsor	6

Risiko 2: Werkzeug zur Zustandsverfolgung von Transaktionen.

Der ausgewählte Anbieter aus Land Z ist für das Team neu und wurde hauptsächlich wegen seines attraktiven Preises gewählt, um die Budgetvorgaben des Finanzbereichs für dieses Jahr zu erfüllen. Positiv hervorzuheben ist, dass der Vertriebsmitarbeiter des Anbieters die Projektsprache fließend spricht und einen professionellen Eindruck macht.

Es bestehen jedoch Bedenken hinsichtlich der Zuverlässigkeit des Anbieters und möglicher erheblicher Kommunikationsprobleme, die wichtige Funktionen beeinträchtigen könnten. Die Wahrscheinlichkeit, dass diese Probleme auftreten, wird mit 51% bis 70% als “hoch” eingestuft und erhält eine Punktzahl von 4. Die potenziellen Auswirkungen dieser Probleme auf den Zeitplan könnten zu Verzögerungen von 3 bis 6 Monaten führen, was ebenfalls als “hoch” bewertet und mit 4 Punkten versehen wird. Die finanziellen Auswirkungen werden aufgrund der verhandelten Vertragsbedingungen auf unter 10.000 € geschätzt, was als “niedrig” eingestuft und mit 1 Punkt bewertet wird. Die mögliche Unzuverlässigkeit des Anbieters könnte sich jedoch sehr negativ auf die Gesamtqualität auswirken, was als “sehr hoch” angesehen und mit 5 Punkten bewertet wird.

Zusammenfassung der Bewertungen für Risiko Nummer 2:

• Wahrscheinlichkeitspunktzahl: 4
• Auswirkungspunktzahlen: Terminplan 4, Kosten 1, Qualität 5
• Gesamtauswirkungspunktzahl: 10 (4 + 1 + 5)
• Kritikalitätspunktzahl: 40 (4 x 10)

Die errechneten Punktzahlen sind in der folgenden Tabelle dargestellt:

Skala	Wahrscheinlichkeit	Auswirkung
		Terminplan	Kosten in €	Qualität
5 Sehr Hoch	>70%	> 6 Monate	> 500K	Sehr signifikanter Einfluss auf die Gesamtfunktionalität
4 Hoch	51% – 70%	3 ~ 6 Monate	100K ~ 500K	Signifikanter Einfluss auf die Gesamtfunktionalität
3 Mittel	31% – 50%	1 ~ 3 Monate	50K ~ 100K	Einige Auswirkungen auf wichtige funktionale Bereiche
2 Niedrig	11% – 30%	1 ~ 4 Wochen	10K ~ 50K	Geringfügige Auswirkungen auf die Gesamtfunktionalität
1 Sehr Niedrig	1% – 10%	1 Woche	<10K	Geringfügige Auswirkungen auf sekundäre Funktionen

Die Analyse der Risiken 3, 4, 5 und 6 erfolgt in ähnlicher Weise wie bei den vorherigen, indem jedes Risiko auf der Grundlage der Wahrscheinlichkeits- und Auswirkungsskalen bewertet wird, um die entsprechende Kritikalitätspunktzahl zu ermitteln. Die Ergebnisse dieser Analysen werden wie folgt dargestellt:

Risiko Nummer 3: Elektronische Zahlungen.

Ein signifikanter Anteil unserer Kunden befindet sich in Region X, wo die Durchführung elektronischer Zahlungen aufgrund strikter Genehmigungsverfahren für Transaktionen in starken Währungen erschwert oder sogar verhindert werden könnte.

Zusammenfassung der Bewertungen für Risiko Nummer 3:

• Wahrscheinlichkeitspunktzahl: 5
• Auswirkungspunktzahlen: Terminplan 1, Kosten 1, Qualität 3
• Gesamtauswirkungspunktzahl: 5 (1 + 1 + 3)
• Kritikalitätspunktzahl: 25 (5 x 5)

Risiko Nummer 4: Onlinehilfe.

Alle Schätzungen basieren auf einer Onlinehilfe in Englisch, und es wurde ausdrücklich erklärt, dass andere Sprachen “außerhalb des Umfangs” liegen. Es gibt jedoch Gerüchte, dass dies für die Vertriebsabteilung nicht akzeptabel ist, die anscheinend auch Unterstützung auf Französisch, Spanisch, Deutsch und Arabisch wünscht.

Zusammenfassung der Bewertungen für Risiko Nummer 4:

Wahrscheinlichkeitspunktzahl: 3

Auswirkungspunktzahlen: 2 + 2 + 3

Gesamtauswirkungspunktzahl: 7 (2 + 2 + 3)

Kritikalitätspunktzahl: 21 (3 x 7)

Risiko Nummer 5: Schulungssitzungen.

Die Budgetschätzungen für Reisen zu den Standorten A, B und C scheinen zu optimistisch zu sein.

Zusammenfassung der Bewertungen für Risiko Nummer 5:

• Wahrscheinlichkeitspunktzahl: 4
• Auswirkungspunktzahlen: 1 + 2 + 1
• Gesamtauswirkungspunktzahl: 4 (1 + 1 + 2)
• Kritikalitätspunktzahl: 16 (4 x 4)

Risiko Nummer 6: Geringes Engagement des Sponsors.

Die Analyse dieses Risikos deutet darauf hin, dass die starke Einbindung des Sponsors in andere hochpriorisierte Projekte zu signifikanten Problemen im aktuellen Projekt führen kann. Das Team hält es für sehr wahrscheinlich (über 70%), dass der Sponsor nicht ausreichend in dieses Projekt involviert sein wird, was mit einer hohen Wahrscheinlichkeitspunktzahl von 5 bewertet wird. Das Fehlen der Sponsorunterstützung könnte erhebliche Herausforderungen bei der Mobilisierung der notwendigen internen Ressourcen darstellen und möglicherweise Verzögerungen von 3 bis 6 Monaten zur Folge haben, was als “hoch” eingeschätzt und mit einer Auswirkungspunktzahl von 4 bewertet wird. Zusätzlich könnten die unter Zeitdruck vom Sponsor formulierten Geschäftsanforderungen zusätzliche Kosten von 100.000 bis 500.000 € verursachen, was ebenfalls als “hoch” bewertet und mit 4 Punkten versehen wird. Schließlich könnte der Mangel an Unterstützung durch den Sponsor bei der Beschaffung geeigneter interner Ressourcen einen signifikanten negativen Einfluss auf die Gesamtfunktionalität der Lösung haben, was als “hoch” eingestuft und mit einer Punktzahl von 4 bewertet wird.

Zusammenfassung der Bewertungen für Risiko Nummer 6:

• Wahrscheinlichkeitspunktzahl: 5
• Auswirkungspunktzahlen: Terminplan 4, Kosten 4, Qualität 4
• Gesamtauswirkungspunktzahl: 12
• Kritikalitätspunktzahl: 60 (5 x 12)

Im nächsten Schritt wird das aktualisierte Risikoregister vorgestellt, das nach absteigender Kritikalität sortiert ist. Bitte nehmen Sie sich einen Moment Zeit, um die Ergebnisse im aktualisierten Risikoregister zu überprüfen.

Name des Risikos	Risikonummer	Wahrscheinlichkeit 1 bis 5	Auswirkung 1 bis 5	Kritikalität
Funktionale Anforderungen	6	5	12	60
Werkzeug zur Zustandsverfolgung von Transaktionen	1	5	12	60
Elektronische Zahlungen	2	4	10	40
Onlinehilfe	3	5	5	25
Schulungssitzungen	4	3	7	21
Sponsor	5	4	4	16

Die durchgeführte Risikoanalyse hat wesentliche Erkenntnisse geliefert, die es ermöglichen, die am meisten kritischen Risiken herauszustellen. Diese Erkenntnisse befähigen uns, unsere Ressourcen und Strategien gezielt auf die Bewältigung dieser besonders dringenden Risiken zu konzentrieren, während für die weniger kritischen Risiken weniger aufwendige Maßnahmen vorgesehen werden. Diese zielgerichtete Vorgehensweise trägt maßgeblich zur Effizienzsteigerung im Projektmanagement bei.

Zusammenfassend wird die Klassifizierung jedes Risikos durch eine spezifische Kritikalitätspunktzahl vorgenommen, die sich aus der Multiplikation der Punkte für Wahrscheinlichkeit und Auswirkung ergibt. Dieser Vorgang ist ein elementarer Teil der qualitativen Risikoanalyse, die primär auf die Bewertung und Priorisierung der Risiken abzielt. Im Rahmen der quantitativen Risikoanalyse werden hingegen die potenziellen Auswirkungen der Risiken auf die festgelegten Projektziele – vor allem bezüglich Kosten, Terminplan und Qualität – genauer quantifiziert. Diese Methode erlaubt eine tiefergehende Untersuchung der Risiken und ihrer möglichen Auswirkungen auf das Projekt.

 

 

2.7.4 Risikobewältigungsstrategien

In diesem Abschnitt gehen wir auf die verschiedenen Strategien ein, die zur Bewältigung der im Projekt identifizierten Risiken eingesetzt werden können. Nachdem die Risiken mit der höchsten Priorität ermittelt wurden, ist es möglich, maßgeschneiderte Lösungen zu entwickeln, die ihre spezifische Bedeutung und Dringlichkeit berücksichtigen.

Es ist essenziell, dass der Risikomanagementplan klare Kriterien festlegt, die bestimmen, ab welchem Punkt ein Risiko eine aktive Bewältigungsstrategie verlangt. Nehmen wir beispielsweise an, der Plan sieht vor, dass Risiken mit einem Kritikalitätsgrad von über 25 aktiv angegangen werden müssen.

Unter dieser Prämisse wären folgende Risiken besonders zu beachten:

• Risiko Nummer 6: Mangelndes Engagement des Sponsors
• Risiko Nummer 1: Unklare funktionale Anforderungen
• Risiko Nummer 2: Unzuverlässigkeit des Anbieters für das Transaktionsverfolgungstool
• Risiko Nummer 3: Schwierigkeiten bei elektronischen Zahlungen in einigen Ländern

Für die übrigen Risiken, insbesondere die Nummern 4 und 5 mit einem Kritikalitätsgrad unter 25, verfolgen wir eine Strategie der aktiven Akzeptanz. Hierfür legen wir Reserven in Bezug auf Zeit und Budget an und überwachen diese Risiken sorgfältig, um sicherzustellen, dass sie auf diesem Kritikalitätsniveau bleiben.

Risikobewältigungsstrategien.

Die gängigsten Strategien zur Risikobewältigung sind Vermeidung, Milderung, Übertragung und Akzeptanz. Jede Strategie bietet spezifische Methoden, um mit Risiken umzugehen.

Vermeidung eines Risikos.

Die Vermeidungsstrategie strebt an, ein Risiko komplett zu eliminieren, indem die Ursachen direkt angegangen werden. Dies kann durch Änderungen in den Projektzielen oder im Projektmanagementplan erreicht werden und kann zu tiefgreifenden Änderungen führen, wie dem Entfernen eines Arbeitspakets oder dem Wechsel eines Lieferanten.

Ein Beispiel hierfür ist das Sprachrisiko in unserer Onlinehilfe. Um dieses Risiko zu vermeiden, wurde beschlossen, ausschließlich Englisch zu unterstützen. Diese Entscheidung hat zwar das Risiko vermieden, aber auch Bedenken bei der Vertriebsabteilung hervorgerufen, was die Wichtigkeit des Managements von Stakeholder-Erwartungen unterstreicht. Das Beispiel zeigt, dass die Vermeidungsstrategie Risiken eliminieren kann, aber auch unbeabsichtigte Konsequenzen haben könnte.

Milderung eines Risikos.

Die Milderungsstrategie zielt darauf ab, entweder die Wahrscheinlichkeit des Eintretens eines Risikos oder dessen potenzielle Auswirkungen zu reduzieren. Dies wird durch gezielte Maßnahmen erreicht, die genau auf die spezifischen Charakteristika des Risikos abgestimmt sind.

Ein Beispiel hierfür ist die Herausforderung, wenn Stakeholder Schwierigkeiten haben, ihre Anforderungen klar zu definieren. In einem solchen Fall kann die Entwicklung eines Prototyps dazu beitragen, Missverständnisse zu beseitigen und somit das Risiko zu mindern. Der Prototyp dient als konkretes Kommunikationsmittel, das hilft, Erwartungen zu klären und die Anforderungen präziser zu fassen.

Ein weiteres Beispiel betrifft Kommunikationsschwierigkeiten, die durch geografische Distanzen verursacht werden. Die Implementierung leistungsfähiger Werkzeuge für die virtuelle Zusammenarbeit, ergänzt durch zielgerichtete Schulungen zur effektiven Nutzung dieser Werkzeuge, kann solche Risiken deutlich verringern. Diese präventiven Maßnahmen verbessern nicht nur die Kommunikation innerhalb des Projekts, sondern tragen auch dazu bei, Missverständnisse zu reduzieren und die Zusammenarbeit zu stärken.

Übertragung eines Risikos.

Die Übertragungsstrategie beinhaltet, die Verantwortung für ein bestimmtes Risiko an eine externe Partei zu übergeben, die besser geeignet ist, dieses zu managen. Ein klassisches Beispiel hierfür ist der Abschluss einer Versicherung, wodurch das finanzielle Risiko auf die Versicherungsgesellschaft übertragen wird.

Ein weiteres Beispiel ist das Auslagern von Arbeitspaketen an ein externes Unternehmen, das spezialisiert und daher besser ausgestattet ist, bestimmte Risiken zu bewältigen. Durch diese Strategie kann das Projektteam Risiken effektiv managen, indem es sie an Dritte überträgt, die über die notwendige Erfahrung oder Ressourcen verfügen, um damit umzugehen.

Akzeptanz eines Risikos.

Die Akzeptanzstrategie beinhaltet die bewusste Entscheidung, keine unmittelbaren Maßnahmen zur Minderung oder Vermeidung eines Risikos zu ergreifen. Diese Strategie wird typischerweise bei Risiken angewandt, die als weniger kritisch für das Projekt betrachtet werden.

Bei der passiven Akzeptanz werden keine vorbeugenden Schritte unternommen. Das Projektteam erkennt das Risiko an, entscheidet sich jedoch dafür, keine spezifischen Maßnahmen zu ergreifen, außer es zu überwachen und auf etwaige Auswirkungen zu reagieren, falls es eintritt.

Im Gegensatz dazu beinhaltet die aktive Akzeptanz die Einrichtung von Maßnahmen, die darauf vorbereiten, auf das Risiko zu reagieren, sollte es sich realisieren. Dazu gehört beispielsweise das Anlegen von finanziellen und zeitlichen Reserven, auch bekannt als Risikozuschläge. Diese Reserven dienen dazu, potenzielle Auswirkungen abzumildern, ohne dass das Risiko direkt angegangen wird.

Risiko-Eskalation.

In manchen Situationen trifft das Projektteam auf Risiken, die außerhalb seines Einflussbereichs oder seiner Kompetenzen liegen. In diesen Fällen ist eine Eskalation erforderlich, d.h. das Risiko muss einer höheren Entscheidungsebene innerhalb der Organisation gemeldet werden, die besser zur Bewältigung des Risikos geeignet ist.

Die Kriterien für eine Eskalation sollten präzise im Risikomanagementplan festgelegt sein. Typischerweise sind für eine Eskalation der Projektsponsor oder ein Lenkungsausschuss die geeigneten Ansprechpartner, besonders bei Risiken, die potenziell die gesamte Organisation beeinflussen könnten, wie z.B. drohende vertragliche Strafen.

Ein klar definierter Eskalationsprozess stellt sicher, dass Risiken effektiv an die richtige Stelle weitergeleitet werden, um eine angemessene Reaktion und effektive Risikosteuerung zu gewährleisten.

Beispielhafte Risikobewältigungsstrategien.

Im Rahmen unseres Fallbeispiels konzentrieren wir uns auf die Entwicklung von Maßnahmen für Risiken, die einen Kritikalitätswert von 25 oder höher aufweisen. Dies betrifft die folgenden identifizierten Risiken:

• Risiko Nummer 6: Mangelndes Engagement des Sponsors
• Risiko Nummer 1: Unklare funktionale Anforderungen
• Risiko Nummer 2: Unzuverlässigkeit des Anbieters für das Transaktionsverfolgungstool
• Risiko Nummer 3: Schwierigkeiten bei elektronischen Zahlungen in einigen Ländern

Risiko Nummer 6: Mangelndes Engagement des Sponsors.

Um dem Risiko eines wenig involvierten Sponsors entgegenzuwirken, könnte der Projektmanager die Ernennung eines Stellvertreters vorschlagen. Diese Person würde den Sponsor in den täglichen Projektangelegenheiten vertreten und sicherstellen, dass eine gewisse Führung und Aufmerksamkeit dem Projekt gewidmet wird. Die Implementierung dieser Milderungsmaßnahme gewährleistet, dass trotz der zeitlichen Einschränkungen des Haupt-Sponsors eine kontinuierliche Unterstützung und Entscheidungsfindung für das Projekt gegeben ist.

Risiko Nummer 1: Unklare funktionale Anforderungen.

Eine mögliche Reaktion auf das Risiko unklarer funktionaler Anforderungen ist der Übergang von einem prädiktiven zu einem inkrementellen Ansatz. Bei der Anwendung eines inkrementellen Ansatzes würden die Anforderungen für einige ausgewählte Funktionen zunächst festgelegt und in einer ersten Lösungsversion umgesetzt. Weitere Funktionen würden dann in späteren Phasen mit detaillierteren Anforderungen implementiert. Dieser Ansatz stellt eine Vermeidungsstrategie dar, da er eine Änderung des Projektmanagementplans von einer vollständigen Implementierung hin zu einer schrittweisen Auslieferung bewirkt. Im Gegensatz dazu würde das Beibehalten des prädiktiven Ansatzes, ergänzt durch zusätzliche Workshops zur präziseren Definition der Anforderungen der gesamten Lösung, als Milderungsstrategie fungieren. Hierbei wird versucht, das Risiko durch ein tieferes Verständnis und Klärung der Anforderungen zu reduzieren, ohne den grundsätzlichen Projektansatz zu ändern.

Risiko Nummer 2: Unzuverlässigkeit des Anbieters für das Transaktionsverfolgungstool.

Das Projektmanagementteam erwägt verschiedene Strategien im Umgang mit der Unzuverlässigkeit des Anbieters.

• Vermeidungsstrategie: Eine Option ist der Wechsel des Anbieters, der das Risiko komplett eliminiert, indem die Ursache direkt angegangen wird. Diese Maßnahme würde das Problem an der Wurzel packen und eine dauerhafte Lösung bieten.
• Milderungsstrategie: Eine andere Herangehensweise ist die intensivierte Überwachung der Leistungen des aktuellen Anbieters. Durch frühzeitiges Erkennen und Adressieren potenzieller Probleme soll das Risiko minimiert werden.
• Übertragungsstrategie: Zusätzlich könnte eine Übertragungsstrategie angewendet werden, indem vertragliche Strafen für Verzögerungen festgelegt werden, um das finanzielle Risiko teilweise zurück an den Anbieter zu übertragen. Bei dieser Strategie ist es allerdings wichtig, die Realisierbarkeit und Durchsetzbarkeit solcher Vereinbarungen genau zu betrachten. Ähnlich den Herausforderungen bei der Inanspruchnahme von Versicherungsleistungen können vertragliche Strafen eigene Schwierigkeiten in Bezug auf die Durchsetzung und den Erhalt der Kompensationen mit sich bringen.

Risiko Nummer 3: Schwierigkeiten bei elektronischen Zahlungen in einigen Ländern.

Um auf die Herausforderungen bei der Abwicklung elektronischer Zahlungen in bestimmten Ländern zu reagieren, könnte eine Übertragungsstrategie darin bestehen, Partnerschaften mit lokalen Finanzinstituten zu etablieren. Diese Institutionen könnten helfen, sogenannte “trianguläre Zahlungslösungen” anzubieten, die speziell auf die Bedürfnisse dieser Märkte zugeschnitten sind. Dies würde das Risiko auf die lokalen Partner übertragen, die besser mit den spezifischen regulatorischen und operativen Anforderungen in ihren Ländern vertraut sind.

Als alternative Vermeidungsstrategie könnte entschieden werden, auf elektronische Zahlungen in diesen Ländern ganz zu verzichten und stattdessen auf traditionelle manuelle Banküberweisungen zurückzugreifen. Dies würde das Risiko umgehen, indem die Notwendigkeit komplexer elektronischer Zahlungssysteme eliminiert und auf eine bewährte, wenn auch weniger effiziente Zahlungsmethode zurückgegriffen wird.

Für Risiken 4 und 5, die unterhalb einer Kritikalitätsschwelle von 25 liegen, bietet sich die Definition einer aktiven Akzeptanzstrategie an. Dies bedeutet, dass Zeit- und Geldreserven sowohl im Terminplan als auch im Budget eingeplant werden, um möglichen Unvorhersehbarkeiten proaktiv begegnen zu können. Diese Reserven dienen als Puffer, um auf unerwartete Ereignisse reagieren zu können, ohne den Projektverlauf oder das Gesamtbudget zu gefährden.

Nach der Festlegung der Risikobewältigungsstrategien ergibt sich folgende Aktualisierung im Risikoregister. Die festgelegten Maßnahmen umfassen:

• Einen Stellvertreter für den Sponsor benennen, um dessen Engagement im Projekt zu gewährleisten.
• Workshops zur detaillierten Anforderungserhebung durchführen.
• Den Anbieter für das Werkzeug zur Zustandsverfolgung wechseln, um Zuverlässigkeit zu sichern.
• Einen Dienstleister für trianguläre Zahlungslösungen beauftragen, um elektronische Zahlungen in schwierigen Märkten zu erleichtern. Diese Lösungen ermöglichen die Abwicklung von Zahlungen über Drittparteien und bieten so eine Anpassung an lokale Gegebenheiten.
• Zeit- und Geldreserven (Risikozuschläge) im Terminplan und Budget bilden, um Risiken zu managen, die mit einer aktiven Akzeptanzstrategie gehandhabt werden.

Bitte nehmen Sie sich einen Moment Zeit, um das aktualisierte Risikoregister zu konsultieren.

Name des Risikos	Risiko- nummer	Wahrscheinlichkeit 1 bis 5	Auswirkung 1 bis 5	Kritikalität	Strategie	Antwort
Sponsor	6	5	12	60	Mildern	Nominierung eines delegierten Sponsors
Funktionale Anforderungen	1	5	12	60	Mildern	Workshops zur Anforderungserhebung
Werkzeug zur Zustandsverfolgung von Transaktionen	2	4	9	36	Vermeiden	Ersatz des Anbieters
Elektronische Zahlungen	3	5	5	25	Übertragen	Beauftragung eines Anbieters für Trianguläre Zahlungslösungen
Onlinehilfe	4	3	7	21	Akzeptieren	Reserve von 2 Wochen und 25K € (*)
Schulungssitzungen	5	4	4	16	Akzeptieren	Reserve von 1 Woche und 35K € (**)

(*) Mittlere Wahrscheinlichkeit: 3 = 31%-50% / Zeitliche Auswirkung (niedrig) 1-4 Wochen; 50% von 4 Wochen = 2 Wochen / Kostenauswirkung (niedrig) 10.000 € – 50.000 €; 50% von 50.000 € = 25.000 €.

(**) Hohe Wahrscheinlichkeit: 4 = 51%-70% / Zeitliche Auswirkung (sehr niedrig) 1 Woche x 70% = 0,7 Wochen, aufgerundet auf 1 Woche / Kostenauswirkung (niedrig) 10.000 € – 50.000 €; 50.000 € x 70% = 35.000 €.

Notfallplan.

Für besonders kritische Risiken ist es ratsam, einen Ausweichplan, oft Plan B genannt, zu entwickeln, der aktiviert wird, falls das Risiko trotz der gewählten Bewältigungsstrategie zum Problem wird. Als Beispiel könnte, falls das Team sich entscheidet, den Anbieter für das Tracking-Tool unter Anwendung einer Milderungsstrategie beizubehalten, als Plan B die Vorauswahl eines potenziellen Ersatzanbieters dienen.

Sekundäre Risiken.

Die Umsetzung spezifischer Risikobewältigungsstrategien kann zu neuen, sogenannten sekundären Risiken führen. Diese entstehen als Folge der ergriffenen Maßnahmen gegen das ursprüngliche Risiko. Ein alltägliches Beispiel hierfür ist der Versuch, der Routine in einer Beziehung zu entkommen, indem eine romantische Woche auf den Seychellen verbracht wird. Die Routine stellt in diesem Fall das primäre Risiko dar. Die Reaktion darauf könnte jedoch zu einem neuen finanziellen Risiko führen, falls die Kosten des Urlaubs die finanzielle Stabilität gefährden. Dieses finanzielle Risiko wäre dann ein sekundäres Risiko, das als direkte Konsequenz aus der Bewältigungsstrategie für das primäre Risiko entsteht.

Bis zu welchem Niveau ist es vernünftig, in eine Strategie zur Risikobewältigung zu investieren?

Bei der Investition in Risikobewältigungsstrategien ist das Kosten-Nutzen-Verhältnis entscheidend. Die Kosten für Risikomanagementmaßnahmen sollten im Budget berücksichtigt werden, dabei muss jedoch eine finanzielle Obergrenze eingehalten werden: Die Ausgaben für eine Risikobewältigungsstrategie sollten nicht höher sein als der erwartete monetäre Wert des Risikos. Dieser Wert errechnet sich aus der Eintrittswahrscheinlichkeit des Risikos multipliziert mit den potenziellen Kosten seiner Auswirkungen.

Wenn die Kosten zur Bewältigung eines Risikos dessen erwarteten monetären Wert überschreiten, kann es sinnvoller sein, das Risiko zu akzeptieren und stattdessen eine finanzielle Reserve in Höhe dieses Wertes zu bilden.

Beispiel: Als Freelancer mit einem Jahreseinkommen von 100.000 € beträgt das Risiko, aufgrund gesundheitlicher Probleme ein Jahr lang kein Einkommen zu erzielen, 1%. Der erwartete monetäre Wert dieses Risikos ist daher 1.000 € (1% von 100.000 €). Wenn die Kosten für eine Versicherung, die dieses Risiko abdeckt, 2.000 € betragen, wäre es wirtschaftlicher, eine eigene Rücklage in Höhe von 1.000 € zu bilden.

Restrisiken.

Es ist wichtig zu erkennen, dass auch nach der Anwendung von Milderungsstrategien ein Restrisiko bestehen bleibt. Restrisiken sind jene Risiken, die nach der Risikominderung noch verbleiben, da es selten möglich ist, die Wahrscheinlichkeit und die potenziellen Auswirkungen eines ursprünglichen Risikos vollständig zu eliminieren.

Daher ist es ratsam, Reserven nicht nur für bewusst akzeptierte Risiken einzuplanen, sondern auch für diese verbleibenden Restrisiken. Dies gewährleistet eine umfassende Vorsorge und trägt dazu bei, das Projekt auch vor unerwarteten Ereignissen zu schützen.

Aktualisierung des Projektmanagementplans.

Nachdem die Risikobewältigungsstrategien definiert wurden, ist es unerlässlich, den Projektmanagementplan entsprechend zu aktualisieren, um die neuen Maßnahmen und Ansätze zu integrieren. Folgende Anpassungen sind erforderlich:

• Delegierten Sponsor gewinnen: Es ist entscheidend, einen Stellvertreter für den Sponsor zu finden, der das Projekt aktiv unterstützt und so ein starkes Sponsoring sicherstellt.
• Zusätzliche Workshops durchführen: Um die funktionalen Anforderungen zu präzisieren, sind weitere Workshops erforderlich. Dies erfordert die Einführung eines neuen Arbeitspakets, das Zeit- und Kostenpläne beeinflussen kann.
• Neuen Anbieter für das Transaktions-Tracking wählen: Ein zuverlässiger neuer Anbieter für das Tracking-System muss gefunden und beauftragt werden.
• Trianguläre Zahlungslösungen für spezifische Märkte einführen: Bei der Auswahl eines Anbieters für trianguläre Zahlungslösungen ist sorgfältige Prüfung geboten. Es ist wichtig, die potenziellen Transaktionsgebühren zu berücksichtigen und wie diese das Geschäftsmodell und den Cashflow beeinflussen könnten.

Um in den Projektmanagementplan aufgenommen zu werden, müssen diese ausgewählten Risikobewältigungsstrategien als Arbeitspakete definiert werden.

Unbekannte Risiken.

Neben den bereits identifizierten Risiken gibt es auch unbekannte Risiken. Diese sind jene negativen Ereignisse, die während der Risikoanalysephase unentdeckt bleiben. Für den Umgang mit solchen unvorhergesehenen Risiken wird eine Managementreserve vorgehalten.

Managementreserve.

Die Managementreserve stellt einen speziellen Teil des Projektbudgets oder Terminplans dar, der nicht im festgelegten Projektbasisplan enthalten ist. Sie liegt außerhalb der direkten Kontrolle des Projektmanagers und ist nicht für die Fortschrittsmessung vorgesehen. Ihre Hauptfunktion ist es, unerwartete Aufgaben zu finanzieren, die innerhalb des Projektumfangs auftreten, aber nicht im Voraus geplant werden konnten.

Die Verantwortung für die Verwaltung dieser Reserve trägt der Projektsponsor, nicht der Projektmanager. Dies macht eine enge Abstimmung mit dem Sponsor besonders wichtig, um effektiv auf unvorhersehbare Ereignisse und Herausforderungen reagieren zu können, die über die ursprüngliche Projektplanung hinausgehen.

Verantwortlicher für jedes Risiko.

Ein wesentlicher Schritt im Abschluss des Risikomanagementprozesses ist die Zuweisung einer verantwortlichen Person für jedes identifizierte Risiko. Diese Person, im Risikoregister namentlich als Risikobeauftragter (oder Risikoeigner) verzeichnet, übernimmt folgende Hauptaufgaben:

• Überwachung des Risikos: Die fortlaufende Beobachtung des Risikostatus und der Risikoentwicklung.
• Umsetzung der Risikobewältigungsstrategie: Die Durchführung der geplanten Maßnahmen zur Risikominimierung oder -vermeidung.
• Kontrolle der Strategieeffektivität: Die regelmäßige Überprüfung und Anpassung der Risikobewältigungsmaßnahmen, um ihre Wirksamkeit sicherzustellen.

Der Risikobeauftragte trägt somit die fortlaufende Verantwortung für das Management des ihm zugewiesenen Risikos während des gesamten Projektverlaufs.

Schwelle zur Auslösung eines Notfallplans.

Im fortgeschrittenen Risikomanagement wird oft ein quantifizierbarer Schwellenwert festgelegt, der kontinuierlich überwacht wird. Wird dieser Wert von einem Risiko überschritten, aktiviert sich automatisch der vorab definierte Notfallplan. Diese Methode bietet eine präzise und objektive Möglichkeit, Risiken zu handhaben, indem sie klare Richtlinien vorgibt, wann einzugreifen ist.

Beispiele:

• In der Entwicklungsphase eines Softwareprojekts: Überschreitet die Fehlerquote im Code 5%, wird das Entwicklungsteam um einen Qualitätsexperten erweitert.
• Bei der Planung eines Events: Übersteigt die Regenwahrscheinlichkeit drei Tage vor dem Event 60%, wird sofort der Ausfallplan B in Kraft gesetzt.

Lassen Sie uns die Kernpunkte im Risikomanagement wie folgt zusammenfassen:

• Die gängigen Strategien zur Risikobewältigung umfassen Vermeidung, Milderung, Übertragung und Akzeptanz.
• Die Reaktion auf ein Risiko kann ein neues, sogenanntes sekundäres Risiko hervorbringen.
• Nach der Milderung eines Risikos verbleibt oft ein Restrisiko. Die eingeplanten Reserven (Risikozuschläge in Zeit und Budget) sollten sowohl für akzeptierte Risiken als auch für Restrisiken vorgesehen werden.
• Nach der Festlegung von Risikobewältigungsstrategien ist eine Aktualisierung des Projektmanagementplans notwendig. Dies beinhaltet die Definition und Planung neuer Arbeitspakete, die sich aus den Strategien ergeben, einschließlich ihrer Kosten, Aufwände und Dauer.
• Zusätzlich können durch die Umsetzung von Risikobewältigungsstrategien Anpassungen in anderen Bereichen des Projektmanagementplans erforderlich sein, wie etwa in der Kommunikation, Qualitätssicherung und Beschaffung.

 

 

 

 

 

2.8 Integration des Projektmanagementplans

Dieser Abschnitt konzentriert sich auf die Zusammenführung aller Komponenten des Projektmanagementplans. Im Mittelpunkt steht die Integration aller zuvor diskutierten Elemente, einschließlich des Basisplans für die Fortschrittsmessung und aller unterstützenden Pläne, sowie das Teilen des finalen, abgestimmten Projektmanagementplans mit den Stakeholdern.

Teamarbeit und Planentwicklung.

Das Kernprojektteam arbeitet eng mit Fachexperten und Hauptstakeholdern zusammen, darunter der Projektsponsor. Gemeinsam entwickeln sie die grundlegenden Pläne in Bezug auf Inhalt, Umfang, Zeitplanung und Budgetierung. Dieser Prozess umfasst auch die Entwicklung von Risikomanagementstrategien und die Erstellung von unterstützenden Hilfsmanagementplänen.

Alles beginnt mit dem Projektauftrag, der das zu lösende Problem klar definiert und das Hauptziel des Projekts festlegt. Dieser wird durch eine oder mehrere Schlüssellieferungen ergänzt.

Im Zuge der Planungsaktivitäten legen wir präzise, messbare, erreichbare, relevante und zeitgebundene (SMART) Unterziele fest, die uns zur Erreichung des Leitziels führen. Aus dem Umfangsstatement, das das Endprodukt des Projekts und die erforderliche Arbeit definiert, leiten wir funktionale Anforderungen und Qualitätsmerkmale für das Hauptlieferobjekt ab. Anschließend zerlegen wir den Projektumfang in Arbeitspakete, wobei wir besonderes Augenmerk auf die prioritär zu bearbeitenden legen. Jedes Arbeitspaket wird unter der Verantwortung eines benannten Arbeitspaketleiters detailliert ausgearbeitet, um die spezifischen Aktivitäten, Ressourcen und den Ressourcenbedarf zu definieren.

Mit diesen detaillierten Arbeitspaketen schätzten wir die erforderlichen Zeitaufwände und entwickelten einen detaillierten Zeitplan, der sich am groben Meilensteinplan des Projektauftrags orientiert. Der Zeitplan entstand in einem iterativen Prozess, in dem sukzessive Erkenntnisse aus verschiedenen Planungsbereichen integriert wurden.

Parallel dazu nutzten wir den Projektstrukturplan und die Zeitplanung, um eine Kostenschätzung für jedes Arbeitspaket vorzunehmen. Diese Schätzungen fassten wir in Kostenstellen und bei den jeweiligen Lieferobjekten zusammen, um einen umfassenden Kostenbasisplan zu erstellen. Dieser Prozess gewährleistet eine systematische Integration von Zielen, Anforderungen, Zeitplänen und Kosten, um eine solide Grundlage für die erfolgreiche Durchführung und Steuerung des Projekts zu schaffen.

Entwicklungsansatz und Lebenszyklus.

Für die Lösungsentwicklung haben wir einen spezifischen Ansatz gewählt, der verschiedene Phasen oder Iterationen umfasst – bekannt als der Lebenszyklus der Lösungsentwicklung. Dieser Ansatz trägt der Tatsache Rechnung, dass die einzelnen Komponenten des Projekts aufgrund ihrer spezifischen Merkmale unterschiedliche Entwicklungswege erfordern können. Für Komponenten, deren Anforderungen und Funktionsweisen klar definiert sind, verwenden wir einen vorhersagbaren Ansatz. Für jene Elemente des Projekts, deren vollständiges Verständnis sich erst im Laufe der Arbeit entwickelt, setzen wir, wenn technisch möglich und sinnvoll, einen iterativen oder inkrementellen Ansatz ein.

Stakeholder-Anforderungen und Projektsteuerung.

Zudem haben wir die Anforderungen bezüglich der Projektsteuerung von unseren Stakeholdern gesammelt. Diese Anforderungen sind essenziell für die Ausarbeitung der Hilfsmanagementpläne und gewährleisten, dass das Projektmanagement den Erwartungen der Stakeholder entspricht.

Integration zum umfassenden Projektmanagementplan.

In der finalen Phase der Planung integrieren wir alle Einzelteile in einen umfassenden, integrierten Projektmanagementplan. Dies beinhaltet die Verknüpfung des Arbeitsumfangs zur Erstellung des Endprodukts mit den entsprechenden Schätzungen für Aufwand, Zeitdauer und Kosten. Weiterhin koordinieren wir diese Elemente mit den erforderlichen Managementaktivitäten, einschließlich Kommunikation, Stakeholderengagement, Qualitätssicherung, Teamentwicklung, Beschaffungen und Risikomanagement, entsprechend den Anforderungen des Projekts, wie in den Hilfsmanagementplänen definiert.

Durch die Integration im Projektmanagementplan stellen wir sicher, dass alle Aspekte des Projekts harmonisiert werden, um eine effiziente und effektive Durchführung zu gewährleisten. Integration bedeutet, dass alle Elemente, seien es jene im Kommunikationsmanagementplan, in den Risikobewältigungsstrategien oder in den Arbeitspaketen des Projektstrukturplans, in den Basisplänen für Termine und Kosten berücksichtigt werden müssen. Der Projektmanagementplan muss alle einzelnen Planungselemente zu einem harmonisch integrierten Ganzen zusammenführen.

Sobald alle Elemente sinnvoll kombiniert und ausgewogen sind, sollte die Genehmigung des Lenkungsausschusses eingeholt werden. In den meisten Fällen sind dies der Sponsor und der Kunde des Projekts, sofern diese Rollen von verschiedenen Personen wahrgenommen werden.

Nach der Genehmigung werden die Projektinhalts- und Umfangsbeschreibungen sowie der Projektstrukturplan in den Inhalts- und Umfangsbasisplan integriert. Die geschätzten Termine und ihre Reserven bilden den Terminbasisplan, und die geschätzten Kosten den Kostenbasisplan. Zusammen bilden diese drei Basispläne den Fortschrittsmessungsbasisplan, der als die integrierte Projektleistungsmessungsbasis dient. Dieser Basisplan ist die offizielle und genehmigte Version dessen, was das Projekt liefern soll, wann und zu welchen Kosten. Die Projektleistungsmessungsbasis dient dabei als Grundlage für die Messung der Projektleistung.

Nach der Genehmigung des Projektmanagementplans informiert der Projektmanager die Stakeholder und plant möglicherweise eine weitere Kick-off-Sitzung, um den finalen Plan zu präsentieren und den Übergang von der Planung zur Ausführung zu markieren. Die Agenda dieser Sitzung orientiert sich an der ersten und konzentriert sich nun auf die entscheidenden Elemente des Projektmanagementplans, da der Start der Ausführungsaktivitäten bevorsteht.

Als dynamisches Dokument wird der Projektmanagementplan durchgehend genutzt und aktualisiert, um die Arbeit zu steuern, den Projektverlauf anzupassen und die Kommunikation mit den Stakeholdern zu gewährleisten. Es ist essenziell, dass insbesondere diejenigen Teammitglieder, die ihre Aufgaben als Erste aufnehmen, gut vorbereitet sind.

Der fertiggestellte und mitgeteilte Projektmanagementplan ist veränderbar und dynamisch. Nach der ersten Planung und Genehmigung starten wir mit der Ausführung der ersten Projektphase. In dieser Phase erfolgt eine kontinuierliche Überwachung und Steuerung des Fortschritts, wobei auf Abweichungen mit korrektiven und präventiven Maßnahmen reagiert wird. Am Ende jeder Phase bewerten wir die Ergebnisse und leiten bei Bedarf die nächste Phase ein, was die Initiierung neuer Aktivitäten und die detaillierte Planung dieser Phase beinhaltet. Diese fortlaufende Aktualisierung des Projektmanagementplans ist entscheidend für eine effektive Projektleitung und die Fähigkeit, auf Veränderungen einzugehen. Die Elemente des Projektmanagementplans, die zuvor erläutert wurden, sind das Fundament dieses Prozesses.

Zusammenfassung: es ist wichtig zu betonen, dass Planungsaktivitäten nicht nur zu Beginn für das Gesamtprojekt durchgeführt werden. Die Aktivitäten der Initiierung, Planung, Ausführung, Kontrolle und des Abschlusses bilden einen wiederkehrenden Zyklus, der sowohl das Gesamtprojekt als auch jede seiner Phasen umfasst und dadurch eine kontinuierliche Anpassung der Projektplanung an die Gegebenheiten des Projekts erlaubt. Diese Betrachtung einer dynamischen Planung zeigt, dass auch ein planorientierter Ansatz im Projektmanagement Raum für iterative und inkrementelle Elemente bietet.

 

 

3.1. Überblick der Projektausführungsaktivitäten

Dieser Abschnitt bietet einen Überblick über die notwendigen Management- und Führungstätigkeiten, um die im Projektmanagementplan enthaltenen Arbeiten umzusetzen.

 

Bis zu diesem Punkt haben wir bereits viel Zeit in die Planung des Projekts investiert und sind nun bereit, mit der Ausführung der Arbeiten zu beginnen. Für all jene, die lieber tun als planen, ist nun der große Moment gekommen, da sie endlich damit beginnen können, das Schlüssellieferobjekt zu erstellen. Was getan werden muss, ist im Projektmanagementplan erläutert. Natürlich nimmt die Erstellung des Hauptprodukts des Projekts den größten Teil des Budgets in Anspruch.

 

In den nächsten Abschnitten werden wir uns damit befassen, wie sowohl menschliche als auch Materialressourcen beschafft werden können, und beleuchten, welche Vertragstypen in verschiedenen Beschaffungssituationen am besten geeignet sind.

 

Außerdem werden wir den Prozess der Genehmigung von Arbeitspaketen untersuchen und erörtern, wie Teams effektiv geführt, gesteuert und weiterentwickelt werden können. Dies schließt Coaching-Techniken und verschiedene Methoden zur Einbindung von Stakeholdern mit ein.

 

Es wird dargelegt, wie Qualität sichergestellt und Änderungen, Korrekturmaßnahmen sowie Risikobewältigungsstrategien effektiv implementiert werden. Zudem wird aufgezeigt, wie Erkenntnisse aus dem Projektverlauf genutzt werden können, um Prozesse zu optimieren.

 

Folgen Sie aufmerksam den nächsten Lektionen, um mehr über das Management der Projektausführung zu erfahren.

 

3.2 Notwendige Ressourcen für das Projekt oder eine Phase beschaffen

In diesem Abschnitt stellen wir die Techniken und Werkzeuge vor, die zur Beschaffung der erforderlichen Ressourcen für die Realisierung des Projekts oder einer bestimmten Phase notwendig sind.

 

Ressourcen zu beschaffen bedeutet, die richtigen Ressourcen zum richtigen Zeitpunkt zu erhalten. Das heißt, Verantwortliche für Arbeitspakete, Teammitglieder sowie technische Ausrüstung, Raum, Rohstoffe und andere notwendige Elemente für die Durchführung der Arbeiten zu bekommen.

 

Bitte beachten Sie, dass die spezifischen Aspekte der Beschaffung durch den Kauf externer Ressourcen im Abschnitt zur Beschaffungssteuerung behandelt werden.

 

Das Versäumnis, die richtigen Ressourcen zu beschaffen oder dies nicht rechtzeitig zu tun, könnte sich negativ auf die Leistungsbasis auswirken und das Scheitern des Projekts zur Folge haben.

 

Um die Verantwortlichen für die Arbeitspakete und die passenden Teammitglieder zu gewinnen, muss der Projektleiter seinen Einfluss und seine Verhandlungsfähigkeiten gegenüber denjenigen einsetzen, die über diese Ressourcen verfügen.

 

Die Organisationsform ist für den Projekterfolg sehr wichtig. In großen Projekten mit einer projektorientierten Struktur werden die wichtigsten Ressourcen meistens vollzeit zugeordnet. Hier ist der Projektleiter die einzige Führungskraft über diese Ressourcen, was Konflikte um deren Nutzung mit Funktionsmanagern verhindert. Solche Konflikte sind häufiger in einer Matrixorganisation anzutreffen, besonders bei Teilzeitressourcen, die zusätzlich zu ihrer Projektarbeit in ihren regulären Funktionen tätig sind.

 

Allerdings sind auch in einer projektorientierten Organisation Verhandlungen um bestimmte Ressourcen unerlässlich. Dies betrifft die Gewinnung von Teilzeitpersonal für Aufgaben, die keine Vollzeitbeschäftigung erfordern, die Reservierung technischer Ausrüstungen oder Räumlichkeiten, sowie die Beschaffung externer Ressourcen durch Kauf, Leasing oder Miete.

 

Ein sorgfältig erstellter Projektmanagementplan ist die Basis für unsere Beschaffungsstrategien, basierend auf dem, was im Ressourcenmanagementplan festgelegt ist. Dieser detaillierte Plan legt fest, wie und wann Ressourcen beschafft werden sollen. Der Terminbasisplan gibt Auskunft über den Beginn und das Ende von Arbeitspaketen, und die Kostenbasisplan definiert die entsprechenden Budgets. Durch das Stakeholderregister wissen wir, welche Beteiligten einzubeziehen sind. Zusätzlich helfen ein Sponsor und ein klar definierter Problemmanagementprozess dabei, eventuelle Prioritätskonflikte mit Funktionsmanagern, die über die benötigten Ressourcen verfügen, effektiv zu bewältigen.

 

Beginnen wir mit einigen effektiven Techniken, um die für ein Projekt oder eine Phase erforderlichen Ressourcen zu beschaffen.

 

Vorabzuweisung ist unsere erste Technik. Dabei werden die Teammitglieder, die für spezifische Aufgaben zuständig sind, bereits vor dem Beginn der Ausführungsarbeiten festgelegt. Dies ist besonders wichtig, wenn spezielle Fähigkeiten oder eine bestimmte Kombination von Kompetenzen benötigt werden, die nur begrenzt verfügbar sind. In solchen Fällen können und sollten diese Ressourcen frühzeitig reserviert werden, unter Umständen schon während der Erstellung des Projektauftrags, insbesondere wenn das Projekt stark von diesen spezifischen Ressourcen abhängt.

 

Die zweite Technik ist der gezielte Einsatz zwischenmenschlicher Fähigkeiten, vor allem im Bereich der Verhandlungen. Um die benötigten Ressourcen für das Projekt zu sichern, ist es oft notwendig, Gespräche mit Funktionsverantwortlichen, anderen Projektteams sowie externen Organisationen, Lieferanten oder Subunternehmern zu führen. Die erfolgreiche Beschaffung dieser Ressourcen und damit der Erfolg des Projekts hängt maßgeblich von der Qualität dieser Verhandlungen ab.

 

Die dritte Technik betrifft den Einsatz virtueller Teams. Sie bieten die Möglichkeit, auf Ressourcen zuzugreifen, die vor Ort nicht verfügbar sind. Dank moderner Kollaborationstools können Teams auf Ressourcen zugreifen, die sonst außer Reichweite wären. Der erfolgreiche Einsatz solcher Fernkollaborationstools setzt jedoch eine sorgfältige Planung und Vorbereitung der Kommunikation voraus. Als praktisches Beispiel bietet dieser Projektmanagementkurs die Gelegenheit, einige effektive Tools für die Fernkollaboration kennenzulernen und zu nutzen.

 

Bei der Auswahl zwischen verschiedenen Kandidaten kann eine Multikriterien-Entscheidungsmatrix hilfreich sein, wie bereits in der Lektion zur Bewertung von Strategien besprochen. In dieser Matrix werden die Bewertungskriterien entsprechend ihrer Bedeutung gewichtet. Beispiele für solche Kriterien bei der Auswahl von Personalressourcen umfassen Verfügbarkeit, Kosten, Erfahrung, Fachkenntnisse, Einstellung und kulturelle Aspekte, unter anderen.

 

Das Ergebnis dieser Maßnahmen sollte die namentliche Zuweisung spezifischer Ressourcen, sowohl menschlicher als auch materieller Art, sein. Diese Zuweisung erfolgt entsprechend den Anforderungen der Arbeitspakete, den Terminen im Terminbasisplan und den Kosten, wie im Kostenbasisplan festgelegt.

 

 

Zusammengefasst umfassen Ressourcen sowohl menschliche als auch materielle Elemente, wie technische Ausrüstungen, Räumlichkeiten, Rohstoffe und andere für die Arbeit notwendige Komponenten. Diese Ressourcen können entweder im Voraus oder zu Beginn der spezifischen Ausführungsarbeiten zugewiesen werden. Der Ressourcenmanagementplan bietet dabei eine zentrale Richtschnur. Entscheidend in diesem Prozess sind die Fähigkeit, Stakeholder zu beeinflussen, und ausgeprägte Verhandlungskompetenzen. Zudem sind sorgfältige Planung und der Einsatz geeigneter Werkzeuge für die erfolgreiche Nutzung virtueller Teams unerlässlich.

 

 

 

 

 

3.3 Beschaffungen durchführen

In diesem Abschnitt widmen wir uns den verschiedenen Schritten der Beschaffung, beginnend mit dem Einholen von Angeboten von Lieferanten, über die Auswahl eines geeigneten Lieferanten bis hin zum Abschluss eines Vertrags für externe Ressourcen.

Für bestimmte Bestandteile Ihrer Lösung kann die Eigenfertigung die bevorzugte Wahl sein, während für andere der Zukauf vorteilhafter erscheint. Manchmal ist auch eine Kombination aus beidem sinnvoll. Die Entscheidungen darüber, was intern produziert und was extern beschafft wird, sind von zentraler Bedeutung und sollten frühzeitig im Projektverlauf getroffen werden. Der Grund dafür ist, dass der Beschaffungsprozess sich grundlegend von der internen Herstellung unterscheidet.

 

Während die Kosten bei der Entscheidung zwischen Herstellung und Kauf zweifellos eine wesentliche Rolle spielen, gibt es weitere Faktoren, die berücksichtigt werden müssen. Wollen Sie beispielsweise interne Ressourcen einsetzen? Wie genau möchten Sie den Fortschritt der Arbeiten überwachen? Ist der Schutz des geistigen Eigentums des Endergebnisses für Sie von Bedeutung? Verfügt Ihre Organisation über die erforderlichen Fähigkeiten und Kapazitäten, und falls ja, in welchem Umfang sind diese für das Projekt verfügbar? Zudem sollten Sie überlegen, ob die anstehenden Aufgaben zu den Kernkompetenzen Ihres Unternehmens gehören.

 

Bei der Entscheidung, ob Ausrüstungen und Einrichtungen gekauft oder gemietet werden sollen, müssen verschiedene Aspekte bedacht werden.

 

Dies ähnelt der Überlegung, ob es sinnvoller ist, ein Auto zu kaufen oder zu mieten, je nachdem, wie häufig und wie lange es genutzt wird. In der Regel ist der Kauf bei intensiver und langfristiger Nutzung vorzuziehen. Weitere wichtige Faktoren sind die anfänglichen Investitionskosten. Beim Kauf erscheint der Gegenstand als Vermögenswert in der Bilanz, und eventuelle Schulden aus der Finanzierung werden ebenfalls bilanziert. Bei Miete oder Leasing hingegen fließen die Zahlungen in die Kosten ein, ohne dass sich dies direkt auf die Vermögens- oder Schuldenposition in der Bilanz auswirkt.

 

Nach der Entscheidung, ob hergestellt, gekauft oder gemietet wird, folgt die Auswahl eines geeigneten Lieferanten. Dabei hilft die Anwendung einer Multikriterien-Entscheidungsmatrix. Zu den gewichteten Kriterien, die in Betracht gezogen werden sollten, gehören:

• Kosten,
• Technischer Ansatz,
• Projektmanagementfähigkeiten,
• Erfahrung in ähnlichen Projekten,
• Referenzen,
• Rechte an geistigem Eigentum.

 

Nachdem die Auswahlkriterien festgelegt sind, beginnt die Suche nach potenziellen Lieferanten, die den Anforderungen gerecht werden könnten. Eine erste Anlaufstelle bieten oft vorqualifizierte Lieferanten, die in der Vergangenheit bereits erfolgreich mit Ihrer Organisation zusammengearbeitet haben.

 

Sollten Sie sich auf die Suche nach neuen Lieferanten begeben müssen, bieten Gespräche mit anderen Unternehmen, Internetrecherchen und das Studium von Fachpublikationen im jeweiligen Wirtschaftszweig wertvolle Ansatzpunkte.

 

Sie beginnen damit, eine umfangreiche Liste potenzieller Lieferanten zusammenzustellen, um eine breite Palette interessanter Optionen zu berücksichtigen. Diese umfassende Anfangsliste lässt sich durch eine erste intuitive Bewertung auf eine überschaubarere Liste einschränken, indem Sie nach klaren Ausschlusskriterien für bestimmte Alternativen suchen.

 

Im Anschluss daran erfolgt die Verkleinerung der Liste auf eine engere Auswahl von Kandidaten. Dazu versenden Sie eine Aufforderung zur Angebotsabgabe an die verbliebenen Lieferanten auf Ihrer Liste und bewerten die eingehenden Angebote anhand der zuvor festgelegten gewichteten Kriterien.

 

Im nächsten Schritt des Prozesses besteht die Möglichkeit, Gespräche mit den Lieferanten zu führen oder ihre Betriebsstätten zu besuchen. Bei umfangreicheren Projekten ist es üblich, Lieferantenkonferenzen zu organisieren. So wird sichergestellt, dass alle potenziellen Anbieter dieselben Informationen erhalten und Fairness gewahrt bleibt.

 

Für jedes Bewertungskriterium vergeben Sie individuelle Punkte, die durch Multiplikation mit dem jeweiligen Gewicht des Kriteriums berechnet werden. Das Ergebnis ist eine Rangliste der Lieferanten, basierend auf einem ausgewogenen Kriterienkatalog.

In vielen Organisationen formuliert das Projektteam zunächst eine Empfehlung, woraufhin der Auswahlprozess an die für Beschaffung verantwortliche Abteilung weitergeleitet wird. Oft ist dies die Einkaufsabteilung. In einigen Fällen übernimmt der Projektmanager diese Rolle, insbesondere wenn spezielles technisches, rechtliches oder geschäftliches Fachwissen erforderlich ist. Ein wesentlicher Aspekt, besonders aus der Perspektive des Projektleiters, ist dabei sicherzustellen, dass die Wahl des Lieferanten nicht allein auf Basis des niedrigsten Preises erfolgt, sondern alle relevanten Auswahlkriterien berücksichtigt werden.

 

Zu diesem Zeitpunkt liegen normalerweise ausreichend Informationen vor, um eine fundierte Entscheidung zu treffen. Sie könnten damit beginnen, Vertragsverhandlungen mit dem potenziellen Lieferanten, der an erster Stelle Ihrer Bewertung steht, zu führen, bevor eine endgültige Entscheidung getroffen wird. Sollten die Verhandlungen mit dem erstplatzierten potenziellen Lieferanten nicht zum gewünschten Ergebnis führen, ist es möglich, Gespräche mit dem Lieferanten, der an zweiter Stelle steht, aufzunehmen. Dieser Ansatz wird so lange fortgesetzt, bis ein Lieferant gefunden ist, der nicht nur die Mindestanforderungen des Projektteams erfüllt, sondern mit dem auch eine vertragliche Einigung erzielt werden kann. Das Ergebnis sollte ein unterzeichneter Vertrag sein.

 

Bei der Auswahl von Verträgen ist es wichtig zu verstehen, dass nicht alle Verträge Festpreisverträge sein müssen. Es gibt drei grundlegende Arten von Verträgen: Festpreis-, Kostenrückerstattungs- und Zeit- und Materialverträge. Obwohl es Varianten innerhalb dieser Kategorien gibt, insbesondere im Hinblick auf Anreizsysteme, bilden diese drei die Grundpfeiler.

 

Jeder Vertragstyp bietet eine andere Verteilung des finanziellen Risikos zwischen Käufer und Verkäufer und ist je nach Projektumfang und spezifischen Anforderungen unterschiedlich gut geeignet. Im Folgenden werfen wir einen detaillierten Blick darauf, in welchen Situationen jeder Vertragstyp besonders vorteilhaft ist.

 

Festpreisverträge bieten eine klare Vereinbarung über Umfang, Qualität, Zeitplan und Preis der zu liefernden Waren oder Dienstleistungen. Der Umfang der Arbeit ist in der Regel präzise definiert, was zu vorhersehbaren Kosten führt. Die Hauptverantwortung für das Management der Arbeit liegt beim Lieferanten, während das Projektteam die Einhaltung von Qualität und Zeitplan überwacht. Ein möglicher Nachteil dieser Vertragsart ist, dass Lieferanten oft zusätzliche Kosten für unvorhergesehene Ereignisse einkalkulieren, um das Risiko zu minimieren, das sie tragen. Manchmal werden Varianten von Festpreisverträgen genutzt, die Anreize für das Einhalten von Zeitplan-Meilensteinen bieten.

 

Kostenrückerstattungsverträge erstatten dem Lieferanten die tatsächlich entstandenen, nachweisbaren Kosten für die erbrachte Leistung. Zu diesen Kosten kommen noch Gebühren hinzu, die den Gewinn des Lieferanten repräsentieren, oft basierend auf einem Prozentsatz der geschätzten Projektkosten. Diese Art von Vertrag ist besonders geeignet, wenn der Arbeitsumfang zu Vertragsbeginn nicht vollständig spezifiziert werden kann oder Änderungen im Laufe des Projekts erwartet werden. Der Lieferant trägt hierbei weniger Risiko und muss dementsprechend geringere Rücklagen für unvorhergesehene Ereignisse bilden. Um den Lieferanten dennoch zu effizientem Arbeiten und zur Einhaltung des Zeitplans zu motivieren, enthalten viele Kostenrückerstattungsverträge leistungsbezogene Anreize.

 

Zeit- und Materialverträge kommen häufig zum Einsatz, wenn es um die kurzfristige Aufstockung von Personal, die Einbindung spezialisierter Expertise oder sonstige externe Unterstützungen geht und der Arbeitsumfang nicht präzise im Voraus definiert werden kann. Bei dieser Vertragsform werden Kosten auf Basis der tatsächlich in Anspruch genommenen Zeit für die externe Ressource und der genutzten Materialien berechnet. In diesem Modell trägt das Projekt den Großteil der Risiken, während der Lieferant relativ geringe Rücklagen für unvorhergesehene Ereignisse vorhalten muss. Es liegt in der Verantwortung des Projektmanagementteams, sorgfältig zu überwachen, welche Leistungen während der vergüteten Zeit erbracht werden.

 

Die folgende Tabelle bietet einen Überblick über wichtige Aspekte, die in der Regel Teil eines Vertrags sind.

 

Ein abgeschlossener Vertrag kann die Notwendigkeit mit sich bringen, verschiedene Bestandteile des Projektmanagementplans zu aktualisieren. Dazu zählen unter anderem die Basispläne für Kosten, Termine, Inhalt und Umfang, sowie die Dokumentation der Anforderungen, das Stakeholderregister, die Risikobewältigungstrategien und der Kommunikationsplan.

 

Zusammenfassend ist es entscheidend:

• Frühzeitige Entscheidungen zu treffen, welche Teile des Projekts intern erstellt und welche zugekauft werden sollen.
• Bei der Auswahl eines Lieferanten eine gewichtete Multikriterien-Entscheidungsmatrix einzusetzen, um Angebote von einer ausgewählten Liste potenzieller Lieferanten zu bewerten, wobei mehrere Kriterien über den Preis hinaus berücksichtigt werden müssen.
• Die Wahl des Vertragstyps sorgfältig zu treffen, unter Berücksichtigung der Kostenvorhersehbarkeit und der Genauigkeit des definierten Arbeitsumfangs.
• Expertise aus verschiedenen Fachgebieten einzubeziehen, um eine fundierte Entscheidungsfindung zu gewährleisten.
• Den Beschaffungsmanagementplan klar zu definieren, inklusive des Auswahlprozesses und der Rolle des Projektmanagers.
• Zu erkennen, dass Anpassungen an verschiedenen Teilen des Projektmanagementplans aufgrund der Beschaffungsvorgänge nötig sein können.

 

 

 

 

 

 

3.4 Arbeitspakete autorisieren, delegieren, durchführen und genehmigen

Dieser Abschnitt konzentriert sich auf die Aktivitäten, die mit der Steuerung von Arbeitspaketen zusammenhängen, welche während der Planungsaktivitäten definiert und strukturiert wurden. Konsultieren Sie bei Bedarf erneut die Abschnitte zum Projektstrukturplan und zu den Arbeitspaketen.

Der Prozess, der die Autorisierung, Delegierung, Durchführung und Genehmigung von Arbeitspaketen umfasst, bildet eine entscheidende Schnittstelle zwischen dem Projektmanager und den Verantwortlichen für die Arbeitspakete.

• Aus der Perspektive des Projektmanagers liegt der Schwerpunkt auf der Autorisierung und Delegierung der Durchführung der Arbeitspakete sowie deren Genehmigung nach einem finalen Qualitätsbewertungsprozess.
• Aus der Perspektive des Leiters des Arbeitspakets liegt der Schwerpunkt auf der Annahme der Delegierung des Arbeitspakets und auf der Steuerung der Durchführungsarbeiten, einschließlich interner Tests durch das Entwicklungsteam. Der Leiter des Arbeitspakets ist auch verantwortlich für die Berichterstattung über den Fortschritt an den Projektmanager und für die Präsentation des fertiggestellten Arbeitspakets zur Genehmigung und Übergabe an den Projektmanager.

Arbeitspakete werden zunächst im Projektstrukturplan definiert. Von dort aus werden sie in den Terminplan für ihre Sequenzierung integriert, entweder als ganze Arbeitspakete oder aufgeschlüsselt in die sie bildenden Aktivitäten.

Jede Projektphase beinhaltet mindestens ein Arbeitspaket. Normalerweise bilden mehrere Arbeitspakete einen oder mehrere Liefergegenstände, die in einer Phase abgeschlossen werden müssen, und die Phase endet, wenn diese Phasenliefergegenstände abgeschlossen sind.

Arbeitspakete können sequenziell von einem Team oder parallel von verschiedenen Teams durchgeführt werden. Der detailliertere Terminplan für die aktuelle Phase dient als Referenzrahmen für die Sequenzierung. Der Projektmanager verwendet den Terminplan, um zu bestimmen, wann jedes Arbeitspaket beginnen und enden soll.

Jedes Arbeitspaket muss seine eigene Definition und Planung haben. Der Leiter des Entwicklungsteams des Arbeitspakets ist verantwortlich für die detaillierte Planung des Arbeitspakets, unter Einbeziehung der Erfahrung der Teammitglieder. Anschließend koordiniert er die Durchführung der Arbeit des Teams von Spezialisten, die das im Arbeitspaket beschriebene Produkt erstellen.

In vielen Fällen bildet der Leiter des Arbeitspakets das Team von Spezialisten mit Personen aus seiner eigenen Organisation. Dies geschieht, wenn der Leiter des Arbeitspakets Teil einer externen Organisation ist. Es kann jedoch auch vorkommen, dass ein Funktionsmanager desselben Unternehmens wie der Projektmanager die Rolle des Arbeitspaketleiters übernimmt und ein von ihm geleitetes Team bildet, um das angeforderte Produkt zu liefern. Diese Anordnung hilft, Konflikte zu vermeiden, die aus der Matrixorganisation resultieren, in der ein Projektmanager die Arbeit überwacht, die von Mitarbeitern einer von einer anderen Person geleiteten Abteilung durchgeführt wird.

Der Formalitätsgrad in der Definition des Arbeitspakets kann variieren, abhängig davon, ob das Spezialistenteam intern zur Organisation gehört oder ob das Arbeitspaket an einen Subunternehmer ausgelagert wurde. Im letzteren Fall kann die Definition des Arbeitspakets Teil eines Vertrags mit diesem Subunternehmer sein.

Autorisierung, Delegierung und Durchführung eines Arbeitspakets.

Die Autorisierung und Delegierung eines Arbeitspakets liegen in der Verantwortung des Projektmanagers. Die Annahme der Delegierung zur Durchführung eines Arbeitspakets obliegt dem Arbeitspaketleiter, der als Teamleiter fungiert.

Der Projektmanager autorisiert zum richtigen Zeitpunkt und stimmt mit dem entsprechenden Arbeitspaketleiter den Beginn jedes Arbeitspakets ab. Bitte konsultieren Sie bei Bedarf die Inhalte über die Beschaffung von Ressourcen und Lieferungen. Diese Prozesse erläutern, wie Spezialisten und Teamleiter für die erforderlichen Arbeitspakete zur Fertigstellung der Liefergegenstände beschafft werden können.

Die Informationen in der Arbeitspaketdefinition klären, welche Produkte produziert werden müssen, welche Akzeptanzkriterien gelten, welche Arbeiten durchgeführt werden müssen sowie die geschätzten Kosten und den Terminplan.

• Der Projektmanager ist für das Management der Schnittstellen zwischen den verschiedenen Arbeitspaketen verantwortlich.
• Der Teamleiter trägt die Verantwortung für die Durchführung des ihm delegierten und akzeptierten Arbeitspakets

Um ein Produkt als abgeschlossen zu betrachten, erfolgt dies in drei Stufen:

• Erste Stufe: Das Entwicklungsteam des Arbeitspakets erstellt das Produkt gemäß den in der Arbeitspaketdefinition festgelegten Akzeptanzkriterien.
• Zweite Stufe: Das Team des Arbeitspakets führt eine interne Qualitätsbewertung des Produkts durch, bevor es außerhalb des Entwicklungsteams zur Annahme präsentiert wird.
• Dritte Stufe: Diese Stufe beinhaltet eine formelle Präsentation zur Genehmigung durch den Projektmanager. Abhängig vom Produkt kann der Projektmanager einen Fachspezialisten für technische Unterstützung während dieser Bewertung zur Produktgenehmigung anfordern.

Während der Durchführung eines Arbeitspakets ist es ebenso wichtig, regelmäßig präzise Informationen über den Fortschritt an den Projektmanager zu kommunizieren. Dies wird durch regelmäßige Berichterstattung des Arbeitspaketleiters an den Projektmanager erreicht. Die Arbeitspaketdefinition legt fest, wie und wie oft Fortschrittsberichte erstellt werden. Der Projektmanager fungiert auch als Eskalationsinstanz für den Arbeitspaketleiter bei Problemen und Änderungsanfragen. Ein Schlüsselaspekt, den das Team des Arbeitspakets verstehen muss, ist, dass ihr Arbeitspaket Teil eines größeren Produkts ist, für das der Projektmanager verantwortlich ist.

Genehmigung eines Arbeitspakets.

Bei einer Besprechung zur Genehmigung eines Arbeitspakets nehmen mindestens zwei Personen teil. Eine Person fungiert als Vorsitzender und übernimmt die Rolle des Prüfers. Diese Rolle kann vom Projektmanager übernommen werden. Abhängig vom zu überprüfenden Produkt kann der Projektmanager Unterstützung von einer technischen Support-Person erhalten.

Die andere Person ist der Leiter des Arbeitspakets, der als Präsentator agiert und entweder eigene Notizen macht oder von einer administrativen Support-Person unterstützt wird. Der Prüfer untersucht das Produkt im Hinblick auf die in der Arbeitspaketdefinition festgelegten Akzeptanzkriterien.

Es werden Nachweise der Übereinstimmung mit den Akzeptanzkriterien verlangt, die vom Präsentator vorgelegt werden. Fragen werden gestellt und beantwortet. Eventuell notwendige Aktionen werden vereinbart und protokolliert.

Das Ergebnis der Qualitätsprüfung kann sein:

• Das Produkt ist korrekt und vollständig und wird daher akzeptiert.
• Das Produkt ist fast korrekt und vollständig und wird bedingt akzeptiert. Dies bedeutet, dass noch einige Aktionen erforderlich sind, die protokolliert werden, aber eine zweite Qualitätsprüfungssitzung ist nicht notwendig.
• Das dritte mögliche Ergebnis ist, dass das Produkt nicht korrekt oder vollständig ist, abgelehnt wird und zur Überarbeitung zurückgesandt wird. Eine weitere Qualitätsprüfung wird erforderlich sein.

Für Produkte, bei denen der Projektmanager die Rolle des Arbeitspaketleiters übernimmt und selbst die Arbeit des Entwicklungsteams leitet, muss eine andere Person, die nicht am Entwicklungsprozess beteiligt ist, die Rolle des Prüfers übernehmen. Abhängig von der Art des Arbeitspakets, insbesondere wenn es von einem externen Anbieter durchgeführt wird, kann eine zweite Genehmigungsinstanz erforderlich sein, wenn dies im Vertrag vorgesehen ist. In Agile-Projekten oder -Komponenten wird die endgültige Genehmigung vom Produktbesitzer vorgenommen.

Zusammenfassend:

• Der Prozess der Autorisierung, Delegierung, Durchführung und Genehmigung von Arbeitspaketen fungiert als Bindeglied zwischen dem Projektmanager und den Verantwortlichen für die Arbeitspakete.
• Aus Sicht des Projektmanagers liegt die Verantwortung darin, die Durchführung der Arbeitspakete zu autorisieren und zu delegieren sowie deren Genehmigung nach den entsprechenden finalen Qualitätsbewertungsprozessen zu gewährleisten.
• Aus Sicht des Arbeitspaketleiters liegt die Verantwortung darin, die Delegierung des Arbeitspakets anzunehmen, die Durchführungsarbeiten zu steuern, einschließlich interner Tests des Entwicklungsteams. Der Arbeitspaketleiter ist auch dafür verantwortlich, den Fortschritt an den Projektmanager zu berichten und das vollständige Arbeitspaket zur endgültigen Genehmigung und Übergabe vorzustellen.
  

3.5 Das Projektteam führen und managen

Das Wort “Führung” kann eine Vielzahl von Bildern hervorrufen, wie einen Politiker, einen Entdecker, einen Geschäftsführer, einen Kämpfer, einen Menschenrechtsaktivisten und andere. Führung hat für verschiedene Menschen auf der ganzen Welt unterschiedliche Bedeutungen. Zum Beispiel assoziieren viele Menschen einen positiven Wert mit einem Anführer, aber das deutsche Wort für Führer, “der Führer”, ruft negative Konnotationen hervor.

Dieser Abschnitt konzentriert sich auf die “individuelle Führung” und befasst sich mit Führung am Arbeitsplatz statt in anderen Bereichen. Es gibt viele Definitionen von “Führung”.

• Peter Drucker, einer der Väter des modernen Managements, sagt: “Ein Führer ist jemand, der Anhänger hat”. Ohne Anhänger gibt es keinen Führer. Aber ist das nicht ein bisschen zu simpel? Ist das nicht eine Tautologie?
• Warren Bennis, ein Experte für Führung und Berater mehrerer US-Präsidenten, definiert es als: “Die Fähigkeit, eine Vision in Realität umzusetzen”. Führung ist mit dem Wandel des Status quo verbunden, aber wo bleiben „die anderen“ in dieser Definition?
• Bill Gates definiert Führer als: “Diejenigen, die andere ermächtigen”. Und ja, „diese anderen“ sind notwendig, wenn es Führung geben soll, aber sollten wir mit dieser Ermächtigung nicht etwas erreichen?
• Dwight D. Eisenhower, Oberkommandierender der Alliierten Streitkräfte in Europa während des Zweiten Weltkriegs und späterer Präsident der Vereinigten Staaten, gibt folgende Definition: “Führung ist die Kunst, jemanden dazu zu bringen, das zu tun, was du willst, weil er es tun will”. Eine bemerkenswerte Definition eines Fünf-Sterne-Generals, der zu dem Schluss kommt, dass Führung letztendlich auf freiwilligen Anhängern beruht.

Es gibt verschiedene Klassifizierungen von Führungsstilen, wobei die klassischsten in den 1930er Jahren entwickelt wurden und Kategorien wie den partizipativen Stil, den autokratischen Stil und den laissez-faire-Stil verwenden. Neuere Kategorien sind der dienende Führung und der transformative Führungsstil.

• Ein partizipativer Stil beinhaltet die Mitwirkung anderer und führt zu Entscheidungen, die verschiedene Standpunkte widerspiegeln.
• Ein autokratischer Stil besteht auf der Notwendigkeit, alle nicht nur über die zu erreichenden Ziele zu informieren, sondern auch darüber, wie sie erreicht werden sollen.
• Der Laissez-faire-Stil ist ein lockererer Ansatz, der es Teams erlaubt, ihre eigenen kreativen Strategien zu erkunden.
• Dienende Führung bezieht sich auf selbstverwaltete Teams, wobei die Rolle des Führers darin besteht, Hindernisse für das Team zu beseitigen.
• Ein transformativer Führungsstil konzentriert sich darauf, Veränderungen anzustoßen zu inspirieren und motivieren, ethische Werte zu fördern, klare Regeln aufzustellen, das Gemeinwohl zu berücksichtigen, offene Kommunikation zu ermöglichen, Coaching anzubieten und Verantwortung zu übernehmen.

Von der Perspektive eines Projektmanagers aus betrachtet, besteht eine grundlegende Herausforderung darin, ein Team von Experten zu führen und zu leiten, die möglicherweise über technisch fortgeschrittenere Fähigkeiten in dem Thema verfügen als der Projektmanager selbst.

Das zweite Szenario besteht darin, ein Team von Teamleitern zu führen, von denen einige möglicherweise in der funktionalen Organisation einen höheren hierarchischen Rang haben als der Projektmanager selbst. Diese Teamleiter können auch externe Partner sein, wie beispielsweise Lieferanten. Obwohl sie in ihrer eigenen Organisation leitende Positionen innehaben können, fungieren sie im Projekt als Leiter von Arbeitspaketen und sind daher dem Projektmanager gegenüber verantwortlich.

Daher kann die Führungsrolle eines Projektmanagers nicht ausschließlich auf positioneller Legitimität beruhen, obwohl die Projektauftrag den Projektmanager benennt und ermächtigt, das Team zu führen und die Projektarbeiten zu leiten.

Welche Machtquellen stehen also einem Projektmanager oder jeder anderen Rolle oder Position in einer Organisation zur Verfügung?

Soziologisch betrachtet ist Macht als die Fähigkeit einer Person oder Gruppe, die Handlungen, Überzeugungen oder Entscheidungen anderer Individuen oder Gruppen zu beeinflussen. Die Machtquellen sind die Ressourcen oder Merkmale, die es jemandem ermöglichen, Einfluss auf andere auszuüben. Die bekanntesten Arten von Macht oder Machtquellen sind die folgenden:

• Positionelle Macht: Auch als formelle Macht oder Autoritätsmacht bekannt, leitet sie sich aus der hierarchischen Position oder der Rolle ab, die jemand in einer organisatorischen Struktur einnimmt. Diese Machtquelle basiert auf der Wahrnehmung, dass Personen in bestimmten Positionen das Recht haben, Befehle zu erteilen und Entscheidungen zu treffen, die befolgt werden müssen.
• Belohnungsmacht: Bezieht sich auf die Fähigkeit einer Person, andere für die Erfüllung ihrer Forderungen oder Wünsche zu belohnen. Diese Belohnungen können materiell sein, wie Gehaltserhöhungen oder Beförderungen, oder immateriell, wie öffentliche Anerkennung oder Zustimmung.
• Zwangsmacht: Diese Art von Macht basiert auf der Fähigkeit, Strafen oder negative Konsequenzen anzuwenden, um das Verhalten anderer zu beeinflussen. Personen mit Zwangsmacht können Drohungen oder Sanktionen verwenden, um Konformität zu erreichen.
• Referenzmacht: Entsteht aus der Bewunderung, dem Respekt oder dem Wunsch, eine Person oder Gruppe nachzuahmen. Diejenigen, die Referenzmacht besitzen, üben Einfluss aus, weil andere sich mit ihnen identifizieren und sich ihre Zustimmung verdienen wollen.
• Expertenmacht: Diese Art von Macht basiert auf dem Wissen, der Erfahrung oder der spezialisierten Fähigkeit einer Person. Diejenigen, die als Experten in einem bestimmten Bereich angesehen werden, können andere durch ihre Kompetenz und Fähigkeit zur Problemlösung beeinflussen.

Der Einsatz dieser Machtquellen ist nicht gegenseitig ausschließend und überschneidet sich oft innerhalb eines Projekts. Zum Beispiel verleiht der Projektauftrag dem Projektmanager eine gewisse positionelle Macht. Durch den Projektmanagementplan kann ein Bonussystem eingeführt werden, das die Belohnungsmacht des Projektmanagers stärkt. Die Abschlussprozesse der Phase bieten Möglichkeiten zur Leistungsbewertung, was sowohl die Belohnungs- als auch die Zwangsmacht erhöht. Wenn der Projektmanager über eine professionelle Zertifizierung im Projektmanagement verfügt und einen guten Ruf durch die erfolgreiche Leitung zahlreicher früherer Projekte genießt, verleiht ihm dies ein hohes Maß an Experten- und Referenzmacht.

Die modernste Kategorie des transformativen Führungsstils basiert auf dem charismatischen Element der Referenzmacht und beinhaltet die Fähigkeit, “eine Vision der Zukunft zu vermitteln”, “die Fähigkeit zu motivieren” und Menschen zu inspirieren sowie andere zu coachen.

Eine Vision der Zukunft vermitteln.

Im Bereich des Projektmanagements ist es äußerst effektiv, eine Vision für die Zukunft zu entwickeln und zu kommunizieren, indem man die zu Beginn des Projekts festgelegten Ziel- und Zweckerklärungen nutzt. Diese Aussagen vermitteln allen eine klare Vorstellung davon, was wir zu erreichen versuchen und warum. In wenigen Sätzen bieten sie einen Überblick über das Problem, dem wir entgegentreten möchten oder dessen Lösung wir anstreben, und vermitteln eine Vision für die Zukunft.

Ihr Projekt könnte beispielsweise eine Fischfarm, ein Seminarzentrum oder ein System zur Handhabung eingehender Telefonanrufe schaffen. Während bestimmte Personen durch diese Schlüsselliefergegenstände motiviert werden könnten, könnten andere eine größere Motivation verspüren, wenn sie darüber informiert werden, dass ihr Beitrag zur Bekämpfung der Armut, zur Verhinderung des Missbrauchs von Mädchen, zur Steigerung der Kundenbindung und somit zur Verbesserung der finanziellen Ergebnisse, zur Sicherung von Arbeitsplätzen und zur Erhöhung der Gehälter beitragen.

Es gibt eine bekannte Geschichte über den Wiederaufbau der St. Paul’s Kathedrale in London im 17. Jahrhundert. Der Architekt Christopher Wren beobachtete drei Maurer, die mit unterschiedlicher Intensität arbeiteten: einer arbeitete langsam, ein anderer mit moderatem Tempo und ein dritter schnell und fleißig. Als Christopher Wren sie fragte, was sie taten, antwortete der erste Maurer: “Ich bin Maurer und arbeite, um meine Familie zu ernähren”. Der zweite Maurer antwortete: “Ich bin ein Maurer und baue eine Mauer”. Der dritte Maurer antwortete mit Stolz: “Ich bin ein Kathedralenbauer. Ich baue die große Kathedrale von St. Paul wieder auf”. Es ist offensichtlich, dass der Dritte, aufgrund seiner Zukunftsvision zum Teamleiter der Maurer wurde.

Motivieren.

Eine überzeugende Vision bildet das Fundament der Führung. Jedoch ist es die Fähigkeit der Führer, Menschen zu motivieren und zu inspirieren, die ihnen hilft, diese Vision in die Realität umzusetzen.

Belohnungen stellen einen leistungsstarken Motivationsfaktor dar. Dabei muss es nicht zwangsläufig um Geld gehen. Tatsächlich weist die Forschung auf verschiedene negative Nebeneffekte von Geld als Motivationsfaktor hin. Belohnungen können auch in Form von Anerkennung erfolgen, sei es materiell oder emotional, oder sie können eine Hoffnung wecken, die sich in Zukunft materialisieren wird.

Ein Projektmanager, der über Glaubwürdigkeit und Charisma verfügt, findet es leichter, seine Teammitglieder zu motivieren und zu inspirieren.

Es gibt zahlreiche Möglichkeiten, ein Team zu motivieren oder zu demotivieren, wobei die Klare Kommunikation von Rollen und Verantwortlichkeiten eine wichtige Rolle spielt. Hierbei nutzen wir Organigramme zur Veranschaulichung, definieren und delegieren Arbeitspakete und erläutern diese ausführlich während der Auftaktbesprechungen.

Eine weitere Gelegenheit, das Team zu motivieren, besteht darin, ambitionierte, aber erreichbare Ziele festzulegen. Ambitionierte, jedoch realistische Ziele und Vorgaben wirken motivierend. Zu ehrgeizige und damit unerreichbare Ziele können hingegen demotivierend wirken.

Die Motivation kann auch durch andere Mittel erreicht werden, wie beispielsweise durch die Bereitstellung schneller und präziser Rückmeldungen sowie durch den Respekt gegenüber anderen. Dabei ist nicht nur wichtig, was man sagt, sondern auch, wie man es sagt. Ein wichtiger Aspekt ist auch die Zugänglichkeit und die Fähigkeit, die eigenen Schwächen und Fehler anzuerkennen. Des Weiteren spielt es eine Rolle, immer die Wahrheit zu sagen, transparent zu kommunizieren und Probleme rasch zu lösen. Die meisten dieser Eigenschaften wahrer Führungspersönlichkeiten tragen zur Entwicklung von Vertrauen bei, einem entscheidenden immateriellen Vermögenswert, der zwar langsam aufgebaut wird, aber schnell verloren gehen kann. Ohne Vertrauen kann es keine effektive Führung geben.

Interkulturelle Aspekte spielen eine entscheidende Rolle, wenn es darum geht, Teams zu führen. Die Anforderungen und Erwartungen an einen Führer variieren je nach kulturellem Hintergrund des Teams. Ein japanisches Team erwartet möglicherweise ein anderes Führungsverhalten als ein brasilianisches Team. Ähnlich werden in französischen oder niederländischen Umgebungen unterschiedliche Verhaltensweisen von einem Führer erwartet.

In den kommenden Abschnitten werden wir zwei weitere wichtige Aspekte der Teammotivation genauer betrachten: Kommunikation, die im Abschnitt “Kommunikations- und Stakeholder-Management” behandelt wird, und Coaching, das Teil des Abschnitts “Team-Entwicklung” ist.

Führung im Vergleich zu Management.

In diesem Abschnitt, betitelt mit “Das Projektteam führen und managen“, lag unser Fokus bisher auf dem Aspekt der Führung. Diese Funktion wird sowohl vom Projektmanager als auch vom Projektsponsor wahrgenommen. Jedoch sind ebenso technische Kompetenzen im Management und in der Leitung von Prozessen und beteiligten Personen unerlässlich, um das angestrebte Ziel zu erreichen.

Was beinhalten diese Managementaufgaben genau?

Managementaufgaben in einem Projekt umfassen die Prozesse und Aktivitäten, die für die Initiierung, Planung, Durchführung, Überwachung, Steuerung und den erfolgreichen Abschluss eines Projekts, jeder seiner Phasen und aller einzelnen Arbeitspakete notwendig sind. Diese wurden im Verlauf dieses Kurses ausführlich erläutert. Die einleitende Lektion bietet eine kompakte Zusammenfassung all dieser Punkte. Bei Bedarf sollten Sie diesen Abschnitt zur Auffrischung heranziehen.

Zusammenfassend sei angemerkt, dass Führen und Management keineswegs gleichzusetzen sind.

• Führung im Team bedeutet, die Kunst zu beherrschen, bei anderen den Wunsch zu entfachen, das Notwendige aus eigenem Antrieb zu vollbringen. Diese Fähigkeit beruht auf zwischenmenschlichen Kompetenzen, oft auch als Soft Skills bezeichnet.
• Managementaufgaben hingegen konzentrieren sich darauf, konkret zu identifizieren, welcher Teil eines Problems angegangen werden soll. Es geht darum festzulegen, wie wir zur Lösung gelangen, einen entsprechenden Aktionsplan zu entwickeln, diesen umzusetzen und fortlaufend anzupassen – und das alles Schritt für Schritt. Diese technischen Fähigkeiten im Bereich Management werden im Rahmen dieses Kurses näher beleuchtet.

 

 

 

3.6 Das Projektteam entwickeln

In diesem Abschnitt wird erörtert, wie die Entwicklung eines Teams durch unterschiedliche Stadien gefördert werden kann, um Kompetenzen, Interaktionen und das Gesamtklima innerhalb des Teams zu verbessern. Dies trägt maßgeblich zur Steigerung der Projektleistung bei.

Teams durchleben diverse Entwicklungsphasen, bevor sie ihre volle Produktivität erreichen. Das von Bruce Tuckman in den 1960er Jahren formulierte Modell skizziert diese typischen Phasen: Forming (Orientierung), Storming (Konflikt), Norming (Normierung), Performing (Leistung) und Adjourning (Abschied).

• Orientierungsphase: In dieser Anfangsphase formieren sich die Teammitglieder zu einer Gruppe.
• Konfliktphase: Zu Beginn der Zusammenarbeit können Konflikte und Spannungen zwischen den Teammitgliedern entstehen.
• Normierungsphase: Die Teammitglieder beginnen, ihre Differenzen beizulegen und die Stärken jedes Einzelnen wertzuschätzen.
• Leistungsphase: Nicht jedes Teams erreichen diese Stufe. Die Teams, die sie erreichen, arbeiten jedoch hoch effizient: Die Aufgabenverteilung ist klar, und die Mitglieder folgen etablierten Prozessen mit minimaler Intervention durch den Projektmanager, der nur bei Bedarf eingreift.
• Abschiedsphase: Diese tritt ein, wenn das Projekt (oder eine Phase) abgeschlossen ist, das Team aufgelöst und die Mitglieder neuen Aufgaben zugeteilt werden.

Der Entwicklungsprozess eines Teams verläuft nicht immer geradlinig. Es ist möglich, dass Teams in frühere Phasen zurückfallen. Beispielsweise kann eine strategische Neuausrichtung des Unternehmens zu neuen Zielen, Aufgabenstellungen, Rollenverteilungen oder der Integration neuer Teammitglieder führen, was wiederum die etablierte Dynamik innerhalb des Teams beeinflussen kann. Im Folgenden werden die verschiedenen Phasen näher betrachtet und die Bedeutung der Führungsrolle in jedem dieser Abschnitte reflektiert.

Die Orientierungsphase.

In der Orientierungsphase ist es entscheidend, klare Ziele für das Team festzulegen. Dazu können bestehende Projektdokumente herangezogen werden. Das anfängliche Team, oft als Basisteam bezeichnet, ist in der Regel für die Erstellung des Projektmanagementplans verantwortlich. Ein zentrales Dokument in dieser Frühphase ist der Projektauftrag.

Für jedes Team, das in den nachfolgenden Phasen gebildet wird, sind der Projektmanagementplan, die detaillierte Planung der jeweiligen Phase und die Definition der einzelnen Arbeitspakete die Schlüsseldokumente, wobei letztere besonders spezifisch für jedes Team ausgearbeitet werden.

Viele Aspekte, die für die Erstellung von “Teamstatuten” erforderlich sind, lassen sich bereits in diesen Dokumenten finden: Kontext, Haupt- und Nebenziele, Teamzusammensetzung, Rollenverteilung, geplante Aktivitäten, Berichtswesen und Ressourcen. Eine ausdrückliche Einigung über die Werte des Teams ist jedoch unerlässlich, da diese in keinem anderen Projektmanagementdokument verankert sind und von Team zu Team variieren können.

Hier sind einige Beispiele für Teamwerte, die während der Orientierungsphase etabliert werden können:

• Wir schieben Aufgaben nicht auf, die heute erledigt werden können, und kommunizieren regelmäßig und rechtzeitig unseren Fortschritt.
• Wir stützen uns auf möglichst wenige Annahmen und bevorzugen es, Entscheidungen auf der Basis von Daten und Fakten zu treffen.
• Wir respektieren während Diskussionen das Rederecht jedes Einzelnen und werten unterschiedliche Perspektiven als Bereicherung.
• Jedes Teammitglied wird ermutigt, seine Meinung zu äußern. Schweigen gilt nicht als Zustimmung oder Ablehnung.
• Bei Problemen suchen wir nicht nach Schuldigen oder Ausreden, sondern bemühen uns, die Ursachen zu analysieren und konstruktive Lösungen zu finden.

Diese Beispiele illustrieren lediglich mögliche Werte, die ein Team für seine Grundsätze in Betracht ziehen könnte. Jedes Team sollte seine eigenen, spezifischen Werte entwickeln, die als Leitfaden für die Zusammenarbeit dienen.

Eine zusätzliche Verantwortung, die Führungskräfte in dieser Phase übernehmen können, besteht darin, den Teammitgliedern zu helfen, ihre individuellen Ziele zu definieren und zu teilen. Dabei sollten sie aufzeigen, wie die Mitwirkung am Projekt dazu beitragen kann, diese persönlichen Ziele zu erreichen.

In der Orientierungsphase des Teams ist es für die Führungskraft besonders wichtig, Gelegenheiten zu schaffen, bei denen sich die Teammitglieder (neu) kennenlernen können. Ein gemeinsames Mittag- oder Abendessen oder Teambuilding-Aktivitäten an einem extra dafür vorgesehenen Tag sind hervorragende Möglichkeiten, um das gegenseitige Verständnis und den Zusammenhalt im Team zu fördern. Bei Teams, die an verschiedenen Standorten arbeiten, können virtuelle Integrationsübungen dabei helfen, ein starkes Gemeinschaftsgefühl zu entwickeln und die Verbundenheit mit den Projektzielen zu stärken. Mehr zu diesem Thema wird in späteren Abschnitten behandelt.

Die Konfliktphase.

In der Konfliktphase- oder Turbulenzphase entwickeln die Teammitglieder ihre zwischenmenschlichen Beziehungen weiter, was häufig zu Machtkämpfen führen kann.

Teams, die sich in dieser Phase befinden, haben oft Schwierigkeiten, Fortschritte zu machen und Entscheidungen zu treffen, da Meinungsverschiedenheiten auftreten. Die positive Seite dieser Konflikte ist jedoch, dass sie zu Kommunikation führen und Chancen für das Wachstum des Teams bieten.

Während sich ein Team in der Konfliktphase befindet, ist es wichtig, dass der Projektleiter Unterstützung in Form von Coaching bietet und seine zwischenmenschlichen Fähigkeiten einsetzt.

Nun ein Blick auf das informelle Coaching: Obwohl ein Projektleiter in der Regel kein offiziell zertifizierter Coach ist – ein Beruf für sich –, kann er dennoch ein gewisses Maß an informellem Coaching anbieten. Es ist wichtig, die beiden Rollen – die des Projektleiters und die des Coaches – klar voneinander abzugrenzen. Wenn Sie Ratschläge oder Anweisungen geben, sollte dies nicht als “Coaching” bezeichnet werden. Generell gilt: Wenn Sie häufig “Ich denke” sagen, handelt es sich wahrscheinlich nicht um ein Coachinggespräch. Als Coach sollten Sie eher Fragen stellen und das Gesagte zusammenfassen, statt Ihre eigene Sicht der Dinge darzulegen. Diese Art des Zuhörens wird als “aktives Zuhören” bezeichnet und ist eine Schlüsselkomponente des Coachings.

Wie aber erkennt man Situationen, die eine Coaching-Sitzung erfordern könnten? Hier einige Anhaltspunkte:

• Nehmen Sie sich Zeit, um die aktuelle und zukünftige Arbeitsbelastung der Teammitglieder zu untersuchen. Oft ist den Betroffenen selbst nicht bewusst, dass sie überlastet sind oder unter Stress stehen.
• Mit Übung können wir lernen, sensibler für die Gefühle anderer zu sein und Veränderungen in Verhalten und Körpersprache wahrzunehmen.
• Seien Sie besonders aufmerksam, wenn Teammitglieder sich auf eine bedeutende oder herausfordernde Aufgabe vorbereiten.
• Ein klassischer Anlass für Coaching ist, wenn ein Teammitglied während eines Meetings kritische Rückmeldungen erhält.

Bieten Sie Coaching an, aber drängen Sie es niemandem auf. Es kann sein, dass Sie eine ideale Gelegenheit für ein informelles Coaching-Gespräch erkennen, doch für die betroffene Person ist vielleicht gerade nicht der richtige Zeitpunkt. Es empfiehlt sich daher, nachzufragen, ob es gerade passt, sich einige Minuten Zeit für ein Coaching-Gespräch zu nehmen.

Eine Mini-Coaching-Sitzung kann in einem formellen Rahmen stattfinden, aber auch in einer informellen Situation, wie etwa während einer Kaffeepause, am Ende eines Meetings oder auf einer gemeinsamen Reise. Das Wesen des informellen Coachings sollte spontan, wirkungsvoll und professionell sein.

Ein Beispiel für ein informelles Coaching-Gespräch könnte folgendermaßen aussehen:

• Sie: “Ich habe bemerkt, dass Sie mit der Situation etwas zu kämpfen hatten. Es geht mir nicht um die Details, sondern eher darum, wie Sie sich dabei gefühlt haben. Vielleicht könnten wir bei einem Kaffee darüber sprechen?”
• Teammitglied: “Wenn Sie glauben, dass es helfen könnte…”
• Sie: “Ich denke, es ist einen Versuch wert, besonders wenn Sie glauben, dass es Ihnen helfen könnte, darüber zu sprechen.”
• Teammitglied: “Nun…” (Das Teammitglied beginnt, den Konflikt zu erklären.)
• Sie: “Ich verstehe. Wie haben Sie sich in dieser Situation gefühlt?”
• Teammitglied: (Das Teammitglied teilt seine Gefühle mit.)
• Sie: “Was denken Sie, wie könnten Sie darauf reagieren oder was möchten Sie dagegen unternehmen?”
• Teammitglied: (Das Teammitglied äußert seine Absichten oder mögliche Lösungsansätze.)
• Sie: “Lassen Sie mich bitte sicherstellen, dass ich alles richtig verstanden habe. Sie sagen also, dass…” (Sie fassen zusammen, was Sie verstanden haben.)
• Teammitglied: “Nein, nein, ich meinte eher…” (Das Teammitglied klärt oder korrigiert.)
• Sie: “Ach so, jetzt verstehe ich. Sie möchten also…” (Sie wiederholen das korrigierte Verständnis.) “Sehen Sie noch andere mögliche Wege oder Optionen?”
• (Das Gespräch setzt sich fort mit weiteren Fragen und aktivem Zuhören. Es könnte schließlich enden mit:)
• Sie: “Vielen Dank für dieses offene Gespräch. Gibt es noch etwas, das Sie ansprechen möchten oder über das Sie sprechen möchten?”

Durch Fragen und aktives Zuhören schafft ein solches Gespräch Raum für Reflexion, Perspektivwechsel und möglicherweise auch für die Entwicklung von Lösungsansätzen.

Es ist wichtig zu verstehen, dass Coaching sich vom Management unterscheidet. Beim Coaching geht es darum, der anderen Person durch gezielte Fragen und aufmerksames Zuhören zu helfen, ihre eigenen Gedanken zu ordnen und eigene Lösungen zu entwickeln.

Die Konflikt- oder Turbulenzphase ist kritisch, denn sie kann darüber entscheiden, ob ein Team zusammenwächst oder auseinanderfällt. Ein Leiter kann in dieser Phase wesentlich dazu beitragen, ein Klima des Vertrauens zu schaffen, in dem sich die Teammitglieder ermutigt fühlen, Ideen einzubringen. Es ist nützlich, sich die zuvor diskutierten Teamwerte ins Gedächtnis zu rufen. Der Teamleiter sollte die Einhaltung dieser Werte überwachen und eingreifen, wenn sie verletzt werden. Wenn das Team einmal den richtigen Kurs eingeschlagen hat, werden die Teammitglieder beginnen, diese Werte selbstständig zu verteidigen. Zum Beispiel, wenn jemand in einem Meeting durch Körpersprache Ablehnung signalisiert, sollte der Leiter intervenieren und an die vereinbarten Teamwerte erinnern.

Das Vertrauen innerhalb des Teams wird auch gestärkt, wenn Teammitglieder aktiv um Unterstützung bei ihren Aufgaben bitten und diese auch anbieten. Ein Ansatz, der in einigen agilen Teams erfolgreich war, ist die Bildung von “Entwicklungspaaren”, die sich gegenseitig bei der Arbeit unterstützen. Ziel ist es, eine Kultur zu fördern, in der es normal ist, um Hilfe zu bitten, Hilfe anzubieten und Hilfe von anderen anzunehmen.

Der Teamleiter mag auch gelegentlich eingreifen müssen, um sicherzustellen, dass zurückhaltendere Teammitglieder zu Wort kommen und nicht von extrovertierteren Kollegen überstimmt werden. Es ist wichtig, von jedem Teammitglied Meinungen einzuholen und diese auch zu berücksichtigen.

Nach Überwindung der Turbulenzphase wird sich das Team festigen.

Interpersonelle Fähigkeiten, wie Konfliktlösung, Problemlösung, Entscheidungsfindung, Kommunikationsfähigkeiten und Verhandlung, sind entscheidende Werkzeuge für jede Führungskraft. Auch wenn diese Themen umfassend sind und nicht alle im Detail in dieser Lektion behandelt werden können, werden einige von ihnen in spezifischen Abschnitten wie “Kommunikationsmanagement und Stakeholder-Einbindung” sowie “Problem- und Änderungsmanagement” näher erörtert.

Die Normierungsphase.

In der Normierungsphase beginnen die Teammitglieder, ihre Differenzen zu überwinden, die Stärken der anderen zu würdigen und die Führungsrolle anzuerkennen. Da die Teammitglieder einander nun besser verstehen, fühlen sie sich sicherer, um Hilfe zu bitten und konstruktive Kritik zu äußern. Es entsteht ein stärkeres Engagement zu den gemeinsamen Zielen, was die Erreichung dieser Ziele begünstigt.

Um diese Phase zu unterstützen, können Sie als Leiter verschiedene Teambuilding-Maßnahmen initiieren. Diese Aktivitäten sind nicht nur während der Normierungsphase, sondern in allen Stadien der Teamentwicklung hilfreich. Beispiele für solche Teambuilding-Aktivitäten sind gemeinsames Kochen, Wanderungen, das Gestalten eines Terrariums, Lego-Wettbewerbe, Detektiv-Mystery-Spiele, Gehirntrainings, das Malen eines Gemeinschaftsbildes und viele mehr. Für Inspiration und konkrete Ideen zu Teambuilding-Workshops können entsprechende Plattformen oder Anbieter konsultiert werden.

Beispiele für reale Workshops zur Entwicklung des Teamgeistes finden Sie unter folgendem Link: https://portesdesiris.ch/de/unternehmen/teambuilding

Zudem kann eine Kombination aus einem Trainingsworkshop und einer Teambuilding-Aktivität, wie etwa ein Projekt-Simulationsspiel, sehr effektiv sein. Solche Spiele sind nicht nur unterhaltsam, sondern auch lehrreich und können flexibel, sowohl vor Ort als auch remote, durchgeführt werden. Informationen zu spezifischen Angeboten und Programmen sind über entsprechende Anbieter oder Plattformen verfügbar.

Weitere Informationen finden Sie unter dem folgenden Link: https://learnplace.org/cppmst-de

Die Leistungsphase.

In der Leistungsphase angekommen, haben Sie als Leiter mehr Freiraum für andere Aufgaben, beispielsweise für die Gründung neuer Teams. Mit einem Hochleistungsteam ist es möglich, anspruchsvollere Aufgaben zu delegieren.

Die Erfolge des Teams zu würdigen und zu feiern ist wichtig, und es gibt zahlreiche Möglichkeiten, dies zu tun – nicht nur beim nahenden Projektabschluss, sondern bei jedem erzielten Erfolg.

Die einfachste Form der Anerkennung ist, die Leistungen auszusprechen. Erfolge können auch mit anderen Personen oder Teams geteilt werden, sei es per E-Mail, über die Unternehmenswebseite oder durch ein Zusammenkommen des Teams zum Applaudieren.

Manchmal mag auch ein kleines Geschenk angebracht sein. Ein gemeinsamer Ausflug zur Feier eines Erfolgs kann das Teamgefühl stärken. Wenn Teammitglieder unbezahlte Überstunden geleistet haben, könnte zusätzliche Freizeit eine passende Anerkennung sein. Die Idee, Erfolge zu belohnen und zu feiern, kann sich bis zu formellen Preisverleihungen oder der Einrichtung einer “Hall of Fame” ausweiten.

Die Abschiedsphase.

Die Abschiedsphase tritt ein, wenn das Projekt oder Teile davon abgeschlossen sind und das Team demzufolge aufgelöst wird. Die Mitglieder werden dann neuen Aufgaben oder Projekten zugeteilt. Diese Phase kann nicht nur am Projektende, sondern auch während des Projekts bei Abschluss bestimmter Arbeitspakete oder Meilensteine eintreten.

Für manche, besonders jene, die stabile Routinen schätzen oder enge Beziehungen zu Kollegen aufgebaut haben, kann diese Übergangszeit herausfordernd sein. Hier kann Coaching eine wertvolle Unterstützung bieten.

Als Leiter haben Sie die Möglichkeit, das Selbstwertgefühl und die beruflichen Aussichten der Teammitglieder, die sich besonders hervorgetan haben, zu fördern. Dies kann durch öffentliches Lob bei Unternehmensmeetings oder durch das Ausstellen von Empfehlungen und Referenzschreiben geschehen.

Die Schulung.

Die berufliche Fortbildung der Teammitglieder spielt eine zentrale Rolle bei der Förderung ihrer Fähigkeiten. Dazu gehören unterschiedliche Methoden wie Präsenzschulungen, Fernlehrgänge und praktisches Lernen am Arbeitsplatz, eventuell mit der Unterstützung eines erfahrenen Kollegen aus dem Projektteam. Oftmals erweist sich eine Kombination verschiedener Lehransätze als besonders effektiv. Die Planung der Fortbildungsmaßnahmen erfolgt gemäß dem Personalmanagementplan, wobei ungeplante Schulungen durch Beobachtungen, Gespräche und Leistungsbewertungen im Projektverlauf initiiert werden können.

Die Finanzierung der Schulungsmaßnahmen kann entweder über das Projektbudget oder über das allgemeine Budget der durchführenden Organisation erfolgen, besonders wenn die erworbenen Kompetenzen auch für zukünftige Projekte von Nutzen sind. Die Durchführung der Schulungssitzungen kann sowohl von internen als auch von externen Trainern, oder einer Kombination aus beiden, übernommen werden. Dieser Kurs im Projektmanagement könnte Teil eines hybriden Lernkonzepts sein, das verschiedene Lernformen und die Entwicklung praktischer Fertigkeiten miteinander verbindet.

Zusammengefasst beinhaltet die Entwicklung eines Teams die Förderung von Fähigkeiten, die Verbesserung der Teaminteraktionen und die Gestaltung eines positiven Teamumfelds. Typischerweise durchläuft ein neues Team die Phasen:

• Orientierung,
• Konflikt,
• Normierung,
• Leistung,
• Abschied.

Coaching-Kompetenzen und die Pflege zwischenmenschlicher Beziehungen sind entscheidend, um den Entwicklungsprozess des Teams zu unterstützen. Zudem stellt die Fortbildung der Teammitglieder ein wesentliches Instrument zur Stärkung des Teams dar.

 

 

3.7 Kommunikation und Stakeholderengagement managen

In diesem Abschnitt werden Methoden und Techniken vorgestellt, um eine wirksame und proaktive Kommunikation in Ihrem Projekt zu gewährleisten und eine angemessene Einbindung der Stakeholder zu fördern.

Effiziente Kommunikation ist ein kritischer Erfolgsfaktor für jedes Projekt. Ohne eine angemessene Informationsverteilung unter den Hauptstakeholdern erhöht sich das Risiko für Missverständnisse und Probleme erheblich. Dies betrifft sowohl die Kommunikation innerhalb des Teams, das für die Umsetzung der Arbeitspakete zuständig ist, als auch die Kommunikation zwischen den Verantwortlichen dieser Pakete, dem Projektmanager und den verschiedenen Stakeholdern. Regelmäßige Meetings und Berichterstattungen sind grundlegende Instrumente, um Fortschritte transparent zu machen und Erwartungen zu steuern. Bei größeren Projekten oder solchen, die signifikante kulturelle Veränderungen innerhalb der Organisation nach sich ziehen, ist ein breiter gefächerter Kommunikationsansatz erforderlich, wie er im Kommunikationsmanagement- und Stakeholder-Engagement-Plan festgelegt ist.

Kommunikation und Stakeholderengagement in kleinen Projekten.

Bei kleinen Projekten gestaltet sich der Kommunikationsmanagementplan oft übersichtlich, da in der Regel nur kurze Berichte benötigt werden. Ist der Projektmanager direkt an der Erstellung der Liefergegenstände beteiligt, hat er meist einen guten Überblick über den Projektstatus. Sind die Stakeholder auf den Sponsor und eine kleine Gruppe von Personen begrenzt, lassen sich ihre Kommunikationsbedürfnisse in der Regel durch regelmäßige Meetings decken.

Sollte der Projektmanager jedoch nicht unmittelbar an der Erstellung der Liefergegenstände beteiligt sein, etwa weil er gleichzeitig mehrere kleine Projekte leitet, ist ein formellerer Managementansatz erforderlich. Dieser Ansatz muss die Kommunikation zwischen dem Team, den Verantwortlichen für die Arbeitspakete, dem Projektmanager und anderen wichtigen Stakeholdern effektiv steuern. Ein typischer Prozess könnte folgendermaßen aussehen:

• Die Verantwortlichen für die Arbeitspakete informieren den Projektmanager wöchentlich über den Fortschritt ihrer jeweiligen Pakete. Auf Basis dieser Informationen erstellt der Projektmanager alle zwei Wochen einen zusammenfassenden Bericht für den Sponsor und andere Schlüsselstakeholder.
• Der Projektmanager organisiert regelmäßige Treffen mit den Arbeitspaketverantwortlichen sowie mit dem Sponsor und weiteren wichtigen Stakeholdern. In diesen Treffen wird die aktuelle Leistung im Vergleich zur geplanten Leistungsbasis besprochen. Zudem werden Informationen zu aktuellen Problemen, Anforderungen an Änderungen und Risiken auf den neuesten Stand gebracht.

Die Frequenz der Meetings sollte sich an der Projektdauer und den spezifischen Kommunikationsanforderungen orientieren. Bei einem dreiwöchigen Projekt könnten beispielsweise zwei Meetings pro Woche sinnvoll sein, während bei einem achtwöchigen Projekt wöchentliche Treffen ausreichen könnten. Projektmanager, Sponsor und andere Beteiligte eines kleinen Projekts sollten gemeinsam die passende Taktung der Meetings festlegen.

Bei Anwendung eines agilen Ansatzes, wie z.B. Scrum, wird das Team wahrscheinlich weniger formale Berichte erstellen, dafür aber tägliche Kurzmeetings – sogenannte “Daily Scrums” – abhalten. In diesen Meetings werden drei zentrale Fragen beantwortet: Was wurde gestern erledigt? Was steht heute an? Gibt es Hindernisse? Identifizierte Blockaden werden dann zu Aufgaben für den Projektmanager (oder Scrum Master), der primär dafür zuständig ist, diese Hindernisse aus dem Weg zu räumen. Der Sponsor, in der agilen Welt oft als Product Owner bezeichnet, erhält am Ende jedes Entwicklungszyklus (üblicherweise zwei Wochen) eine Vorstellung des aktuellen Produktstands.

In größeren Projekten sind Berichte und Meetings zwar unverzichtbar, doch wird auch eine Vielfalt anderer Kommunikationsformen benötigt. Zudem verlangen die Bemühungen um eine stärkere Einbindung der Stakeholder nach ausgefeilteren Strategien.

Zu Beginn ist es wichtig, die Schlüsselstakeholder zu identifizieren. Eine solche Identifizierung und Kategorisierung der Stakeholder findet bereits im Rahmen der Projektdefinition statt und wird im Projektauftrag festgehalten. Da Planungsaktivitäten in jeder Projektphase vorkommen, wird das Stakeholder-Register fortlaufend aktualisiert. Dies geschieht insbesondere, wenn die Projektoutputs für jede Phase genauer definiert und in Arbeitspakete aufgeteilt werden, was die Zusammensetzung der Stakeholder je nach Phase beeinflussen kann.

Für die Klassifizierung der Stakeholder kann eine Vielzahl von Methoden zum Einsatz kommen, darunter zum Beispiel eine “Wichtigkeits- und Interessen”-Matrix. Diese bewertet Stakeholder typischerweise auf drei Stufen – niedrig, mittel und hoch – hinsichtlich ihrer Bedeutung für das Projekt und ihres Interesses daran.

Um die Bedeutung eines Stakeholders für Ihr Projekt zu ermitteln, ist es notwendig, dessen Einfluss auf den Projekterfolg zu bewerten sowie die Auswirkungen zu betrachten, die eine Nichtbeteiligung dieses Stakeholders hätte. Ein Stakeholder, dessen Engagement als essenziell eingestuft wird, findet seinen Platz in den oberen Quadranten der Matrix.

Um das Interessensniveau, Engagement oder Bewusstsein eines Stakeholders zu bestimmen und um tiefergehende Einblicke in dessen Kommunikationsbedürfnisse zu gewinnen, ist ein direkter Austausch mit den betreffenden Personen unerlässlich. In einigen Fällen mag ein Stakeholder spezifische Erwartungen an das Projekt haben und sucht aktiv nach Informationen und Beteiligungsmöglichkeiten. In anderen Fällen zeigt der Stakeholder vielleicht nur ein geringes Interesse am Projekt, möchte jedoch auf dem Laufenden gehalten werden. Jedes dieser Interessensniveaus wird entsprechend als niedrig, mittel oder hoch klassifiziert.

Das Resultat dieser Bewertung ist eine Matrix mit neun Feldern, die als Grundlage für Ihren Aktionsplan zur Gestaltung der Kommunikation und des Engagements der Stakeholder dient.

	Interesse / Engagement / Sensibilisierung
Bedeutung		Niedrig	Mittel	Hoch
	Hoch	4	2	1
	Mittel	7	5	3
	Niedrig	9	8	6

Ihre Hauptaufmerksamkeit sollte sich auf die Stakeholder in den Quadranten 4 und 7 richten:

• Stakeholder im Quadranten 4 sind für den Erfolg Ihres Projekts entscheidend, zeigen jedoch momentan wenig Interesse oder sind nicht ausreichend über das Projekt informiert. Ihre Strategie sollte darauf abzielen, diese Stakeholder in den Quadranten 1 zu verschieben, wo ihre Bedeutung und ihr Interesse am Projekt beide hoch sind, oder zumindest in den Quadranten 2, wo ihr Interesse gesteigert wird, auch wenn es nicht das höchste Niveau erreicht.
• Stakeholder im Quadranten 7 weisen eine mittlere Bedeutung für das Projekt auf, sind aber entweder nicht interessiert oder nicht hinreichend informiert. Das Ziel sollte hier sein, diese Stakeholder in den Quadranten 3 zu bewegen, wo sowohl ihre Bedeutung als auch ihr Interesse am Projekt als hoch eingestuft werden, oder zumindest in den Quadranten 5, wo ihr Interesse zunimmt, selbst wenn es nicht das höchste Level erreicht.
• Die aktuelle Positionierung der Stakeholder in den Quadranten 2 und 5 dürfte grundsätzlich zufriedenstellend sein. Überlegen Sie jedoch, ob eine Verschiebung einiger Stakeholder von Quadrant 2 nach Quadrant 1 sinnvoll wäre.
• Stakeholder in den Quadranten 9, 8 und 6 können ihre Position beibehalten, da sie keinen wesentlichen Einfluss auf Ihr Projekt ausüben. Besonders im Quadranten 6 angesiedelte Stakeholder können sich als besonders wertvoll erweisen während der Definitions- und Planungsphase Ihres Projekts sowie bei der Testung Ihrer Lösung.

Welche Kommunikationsstrategien und Maßnahmen zur Förderung des Engagements kommen infrage? Diese lassen sich in drei Kategorien einteilen: obligatorische, informative und auf Marketing ausgerichtete Maßnahmen.

• Obligatorische Kommunikation umfasst solche Berichte und Besprechungen, die entweder gesetzlichen Vorschriften oder internen Unternehmensrichtlinien entspringen. Versenden Sie diese Unterlagen proaktiv, ohne dass eine explizite Anforderung vorliegt. Hierzu zählen auch jene Berichte und Meetings, die in Ihrem Plan für das Kommunikationsmanagement als verbindlich festgelegt sind. Beispiele hierfür sind Updates von den Leitern der Arbeitspakete an den Projektmanager sowie Kommunikation des Projektmanagers mit dem Sponsor und dem Steuerungsausschuss, sofern vorhanden. Ebenfalls fallen regelmäßige Abstimmungen zwischen dem Projektmanager, dem Sponsor und dem Steuerungsausschuss in diese Kategorie.
• Informative Kommunikation bietet Informationen an, verlangt jedoch von den Empfängern, dass sie eigeninitiativ handeln, um diese Informationen zu erhalten. Beispiele hierfür sind eine Projekthomepage oder eine Seite mit häufig gestellten Fragen (FAQs).
• Marketingkommunikation zielt darauf ab, Zustimmung und Enthusiasmus für das Projekt sowie seine Ergebnisse zu wecken. Dies kann durch verschiedene Mittel erreicht werden, etwa durch Newsletter oder durch regelmäßige persönliche Gespräche mit Schlüsselstakeholdern. Auch der Besuch relevanter Orte, um das Projekt und seine Nutzen vorzustellen, gehört dazu. Weitere Methoden umfassen Erfahrungsberichte, die den Mehrwert der Projektergebnisse darlegen, sowie die Kreation eines einprägsamen Akronyms oder Slogans, um ein positives Projektimage zu fördern. Wichtig sind auch Feierlichkeiten zu bedeutenden Projektmeilensteinen. Überlegen Sie zudem, ob Erinnerungsstücke mit Projektname und -logo wie Anstecknadeln, Stifte, Tassen oder T-Shirts sinnvoll wären, um eine Art Marketingkampagne für Ihr Projekt zu gestalten.

Bei umstrittenen Projekten oder solchen, die einen Kulturwandel mit sich bringen, spielt die Marketingkommunikation eine wesentliche Rolle. Ein vorausschauender Kommunikationsansatz ist unerlässlich, besonders wenn Widerstände zu erwarten sind.

Eine wirksame Kommunikationsstrategie könnte beispielsweise die folgenden Elemente beinhalten:

• Tägliche Anwesenheit des Projektmanagers am Standort des Teams, sofern dieses vor Ort zusammenarbeitet.
• Wöchentliche Aktualisierungen vom Projektmanager an das Projektteam, mittels E-Mail, Video oder über Gruppennachrichtendienste.
• Formelle, wöchentliche Statusberichte der Verantwortlichen für Arbeitspakete an den Projektmanager, erstellt nach einem einheitlichen Muster.
• Halbmonatliche Besprechungen zwischen den Verantwortlichen für Arbeitspakete und dem Projektmanager zur intensiven Koordination.
• Das Lenkungsgremium sollte alle zwei Monate eine Zusammenfassung für Führungskräfte erhalten, um strategische Entscheidungen zu treffen.
• Persönliche, monatliche Berichte sowie wöchentliche, zweiwöchentliche oder monatliche Berichte an den Projektsponsor, angepasst an dessen Vorlieben.
• Versand eines vierteljährlichen Newsletters an die gesamte ausführende Organisation zu Informations- und Werbezwecken.
• Feierlichkeiten zu Meilensteinen innerhalb der Phase mit dem Projektmanager und dem Entwicklerteam der Phase, wobei der Sponsor bei größeren Übergangsfeierlichkeiten teilnehmen sollte.
• Für externe Interessengruppen in den Quadranten 4 und 7 könnten Maßnahmen zur Förderung des Engagements sinnvoll sein, wie Informationsveranstaltungen, um die Vorteile des Projekts darzustellen, ergänzt durch Berichte aus ähnlichen Projekten, sowie der Versand des vierteljährlichen Newsletters.
• Gezielte Engagementmaßnahmen für ausgewählte externe Interessengruppen im Quadranten 4 könnten deren Einbindung in die Definition der Anforderungen und die Qualitätssicherung der Projektergebnisse umfassen.

Ein Musterbericht über den Projektfortschritt könnte folgenden Bestandteile umfassen:

• Erbrachte Leistungen im Abgleich mit den im Zeitplan festgelegten Aktivitäten, wobei farbliche Indikatoren – Grün, Gelb und Rot – zur schnellen Einschätzung des Status einzelner Elemente dienen.
• Anmerkungen zu Aufgaben, die bis dato hätten abgeschlossen sein müssen, es jedoch nicht sind, einschließlich der daraus resultierenden Konsequenzen für Schnittstellen. Empfehlenswert ist es, Ausflüchte zu vermeiden und stattdessen korrigierende Schritte vorzuschlagen.
• Eine Vorschau auf die im nächsten Berichtszeitraum anstehenden Tätigkeiten.
• Festgestellte Problematiken sowie vorgeschlagene oder bereits eingeleitete Gegenmaßnahmen.
• Anträge zur Modifikation des Projektumfangs.
• Neu aufgedeckte Risiken.
• Sonstige relevante Punkte.
• Anlagen, die tiefergehende Einzelheiten zu spezifischen Punkten für jene Stakeholder liefern, die detailliertere Informationen benötigen, ohne den Hauptteil des Berichts zu überfrachten.

Zu den Projektstatusbesprechungen ist Folgendes anzumerken:

• Sie sollten auf eine Stunde begrenzt sein. Für die Problemlösung sind separate Besprechungen anzusetzen. Eine einheitliche Tagesordnung, die den Inhalten des Fortschrittsberichts entspricht (abgesehen von den Anhängen), wird empfohlen.
• Die Besprechungen sollten exakt zum festgelegten Zeitpunkt beginnen, ohne auf verspätete Teilnehmende zu warten. Dieser Punkt erfordert möglicherweise eine Anpassung an die jeweilige Unternehmenskultur. Ein Verspätung von einer Minute kann in der Schweiz bereits als Missachtung empfunden werden, während in anderen Kulturen eine Verspätung von bis zu 15 Minuten noch als pünktlich gelten kann.
• Es ist wichtig, Aktionspunkte festzuhalten und deren Umsetzung zu überwachen, beispielsweise durch die Zuweisung als Aufgaben in einem Kollaborationstool.

Dokumentationsmanagement.

Das Management von Dokumentation ist ein wichtiger Bestandteil des Kommunikationsmanagements. Besonders wenn mehrere Personen an der Erstellung von Dokumenten beteiligt sind, kann die Überwachung der verschiedenen Versionen herausfordernd sein. Kollaborationswerkzeuge erweisen sich hierbei oft als sehr nützlich, vor allem, wenn das Projekt über die Grenzen der eigenen Organisation hinausgeht und einige Beteiligte keinen Zugriff auf den Firmenserver haben. Eine weitere Unterstützung bietet die Angewöhnung des Teams, Dokumente nach einer einheitlichen Logik zu benennen, beispielsweise mittels der Initialen der Verfassenden und des Datums. Beginnt der Dokumentenname mit dem ISO-Datum, gefolgt von den Initialen der Verfassenden und der Revisionskette, lässt sich leichter nachvollziehen, wer das Dokument verfasst hat und wer an der Überprüfung dieser speziellen Version beteiligt war. So deutet der Name “2024.10.27 NameDesDokuments-MN-OC” darauf hin, dass MN das Dokument erstellte und OC es am 27. Oktober 2024 überprüfte. Der Name “2024.10.29 NameDesDokuments-MN-GS” zeigt an, dass GS das Dokument ebenfalls überprüfte, die Kommentare von OC jedoch nicht einbezogen wurden. Der Name “2024.10.30 NameDesDokuments-MN-OC-GS-MN” wiederum zeigt, dass MN, der ursprüngliche Verfasser, die Anmerkungen von OC und GS in einer neueren Version vom 30. Oktober zusammengeführt hat.

Wenn Ihr Team in unterschiedlichen Zeitzonen arbeitet, kann die Verwendung des UTC-Zeitformats (Coordinated Universal Time, auch bekannt als GMT, Greenwich Mean Time) für Besprechungen sinnvoll sein. UTC dient als Referenz für alle anderen Zeitzonen und wechselt nicht zwischen Sommer- und Winterzeit. Verlassen Sie sich nicht allein auf traditionelle Planungswerkzeuge für die korrekte Zeitumrechnung, insbesondere beim Wechsel zwischen Sommer- und Standardzeit. Um Missverständnisse zu vermeiden, empfiehlt es sich, klare Angaben wie “Das Meeting findet um 14:30 UTC statt” zu machen. Um Verwirrung über das Datum zu vermeiden, z.B. ob “01.12.24” den 1. Dezember oder den 12. Januar bedeutet, nutzen Sie das ISO-Format (2024-01-12), das eindeutig den 12. Januar 2024 bezeichnet.

 

Proaktive im Vergleich zu reaktiver Kommunikation.

Ein abschließender Gedanke zur Unterscheidung zwischen proaktiver und reaktiver Kommunikation: Reaktive Kommunikation findet statt, wenn jemand Sie nach Informationen fragt und Sie daraufhin antworten. Dies gilt als grundlegende Höflichkeit, obwohl manche der Meinung sind, dass das Ausbleiben einer Antwort ebenfalls als eine Form der Antwort anzusehen ist. Der in diesem Kurs empfohlene proaktive Kommunikationsansatz legt Wert darauf, die Beteiligten zu informieren, bevor sie selbst nachfragen. Wenn jemand zum Telefon greift oder Ihnen eine E-Mail sendet, um sich nach dem Stand des Projekts zu erkundigen, ist es im Grunde schon zu spät.

Zusammenfassend lässt sich sagen, dass die Komplexität des Kommunikationsmanagements den spezifischen Anforderungen des Projekts gerecht werden muss. Bei kleineren Projekten gestaltet sich das Kommunikationsmanagement meist einfacher, wohingegen umfangreichere Projekte ein deutlich Anspruchsvollere Kommunikationsmanagement erfordern.

Ein besonderes Augenmerk sollte auf die Stakeholder gelegt werden, insbesondere wenn diese nicht ausreichend informiert, interessiert oder eingebunden sind. Es ist ratsam, auch Gegner in die Kommunikationsstrategie miteinzubeziehen, um sie zumindest zu neutralisieren, und generell einen proaktiven Kommunikationsansatz zu verfolgen.

 

 

3.8 Qualität sichern

In diesem Abschnitt wird der Unterschied zwischen “Qualitätssicherung” und “Qualitätskontrolle” beleuchtet, wobei der Schwerpunkt auf der Qualitätssicherung liegt.

Beginnen wir mit der Definition von Qualität gemäß der ISO 9000-Norm: Qualität ist das Ausmaß, in dem ein Set an inhärenten Eigenschaften die gestellten Anforderungen erfüllt. Der zentrale Punkt dabei ist die Anforderungserfüllung.

Die Erfüllung der Anforderungen, sprich die Qualität, ist nicht gleichzusetzen mit Klasse oder Grad, die einer Produktkategorie mit derselben funktionalen Nutzung zugeordnet wird. Zum Beispiel sind XL-Eier größer als S-Eier, was jedoch keine Aussage über eine höhere Qualität trifft. Ist ein XL-Ei beschädigt, mag sein Kaliber hoch sein, seine Qualität jedoch gering, unter der Voraussetzung, dass Intaktheit der Schale ein Qualitätsmerkmal von Eiern ist.

Ein Auto, das in 3 Sekunden von 0 auf 100 km/h beschleunigt, über einen Champagnerkühler verfügt und bei Bedarf abheben und fliegen kann, mag beeindruckend sein. Sollte jedoch eine wesentliche Anforderung sein, dass das Auto 5 Liter Kraftstoff auf 100 Kilometer verbraucht, es jedoch 8 Liter benötigt, erfüllt es dieses wichtige Qualitätskriterium nicht und weist somit in Bezug auf diese Anforderung eine geringere Qualität auf als ein einfacheres Auto, das die Energieeffizienzanforderungen erfüllt.

Im Projektmanagement sind zwei zentrale Qualitätsaspekte von Bedeutung:

Einerseits die “Qualitätskontrolle”, welche die Übereinstimmung der Liefergegenstände mit den funktionalen Anforderungen und Qualitätskriterien überprüft. Dieser Aspekt wird hauptsächlich im Rahmen des Projektcontrollings behandelt.

Andererseits die “Qualitätssicherung”, die sich auf die Implementierung der im Qualitätsmanagementplan festgelegten Standards, Richtlinien und Verfahren konzentriert, um die Erfüllung der Kundenerwartungen durch den Hauptliefergegenstand und seine Komponenten zu gewährleisten. Hierbei liegt der Fokus auf der Erzeugung von Qualität.

Es ist von entscheidender Bedeutung zu erkennen, dass Qualitätssicherung und Qualitätskontrolle eng miteinander verflochten sind. Zusätzlich muss gewährleistet sein, dass nicht nur der Hauptliefergegenstand des Projekts, sondern auch die Ergebnisse jedes einzelnen Arbeitspakets definierte “Akzeptanzkriterien” erfüllen.

Ein grundlegender Teil des Qualitätssicherungsprozesses ist die Überprüfung der Einhaltung der vorgegebenen Standards, Richtlinien und Verfahren. Diese Prüfungen können entweder von internen oder externen Audit-Abteilungen oder von einem Projektbüro des Unternehmens durchgeführt werden.

Qualitätssicherung geht jedoch über die bloße Normenkonformität hinaus. Der Projektleiter ist dafür verantwortlich, die Qualität des Produktions- oder Entwicklungsprozesses der Projektliefergegenstände sicherzustellen. Es geht somit nicht allein um das Endprodukt, sondern auch um den Prozess, der zu diesem führt. Beispielsweise kann aus der Tatsache, dass ein Design-Dokument hastig erstellt und nicht geprüft wurde, gefolgert werden, dass der daraus resultierende Liefergegenstand wahrscheinlich Mängel aufweisen wird, ohne dass das Design-Dokument selbst in Augenschein genommen oder verstanden werden muss.

Eine umfassendere Sichtweise der Qualitätssicherung.

Lassen Sie uns den Blickwinkel erweitern. Eine umfassendere Perspektive der Qualitätssicherung erstreckt sich über die bloße Auditierung hinaus und beschäftigt sich mit der Schaffung von Qualität in allen Phasen – vom Design über die Produktion und Tests bis hin zur Integration und Implementierung des Hauptliefergegenstandes und seiner Bestandteile. Diese ganzheitliche Sicht auf die Qualitätssicherung bezieht die Qualität von Rohmaterialien, Ausrüstungen, Software und Arbeitsabläufen mit ein. Sie umfasst ebenso die Unternehmenskultur und die Arbeitsweisen aller Beteiligten, einschließlich der Geschäftsführung, der Zulieferer und selbst der Kunden.

Das Konzept des “Total Quality Management” (TQM) bietet hier einen wertvollen Ansatz. Als eine aus Japan stammende Managementphilosophie fokussiert TQM auf höchste Qualität in allen Unternehmensbereichen durch stetige Verbesserungen. Dieses Prinzip steht in enger Verbindung mit der Philosophie des “Kaizen”, nach der jede Person auf jeder Ebene des Unternehmens dazu aufgerufen ist, Schwachstellen zu identifizieren. Es wird von allen erwartet, Verbesserungsvorschläge einzubringen, nach der Maxime “Null Fehler” zu streben und Aufgaben von Beginn an korrekt auszuführen, anstatt Fehler im Nachhinein zu erkennen und zu beheben, was als “Verschwendung” betrachtet wird.

Die Philosophie des “Lean Managements” betont ebenfalls die Eliminierung von Verschwendung in allen Bereichen. Unter Verschwendung versteht man jede Aktivität, die keinen Wert generiert, für den der Kunde zu zahlen bereit ist. Ein prägnantes Beispiel hierfür ist die Montage einer Autotür: Wird sie korrekt eingebaut, entsteht ein Mehrwert. Die Nacharbeit einer fehlerhaft montierten Tür hingegen stellt eine Verschwendung dar. Unordnung, wiederholte Fehler, die Zuweisung von Schuld anstatt die Übernahme von Verantwortung, Zeitverlust durch Ausflüchte bei Leistungsbewertungen, übermäßige Lagerbestände und unvollständige Arbeiten – all dies gilt als Verschwendung, da Ressourcen verbraucht werden, ohne einen fertigen Wert zu schaffen.

Die Lean-Philosophie zielt darauf ab, die Anzahl der in einem Produktionszyklus initiierten Aufgaben zu begrenzen, um sicherzustellen, dass sie auch abgeschlossen werden können. Dies verhindert, dass zu viele Aufgaben gleichzeitig begonnen und infolge von Kapazitätsüberlastungen unvollendet bleiben. Ein alltägliches Beispiel dafür ist das gleichzeitige Starten zu vieler Projekte, von denen viele aufgrund von Arbeitsüberlastung nicht fristgerecht abgeschlossen werden können. Länger als nötig unvollendete Aufgaben gelten ebenfalls als Verschwendung.

Die “Team-Motivation” spielt eine entscheidende Rolle für die Qualitätserzeugung im Projektmanagement. Motivierte Teammitglieder tendieren dazu, seltener Fehler zu machen, effizienter auf Fehlersuche zu gehen, Kollegen bei Verbesserungen zu unterstützen und ihre Aufgaben effektiver sowie effizienter zu erledigen. Es lohnt sich, bei Bedarf die Abschnitte über “Teamführung”, “Team-Entwicklung” sowie “Kommunikationsmanagement und Stakeholderengagement” zu Rate zu ziehen. Das Bilden von Teams, die über die notwendigen Fähigkeiten verfügen, sowie deren fortlaufende Entwicklung, Schulung und Coaching sind Schlüsselfaktoren, um von Anfang an hohe Qualität sicherzustellen, anstatt später qualitativ minderwertige Arbeit nachbessern zu müssen.

Die Bedeutung eines qualitätsorientierten organisatorischen Rahmens und einer entsprechenden Kultur unterstreicht die Notwendigkeit einer Führung, die in die gleiche Richtung weist. Es gestaltet sich als herausfordernd, in einer an minderwertige Qualität gewöhnten Organisation hohe Qualitätsstandards in Projekten zu realisieren. Der Projektleiter kann durch die Anwendung eines strukturierten Führungsansatzes seinen Beitrag leisten, beispielsweise durch die Implementierung der in diesem Kurs erörterten ISO 21502-Norm.

Dies umfasst unter anderem einen Qualitätsmanagementplan, definierte, spezifische und messbare Anforderungen sowie Akzeptanzkriterien für jedes Arbeitspaket, ein motiviertes Team und einen engagierten Projektsponsor. Die Qualitätsaudits basieren auf eindeutig messbaren Qualitätsmerkmalen. All diese Anstrengungen können im Einklang mit den besten Praktiken des Qualitätsmanagements stehen. Doch ohne die Unterstützung der Organisation und insbesondere, wenn die Unternehmensführung diese Elemente als unnötigen Aufwand ansieht, wird es für den Projektleiter schwierig, ein qualitativ hochwertiges Produkt zu liefern und die erwarteten Ergebnisse zu erzielen.

Audits sind, wie bereits erwähnt, ein zentrales Instrument der Qualitätssicherung. Darüber hinaus gibt es verschiedene andere Werkzeuge und Techniken im Qualitätsmanagement, wie etwa Checklisten, Prozessanalysen, Entscheidungsfindungs- und Problemlösungstechniken. Zwei davon wollen wir näher betrachten: “Ursache-Wirkungs-Diagramme” und “Pareto-Analysen”.

“Ursache-Wirkungs-Diagramme”, auch bekannt als “Ishikawa-Diagramme” oder “Fischgrätendiagramme”, dienen dazu, die Faktoren zu ermitteln, die zu Qualitätsproblemen oder anderen Schwierigkeiten führen können. Im Rahmen eines Brainstormings identifiziert das Team zahlreiche potenzielle Ursachen für ein bestimmtes Problem oder einen Effekt und ordnet diese dann in sinnvolle Kategorien ein. Dieser Ansatz bildet die Grundlage für die Entwicklung von Mind-Map-Werkzeugen.

Die “Pareto-Analyse” ist ein statistisches Werkzeug, das darauf abzielt, die wenigen, aber entscheidenden Ursachen zu identifizieren, die vorrangig behandelt werden sollten, da sie für den Großteil der Probleme verantwortlich sind. Diese Methode basiert auf der 20/80-Regel von Pareto, die besagt, dass 20% der Ursachen 80% der Wirkungen oder Probleme hervorrufen. Im Kontext von Qualitätsproblemen bedeutet dies, dass ein kleiner Anteil der Fehlerquellen die Mehrheit der Qualitätsmängel verursacht.

Im Rahmen der Qualitätssicherungsmaßnahmen während der Projektumsetzung ist es üblich, Berichte über den aktuellen Qualitätsstatus zu erstellen. Bei Abweichungen von den Qualitätszielen werden korrektive Maßnahmen eingeleitet, die möglicherweise Anpassungen am Projektmanagementplan erfordern. Diese korrektiven Maßnahmen dienen der Problemlösung, dem Management neuer Risiken und der Verbesserung zukünftiger Leistungen durch die Reflexion und das Lernen aus Fehlern während der Retrospektiven. Dies unterstreicht die Bedeutung des Lernens aus Fehlern für die kontinuierliche Verbesserung.

Zusammengefasst bedeutet Qualität die Erfüllung spezifischer Anforderungen und ist nicht gleichzusetzen mit dem Begriff der Klasse oder des Grades eines Produkts oder einer Dienstleistung.

Qualitätssicherung unterscheidet sich von der Qualitätskontrolle. Während die Qualitätssicherung auf die Implementierung von Standards und Richtlinien durch Prozesse, Werkzeuge, Techniken, Teams und Verhaltensweisen abzielt und Qualität durch die korrekte Durchführung von Anfang an erzeugt, konzentriert sich die Qualitätskontrolle auf die Überprüfung des Endprodukts oder der Dienstleistung.

Effektive Qualitätssicherung bedeutet, Verschwendung in allen Prozessen zu vermeiden, jeden im Prozess einzubeziehen und den Kunden in den Mittelpunkt zu stellen, indem von Anfang an alles richtig gemacht wird.

Um eine hohe Qualität zu gewährleisten, bedarf es einer starken organisatorischen Führung, geeigneter Systeme, einer qualitätsorientierten Kultur sowie hochmotivierter und fähiger Teams.

 

 

 

 

 

3.9 Genehmigte Änderungen und Korrekturmaßnahmen umsetzen

Dieser Abschnitt widmet sich der Umsetzung von Maßnahmen, die ursprünglich nicht vorgesehen waren, jedoch notwendig werden, um Abweichungen im Projektmanagementplan zu beheben, auftretende Probleme zu lösen oder aus genehmigten Änderungen am Plan resultieren.

Im Laufe der Projektdurchführung werden neben den eigentlichen Projektaktivitäten auch Überwachungs- und Kontrollaktivitäten durchgeführt, um sicherzustellen, dass das Projekt entsprechend dem Projektmanagementplan voranschreitet. Im Zuge dessen können sich stets Planabweichungen, neue Risiken, Probleme und Änderungsanforderungen ergeben. Als Antwort darauf entwickelt das Projektmanagementteam korrektive und präventive Maßnahmen, die Auswirkungen auf den Projektmanagementplan haben können. Die erwähnten Kontrollaktivitäten werden im Projektcontrolling behandelt.

In dieser Einheit, die sich auf die Projektausführung konzentriert, liegt der Schwerpunkt auf der praktischen Umsetzung von Änderungen an den Managementplänen sowie von korrektiven und präventiven Maßnahmen, die aus den Kontrollprozessen hervorgehen.

Die Unterscheidung zwischen Ausführung, Kontrolle und Planung ist in der Theorie klar definiert, doch in der Praxis erleben Sie als Projektleiter diese Prozesse als fließenden Übergang. Nehmen wir an, während der Ausführung stößt das Projekt auf ein Problem. In diesem Moment schalten Sie mental in den Kontrollmodus, um mögliche Lösungen zu bewerten und entscheiden sich vielleicht für eine korrektive Maßnahme, die den Leistungsbasisplan im Projektmanagementplan beeinflussen könnte. Erfordert diese Maßnahme eine Änderung des Basisplans, ist eine formelle Genehmigung nötig, was zu einer genehmigten Änderung führt, die sowohl korrektive als auch eventuell präventive Maßnahmen beinhaltet.

Solange die Änderungsanfrage nicht genehmigt ist oder bis eine Entscheidung über die präventive oder korrektive Maßnahme getroffen wurde, verbleiben Sie im Kontrollmodus. Ist die Entscheidung gefallen, gehen Sie mental in den Planungsmodus über, indem Sie die beschlossenen Maßnahmen in Ihre Aktivitätenliste aufnehmen.

Einige dieser Aktivitäten könnten neue Arbeitspakete darstellen, die definiert, geplant und zugeteilt werden müssen. Andere Aktivitäten könnten sekundäre Risiken mit sich bringen, die eine Risikoanalyse und entsprechende Risikobewältigungsstrategien  erfordern. Wieder andere könnten Änderungen der Projektumfangs-, Termin- oder Kostenbasispläne notwendig machen. Die Auswirkungen solcher Änderungen werden im Kontrollmodus analysiert und führen zu einer Änderungsanfrage. Nach der Genehmigung dieser Änderung und der Planung der resultierenden Aktivitäten kehren Sie mental in den Ausführungsmodus zurück, um die beschlossenen und geplanten Maßnahmen umzusetzen.

Hier knüpfen wir an: bei der Implementierung genehmigter Änderungen und der Umsetzung von präventiven und korrektiven Maßnahmen.

Die Art der erforderlichen Maßnahmen ist abhängig vom jeweiligen Managementbereich und den im spezifischen Kontext verfügbaren Optionen. Wie bereits angesprochen, findet die Identifikation von Planabweichungen und die Definition entsprechender Reaktionen innerhalb der Kontrollprozesse statt. Um jedoch zu illustrieren, welche Maßnahmen möglicherweise als Ergebnis von genehmigten Änderungen oder im Rahmen der Kontrolle beschlossenen korrektiven und präventiven Maßnahmen in der Ausführungsphase implementiert werden müssen, sei ein Beispiel herangezogen.

Beispiel.

Angenommen, wir erkennen während der Überwachung, dass das Arbeitspaket 4.7 bereits nach den ersten zwei von zwanzig vorgesehenen Bauwochen um 10% im Rückstand ist. Im Zuge der Steuerung greifen wir auf Problemlösungstechniken zurück und stellen fest, dass die Verspätung durch das Verhalten der innovativen Materialien verursacht wird, die wir wegen ihrer herausragenden Resistenz gegenüber Partikeln X ausgewählt haben. Allerdings entsprechen diese Materialien nicht den Erwartungen unter den hohen Temperaturen, die tagsüber auf der Baustelle vorherrschen. Infolgedessen wird das Entwicklungsteam ausschließlich in den Nachtstunden tätig, wenn die Temperaturen unter die kritische Schwelle sinken.

• Option A sieht einen Austausch der Materialien vor, was die Qualitätsmerkmale beeinflussen und zusätzliche Kosten von 300.000 Euro verursachen könnte.
• Option B hingegen schlägt vor, die Bauarbeiten mit den aktuellen Materialien fortzusetzen, jedoch unter Einsatz einer künstlich klimatisierten Umgebung auf der Baustelle, was eine Bauzeit von vier Wochen in Anspruch nehmen und 200.000 Euro kosten würde.
• Option C würde beinhalten, ohne jegliche Anpassungen fortzufahren, was eine Verlängerung der Bauzeit auf 40 statt der geplanten 20 Wochen zur Folge hätte. Da sich dieses Arbeitspaket auf dem kritischen Pfad befindet, würde jede Verzögerung hier eine Gesamtverzögerung des Projekts nach sich ziehen. Laut Vertrag fallen bei einer Verzögerung Strafzahlungen in Höhe von 200.000 Euro pro Woche an. Das Team ist jedoch der Ansicht, dass mit einer Wahrscheinlichkeit von 50% Zeitgewinne bei anderen kritischen Aktivitäten erzielt werden können, um die Verzögerungen bei Arbeitspaket 4.7 auszugleichen.

Die dem Arbeitspaket 4.7 zugeordnete Kostenstelle besitzt eine Risikoreserve von 1 Million Euro und einen zeitlichen Puffer von 10 Wochen. Nach sorgfältiger Bewertung der drei Optionen entscheidet sich das Team für Option B, das heißt, weiterhin mit den gleichen Materialien zu bauen, aber eine künstlich temperierte Bauumgebung zu schaffen, die 4 Wochen dauern und 200.000 Euro kosten wird.

Dieser Schritt führt nicht zu einer Beeinträchtigung der Leistungsbasis des Projekts und erfordert keinen formellen Änderungskontrollprozess. Der Grund dafür ist das Vorhandensein der Risikoreserve, die speziell für solche Situationen vorgesehen ist und dementsprechend zum Einsatz kommt.

Der Projektleiter trägt den Vorfall ins Problemregister ein und wählt zur Behebung Option B. Dabei bleibt er im Kontrollmodus. Diese Entscheidung führt zur Initiierung eines neuen Arbeitspakets, das die Errichtung einer künstlich temperierten Baustellenumgebung vorsieht. Auch während dieser Phase bleibt der Projektleiter im Kontrollmodus, um die Situation effektiv zu steuern.

Mit der Unterzeichnung des Änderungsregisters zur Genehmigung der Anpassung wechselt der Projektleiter vom Kontroll- in den Planungsmodus. In dieser Phase konkretisiert er die Details des neuen Arbeitspakets, das den Aufbau der künstlich temperierten Baustellenumgebung umfasst, und delegiert die entsprechenden Aufgaben. Ebenfalls im Rahmen der Planung nimmt er notwendige Aktualisierungen am Projektstrukturplan, am Terminplan und an den Kostenschätzungen vor, um die Änderungen zu integrieren und den Projektfortschritt entsprechend anzupassen.

Wir stehen an der mentalen Schwelle, vom Planungsmodus in den Ausführungsmodus zu wechseln. Ein Bauteam kann mit der Errichtung der künstlich temperierten Baustellenumgebung beginnen. Der Projektleiter berücksichtigt dieses Element in den Projektberichten und auf den Tagesordnungen der Besprechungen im Rahmen des Kommunikationsmanagements. Wenn der Projektleiter das im Kurs Gelernte umsetzt, enthalten die Berichte und die standardmäßigen Tagesordnungen für die Besprechungen fortlaufend Punkte, die Probleme, Änderungen und Risiken thematisieren. Der Vorfall wird im Problemregister verzeichnet. Ebenso wird der Fall im Änderungsregister aufgeführt und ist Teil der Berichte und der Tagesordnungen der Besprechungen.

Hätte sich das Team für Option A entschieden, also für einen Wechsel des Materials, hätte dies sowohl die Qualität beeinflusst als auch 300.000 Euro gekostet. Diese Maßnahme hätte dann dem Änderungskontrollkomitee zur Genehmigung vorgelegt werden müssen. Ein Materialwechsel würde möglicherweise neue Ingenieurleistungen erfordern, den Einsatz unterschiedlicher Ausrüstungen und Werkzeuge bedingen und eventuell den Bedarf an anderen Teammitgliedern nach sich ziehen, die mit den neuen Materialien arbeiten. Diese erforderlichen Schritte unterscheiden sich deutlich von jenen, die sich aus Option B ergeben würden, und müssten sorgfältig geplant und umgesetzt werden.

Wenn das Team Option C gewählt hätte, würde es ohne Änderungen fortfahren, aber andere Tätigkeiten auf dem kritischen Pfad straffen, um die Verzögerung bei Arbeitspaket 4.7 auszugleichen. Hier kämen Terminverdichtungstechniken zum Einsatz, die im Projektcontrolling näher erläutert werden. Diese Maßnahmen, darunter Überstunden und die Bereitstellung zusätzlicher Ressourcen, könnten zwar wirksam sein, bergen jedoch das Risiko, die für das Arbeitspaket veranschlagten Risikozuschläge zu überschreiten – etwa durch Überstundenentgelte oder die Mehrkosten für zusätzliche Ressourcen. Zudem könnte langfristige Mehrarbeit die Motivation des Teams beeinträchtigen. Ein wesentliches Risiko dieser Option besteht in der erhöhten Risikoexposition des Projekts, bedingt durch die nur 50%ige Chance, den Zeitverlust auszugleichen, und die drohenden vertraglichen Strafen bei Verzögerungen.

Im Rahmen der Projektausführungsaktivitäten würden sowohl die Berichte als auch die Tagesordnungen der Besprechungen diese Punkte aufnehmen.

Zusammenfassend lässt sich festhalten, dass die Prozesse der Planung, Ausführung und Kontrolle in einem kontinuierlichen Zyklus stattfinden und sämtliche Aspekte des Projektmanagements miteinander verbinden. Um auf während der Projektdurchführung auftretende Probleme, Risiken und Planabweichungen zu reagieren, entwickelt der Projektleiter – gegebenenfalls in Absprache mit der Projektgovernance – entsprechende Änderungen und Korrekturmaßnahmen mithilfe von Kontrollprozessen. Diese Maßnahmen werden anschließend in den Planungsprozessen überarbeitet, bevor sie umgesetzt werden. Das verdeutlicht, wie abwechslungsreich und anspruchsvoll die Tätigkeit eines Projektleiters sein kann.

 

 

 

 

 

3.10 Risikobewältigungsstrategien umsetzen

In diesem Abschnitt geht es um die Implementierung der Risikobewältigungsstrategien, die während der Planungsaktivitäten festgelegt wurden. In diesen Planungsprozessen bereiteten wir das Risikomanagement vor, erkannten und analysierten Risiken und formulierten Strategien für deren Bewältigung. Im Laufe der Umsetzungsaktivitäten ist es nun an der Zeit, diese Risikobewältigungsstrategien in die Praxis umzusetzen. Dies ist der zentrale Inhalt dieses Kapitels.

Wir fahren fort mit unserem Beispiel, das sich auf die Risiken bei der Einführung einer Online-Lösung zur Verbesserung der Transaktionstransparenz bezieht. In den Kapiteln zur Projektplanung haben wir das Risikoregister bis zu folgendem Stand ausgearbeitet:

Name des Risikos	Risiko- nummer	Wahrscheinlichkeit 1 bis 5	Auswirkung 1 bis 5	Kritikalität	Strategie	Antwort
Sponsor	6	5	12	60	Mildern	Nominierung eines delegierten Sponsors
Funktionale Anforderungen	1	5	12	60	Mildern	Workshops zur Anforderungserhebung
Werkzeug zur Zustandsverfolgung von Transaktionen	2	4	9	36	Vermeiden	Ersatz des Anbieters
Elektronische Zahlungen	3	5	5	25	Übertragen	Beauftragung eines Anbieters für Trianguläre Zahlungslösungen
Onlinehilfe	4	3	7	21	Akzeptieren	Reserve von 2 Wochen und 25K € (*)
Schulungssitzungen	5	4	4	16	Akzeptieren	Reserve von 1 Woche und 35K € (**)

(*) Mittlere Wahrscheinlichkeit: 3 = 31% bis 50% / Zeitlicher Einfluss (niedrig) 1 bis 4 Wochen; 50% von 4 Wochen = 2 Wochen / Kostenwirkung (niedrig) 10.000 (K) € – 50.000 (K) €; 50% von 50.000 (K) € = 25.000 (K) €

(**) Hohe Wahrscheinlichkeit: 4 = 51% bis 70% / Zeitlicher Einfluss (sehr niedrig) 1 Woche x 70% = 0,7 Wochen, aufgerundet auf 1 Woche / Kostenwirkung (niedrig) 10.000 (K) € – 50.000 (K) €; 50.000 (K) € x 70% = 35.000 (K) €

Die umzusetzenden Risikobewältigungsstrategien umfassen:

• Die Akquise eines stellvertretenden Sponsors.
• Die Durchführung von Workshops zur Erfassung der Anforderungen.
• Den Austausch des Anbieters für das Werkzeug zur Nachverfolgung des Transaktionsstatus.
• Die Beauftragung eines Dienstleisters für trianguläre Zahlungen.
• Die Bildung von Reserven für die Risiken 4 und 5, auf die mit einer Strategie der aktiven Akzeptanz reagiert wird.

Die Termin- und Geldreserven für die Risiken 4 und 5 sind bereits im Projektmanagementplan festgelegt worden.

Wie erfolgt die Bereitstellung der Liefergegenstände für die festgelegten Risikobewältigungsstrategien? Die Antwort ist einfach: genau wie bei jedem anderen Liefergegenstand. Wir erstellen ihn entweder selbst oder erwerben ihn von außen. Die Entscheidung über die Vorgehensweise bei der Entwicklung jedes Liefergegenstandes hängt von dessen Art und den spezifischen Bedingungen ab.

Antwort auf Risiko Nummer 6: Einen stellvertretenden Sponsor nominieren.

Zunächst benötigen wir die Zustimmung des Hauptsponsors, um einen stellvertretenden Sponsor zu ernennen. Dieser Prozess erfordert Verhandlungsgeschick. Wie bei jeder Verhandlung ist es essenziell, den Zweck der Maßnahme klar zu kommunizieren, nämlich die Gewährleistung einer kontinuierlichen Unterstützung für das Projekt. Neben diesem Hauptanliegen haben wir auch beziehungsorientierte Ziele, wie die Aufrechterhaltung einer positiven Beziehung zum Hauptsponsor, der in der Regel eine leitende Position innehat. Manchmal kann schon das Gespräch über das Risiko mit dem Hauptsponsor ausreichen, sodass die Bestellung eines Stellvertreters nicht mehr erforderlich wird, weil der Hauptsponsor sein Engagement für das Projekt verstärkt. Andernfalls könnte er der Ernennung eines stellvertretenden Sponsors zustimmen, der ihn in der täglichen Sponsoringarbeit für das Projekt vertritt.

Was ist zusätzlich erforderlich, damit ein stellvertretender Sponsor seine Rolle effektiv ausfüllen kann? Eine ausführliche Rollenbeschreibung kann hierbei sehr hilfreich sein. Verfügt Ihre Organisation über eine standardisierte Projektmanagementmethode, könnte bereits eine entsprechende Rolle für den stellvertretenden Sponsor definiert sein. Falls nicht, bieten sich folgende Punkte für eine Rollenbeschreibung an: Leitung bei wichtigen Entscheidungspunkten, Genehmigung von Übergängen zwischen Projektphasen, Freigabe zentraler Liefergegenstände, Entscheidungsfindung bei auftretenden Problemen, Zustimmung zu Änderungen an der Projektleistungsbasis, Bereitstellung strategischer Richtungsweisungen, Unterstützung und Coaching des Projektmanagers, Vertretung des Projekts im organisationalen Führungskreis, Sicherstellung der Verfügbarkeit notwendiger Projektressourcen und Finanzmittel gemäß dem Finanzierungsplan.

So könnte das Arbeitspaket „Nominierung eines stellvertretenden Sponsors“ Aktivitäten wie die Identifizierung einer passenden Person, Gespräche und Verhandlungen mit dieser Person sowie das Erzielen einer Übereinkunft beinhalten. Zudem mag das Arbeitspaket die Erstellung und Zustimmung einer Rollenbeschreibung umfassen, falls diese nicht schon mit dem primären Hauptsponsor abgestimmt wurde.

Antwort auf Risiko Nummer 1: Die Durchführung von Workshops zur Erfassung der Anforderungen.

Wie das Beispiel aus der Fallstudie verdeutlicht, hat das Team beschlossen, Workshops zu veranstalten, um präzisere funktionale Anforderungen für die Lösung zu erfassen. Dieses Arbeitspaket würde die Planung und Realisierung dieser Workshops umfassen, einschließlich der Auswahl relevanter Stakeholder, der Buchung eines geeigneten Raums und eventuell der Organisation der Anreise. Soll ein Moderator hinzugezogen werden? In diesem Fall beinhaltet das Arbeitspaket auch die Auswahl und Beauftragung eines solchen. Vielleicht existiert bereits ein Rahmenvertrag mit einem festen Moderator, und es geht nur darum, Termine zu koordinieren. Ist spezielle Ausrüstung wie ein Metaplan-Kasten für Moderationstechniken erforderlich? Nach der Sammlung der funktionalen Anforderungen muss das Team diese analysieren, abgleichen und priorisieren sowie einen Konsens unter den Stakeholdern herbeiführen. Eventuell sind mehrere Iterationen notwendig. All diese Schritte müssen geplant und durchgeführt werden, was wahrscheinlich Auswirkungen auf den Terminplan und die Kostenkalkulation haben wird. In den Planungsprozessen sollten Reserven für solche Unwägbarkeiten vorgesehen worden sein, die nun zum Einsatz kommen würden.

Antwort auf Risiko Nummer 2: Den Austausch des Anbieters für das Werkzeug zur Nachverfolgung des Transaktionsstatus.

In unserem Fallbeispiel stellt dies eine heikle Angelegenheit dar. Der ursprüngliche Anbieter wurde aufgrund seines konkurrenzlos niedrigen Preises ausgewählt, um eine von der Finanzabteilung vorgegebene Kostengrenze nicht zu überschreiten. Es ist notwendig, behutsam mit der Finanzabteilung zu verhandeln, um Gegenreaktionen zu vermeiden. Ideal wäre es, die Situation so zu gestalten, dass die Finanzabteilung als Urheber der neuen Lösung erscheint. Hier bietet sich eine ausgezeichnete Gelegenheit zur Anwendung von Einflussnahme. Der Sponsor könnte hierfür die ideale Person sein. Auch die Beschaffungsabteilung spielt eine Rolle. Angenommen, sie wählte den kostengünstigsten Anbieter aus, weil unsere Beteiligung am Auswahlprozess nicht ausreichte, um sicherzustellen, dass auch andere wichtige Kriterien angemessen berücksichtigt wurden. Diesmal werden wir uns intensiver und effektiver einbringen. Die Vorgehensweise bei der Anbieterauswahl wird im Detail in der Lektion „Beschaffungen durchführen“ behandelt. Konsultieren Sie diese Lektion, falls notwendig. Möglicherweise gestaltet sich der Prozess einfacher, und wir können einfach den zweiten oder dritten Kandidaten von der Liste potenzieller Anbieter wählen. Die Risikoreserven sollten bereits in den Planungsprozessen festgelegt worden sein.

Antwort auf Risiko Nummer 3: Beauftragung eines Dienstleisters für trianguläre Zahlungen.

Für diese Maßnahme können wir dem in der Lektion „Beschaffungen durchführen“ dargelegten Verfahren folgen. Das bedeutet, wir beginnen mit der Erstellung einer langen Liste potenzieller Dienstleister, verengen diese Auswahl auf eine mittlere Liste von Kandidaten, fordern Angebote an und bewerten diese, um zu einer kurzen Liste zu kommen. Der abschließende Schritt umfasst die Verhandlung mit den drei Finalisten und die Vergabe des Auftrags. Risikoreserven sollten während der Planungsprozesse angelegt worden sein.

Zusammenfassend kann festgehalten werden, dass die Umsetzung der Risikoantworten in Arbeitspakete resultiert, die – wie alle anderen Arbeitspakete auch – definiert, geplant und ausgeführt werden müssen. Im Laufe der Planungsprozesse haben wir Risikoreserven angelegt, um die Mehrarbeit, die durch die Risikobewältigungsstrategien entsteht, abzufangen. Bei den Ausführungsprozessen konzentrieren wir uns nun darauf, die während der Planung festgelegten Risikobewältigungsstrategien in die Praxis umzusetzen.

 

 

 

3.11 Projektwissen managen und Prozesse durch Retrospektiven optimieren

In diesem Abschnitt geht es darum, wie vorhandenes Wissen genutzt und neues Wissen im Laufe des Projekts gemeinsam erarbeitet wird, einschließlich des Lernprozesses im Team. Ziel ist es, eine Umgebung zu schaffen, in der Teammitglieder und andere Beteiligte ihr Wissen und ihre Fähigkeiten einbringen und nutzen können. Es geht auch darum, dass das Team durch Austausch und Verbindung von Informationen, Wissen und Ideen neues Wissen generiert.

Allerdings ist Wissen an die Personen gebunden, die es besitzen. Es lässt sich niemand dazu zwingen, sein Wissen zu teilen oder auf das Wissen anderer zu achten. Oft wird vorhandenes Wissen im Team nicht automatisch geteilt oder genutzt, was zu Verschwendung führen kann.

Um Personen zu ermutigen, ihr Wissen zu teilen und sich für das Wissen anderer zu öffnen, ist es wichtig, ein Klima des Vertrauens, Teamgeists und qualitativ hochwertige Interaktionen zu fördern. Ebenso wichtig ist es, die Nutzung von Projektdokumentationen zu vereinfachen.

Diese Punkte haben wir bereits in den Abschnitten zur Teamführung und -entwicklung sowie im Kapitel zum Management der Kommunikation und des Stakeholderengagements erörtert.

Als nächstes möchten wir uns dem Thema Rückmeldung zuwenden, das eng mit dem Sammeln und Nutzen von Erfahrungen verbunden ist. Eine wichtige Technik dabei sind retrospektive Sitzungen.

Retrospektiven ermöglichen es dem Team, durch gemeinsame Reflexion neues Wissen zu sammeln und Arbeitsabläufe zu optimieren. Ziel ist es, das Team regelmäßig dazu anzuregen, über die Verbesserung und Anpassung ihres Verhaltens nachzudenken, um ihre Effizienz und Effektivität zu steigern.

Ein retrospektives Meeting ist sinnvoll, sobald das Team einen Meilenstein erreicht hat. Es ist nicht zweckmäßig, mit der Reflexion bis zum Projektende zu warten, um Verbesserungspotenziale zu identifizieren. Vielmehr ist es effektiver, Zwischenretrospektiven abzuhalten, die es ermöglichen, Optimierungen vorzunehmen, solange das Projekt aktiv ist. Phasenübergänge sowie Meilensteine innerhalb einer Projektphase bieten ideale Anlässe hierfür. Retrospektive Sitzungen können ebenfalls in festgelegten Intervallen oder zu Zeiten erfolgen, wenn das Team auf Schwierigkeiten stößt und die Arbeit nicht flüssig vorangeht. In agilen Kontexten finden Retrospektiven regelmäßig am Ende jeder Iteration statt, die üblicherweise eine Dauer von zwei Wochen hat.

Eine Retrospektive dient keinesfalls der Schuldzuweisung oder der Suche nach Verantwortlichen für etwaige Probleme. Vielmehr bietet sie dem Team die Chance, aus den kürzlich gemachten Erfahrungen zu lernen und sich weiterzuentwickeln.

Die Retrospektive zielt nicht darauf ab, das Produkt selbst zu begutachten. Diese Aufgabe fällt dem Treffen zur Überprüfung eines Liefergegenstandes zu, wie in der Lektion über die Definition, Delegation und Genehmigung von Arbeitspaketen beschrieben.

Die retrospektive Sitzung richtet ihren Fokus auf die Qualität der Arbeitsabläufe, der eingesetzten Methoden und Werkzeuge sowie auf die Interaktionen im Team, einschließlich Empfindungen und Stimmungen. Zudem widmet sie sich der Ursachensuche bei aufgetretenen Problemen. Es werden Gegenmaßnahmen erarbeitet und konkrete Aktionspläne entwickelt, um die Arbeitsprozesse zu optimieren.

Die Tagesordnung einer retrospektiven Sitzung könnte folgendermaßen gestaltet sein:

• Rückblick auf die Entwicklungen des letzten Arbeitszeitraums mit Fokus auf Interaktionen, Arbeitsabläufe und eingesetzte Werkzeuge.
• Herausstellen der Aspekte, die erfolgreich waren, sowie der Bereiche, die Verbesserungsmöglichkeiten aufweisen.
• Festlegung von Maßnahmen zur Umsetzung der identifizierten Verbesserungen.

Es ist entscheidend, dass zu Beginn einer retrospektiven Besprechung alle Teilnehmenden aktiv einbezogen werden. Indem man es zulässt, dass einige zu Beginn schweigen, könnte fälschlicherweise der Eindruck entstehen, Nichtbeteiligung sei akzeptabel. Schweigen wirkt sich negativ aus, da das Kernziel einer Retrospektive darin besteht, die Teilnehmenden zum Austausch darüber anzuregen, wie die vergangenen Prozesse verlaufen sind und welche Pläne und Hoffnungen sie für die Zukunft hegen. Eine effektive Methode, um frühzeitig Gespräche anzuregen, ist die Aufforderung an jeden Teilnehmenden, seine Erwartungen an die Retrospektive zu formulieren. Sollte dieser Ansatz auf Dauer zu monoton werden, könnte man die Beteiligten bitten, ihre Gefühle im zurückliegenden Zeitraum sowie ihre Einschätzungen zum Teamfortschritt zu teilen. Es ist wichtig zu betonen, dass es keine “richtigen” oder “falschen” Gefühle gibt – Gefühle sind objektive Tatsachen. Erinnern Sie sich an das Beispiel von „Teamstatuten“, in denen die gemeinsamen Werte des Teams festgehalten wurden? Hier ein Beispiel für Teamwerte, wie sie in der Lektion zum „Entwickeln des Projektteams“ vorgestellt wurden:

• Wir schieben Aufgaben nicht auf, die heute erledigt werden können, und kommunizieren regelmäßig und rechtzeitig unseren Fortschritt.
• Wir stützen uns auf möglichst wenige Annahmen und bevorzugen es, Entscheidungen auf der Basis von Daten und Fakten zu treffen.
• Wir respektieren während Diskussionen das Rederecht jedes Einzelnen und werten unterschiedliche Perspektiven als Bereicherung.
• Jedes Teammitglied wird ermutigt, seine Meinung zu äußern. Schweigen gilt nicht als Zustimmung oder Ablehnung.
• Bei Problemen suchen wir nicht nach Schuldigen oder Ausreden, sondern bemühen uns, die Ursachen zu analysieren und konstruktive Lösungen zu finden.

Eine weiße Tafel und Haftzettel sind hilfreich, um bewährte Problemlösungsmethoden wie Ideensammlung, das Ishikawa-Diagramm (auch bekannt als Ursache-Wirkungs-Diagramm) und die Fünf-Warum-Fragestellung anzuwenden.

Wenn die Diskussion von ein oder zwei Personen beherrscht wird, sollte der Leiter der Sitzung einschreiten und andere Teilnehmende zur aktiven Beteiligung ermutigen, um eine ausgewogene Beteiligung zu gewährleisten.

Das Ergebnis kann eine umfangreiche Liste von notwendigen Maßnahmen sein, um Hindernisse zu beseitigen. Um diese Maßnahmen zu priorisieren, kann das Mehrfachpunkte-Abstimmungsverfahren angewendet werden. Dabei könnte jedem Teilnehmenden beispielsweise eine bestimmte Anzahl an Punkten gegeben werden, die er auf die identifizierten Probleme verteilen kann, abhängig davon, welche ihm am wichtigsten erscheinen. Das Problem, das die meisten Punkte erhält, wird als das Wichtigste für die Gruppe angesehen. Die drei Probleme mit den meisten Punkten werden zu den Prioritäten A, B und C, in der Reihenfolge ihrer erhaltenen Punkte.

Nach der Priorisierung der Verbesserungsansätze durch das Team, entscheidet dieses, welche Anzahl an Punkten im nächsten Arbeitszeitraum angegangen wird. Es ist ratsam, die Menge der Aktionspunkte zu begrenzen. Manche Teams legen ihren Fokus auf ein bis zwei wesentliche Aspekte, die im folgenden Zeitraum optimiert werden sollen. Der Versuch, zu viele Bereiche gleichzeitig zu verbessern, kann zu Enttäuschungen führen, besonders wenn viele der Vorhaben nicht erfolgreich umgesetzt werden. Bei der Auswahl der Verbesserungen, auf die sich das Team konzentrieren möchte, ist ebenfalls festzulegen, wie der Erfolg der umgesetzten Maßnahmen bewertet werden soll.

Manche Themen könnten tiefgreifendere Probleme offenlegen, die nicht innerhalb einer einzigen Sitzung bewältigt werden können. Diese sollten in das Problemregister aufgenommen und der im Projektmanagementplan festgelegte Problemlösungsprozess sollte darauf angewendet werden, auch wenn sie nicht zur Entscheidungsfindung an den Projektsponsor weitergeleitet werden. Der Grund hierfür ist, dass das etablierte Problemlösungsverfahren die notwendigen Schritte umfassen sollte, inklusive der Ermittlung der Hauptursache des Problems und der Bewertung alternativer Lösungsansätze. Bei Bedarf sollte die Lektion über Problemlösung konsultiert werden.

Im darauffolgenden Arbeitszeitraum sollten dann die Ergebnisse gemessen werden, um den Erfolg oder das Ausbleiben des Erfolgs jeder durchgeführten Verbesserung zu bewerten.

Zusammenfassend liegt unser Fokus in den Prozessen des Managements von Projektwissen und der Optimierung durch Retrospektiven darauf, die vorhandenen Fähigkeiten und Erfahrungen im Projekt nutzbar und zugänglich zu machen. Unser Bestreben ist es zudem, durch den Austausch und die Verknüpfung von Informationen, Wissen und Ideen neues Wissen zu generieren. Die Bedeutung von Projektdokumentation und Werkzeugen für das Informationsmanagement steht außer Frage. Doch ohne ein Fundament aus Vertrauen und einem kooperativen Teamgeist können diese Werkzeuge ihre volle Wirkung nicht entfalten. Regelmäßig stattfindende retrospektive Teamtreffen bieten eine hervorragende Möglichkeit, Lernprozesse zu unterstützen und die Effizienz von Arbeitsprozessen fortlaufend zu steigern.

 

 

4.1 Überblick über Projektcontrolling

Der Zweck der Projektkontrolle besteht darin, den aktuellen Zustand des Projekts zu verstehen, seinen zukünftigen Zustand durch Kosten- und Zeitabschätzungen vorherzusehen und nach Bedarf korrektive und präventive Maßnahmen einzuleiten.

In den nachfolgenden Lektionen werden wir die Prozesse und Methoden der Projektüberwachung erläutern, um Planabweichungen frühzeitig zu erkennen und deren Konsequenzen zu bewerten. Darüber hinaus werden korrektive Maßnahmen diskutiert, die darauf abzielen, diese Abweichungen zu korrigieren. Wir werden auch die Technik der Fertigstellungswertanalyse (Earned Value Analysis, EVA) einführen, die eine integrierte Sicht auf Kosten, Termine und Arbeitsumfang bietet und eine effektive Überwachung sowie Steuerung von Projekten durch das Vergleichen der geplanten mit der tatsächlich erzielten Leistung ermöglicht.

Der Projektmanagementplan integriert den Fortschrittsmessungsbasisplan (Performance Measurement Baseline) sowie weitere Managementhilfspläne. Jeder Plan erfordert einen Kontrollprozess, um den Fortschritt im Rahmen des Plans zu überwachen. Bei Abweichungen ist es entscheidend, deren jeweiligen Einfluss auf den Projektmanagementplan zu verstehen und geeignete Maßnahmen zu ergreifen. Dementsprechend erstrecken sich die Prozessekontrolle – also die Überwachungs- und Steuerungsaktivitäten – über alle Bereiche des Projektmanagementplans.

Hier folgt eine Übersicht der Bestandteile des Projektcontrollings:

4.2 Kontrolle des Inhalts- und Umfangsbasisplans.

4.3 Kontrolle des Terminbasisplans.

4.4 Kontrolle des Kostenbasisplans.

4.5 Kontrolle der Qualität.

4.6 Kontrolle der Probleme.

4.7 Kontrolle der Änderungen.

4.8 Kontrolle der Risiken, der Kommunikationseffektivität und des Stakeholderengagements, der Beschaffungen und der materiellen Ressourcen.

4.9 Kontrolle der Phasenübergänge.

 

 

 

 

4.2 Kontrolle des Inhalts- und Umfangsbasisplans

Dieser Abschnitt befasst sich mit der Unvermeidbarkeit von Projektänderungen, sowie mit einem soliden Prozess zur Kontrolle von Umfangsänderungen.

Stellen Sie sich vor, Sie treffen einen leitenden Angestellten Ihres Unternehmens auf dem Flur, der Ihnen sagt: ‘Hallo, bla bla bla… Es ist wesentlich, dass die Lösung unseres Projekts dies und das beinhaltet. Könnten Sie sich darum kümmern?’ Und der leitende Angestellte eilt zu einem Meeting. Es ist sehr wahrscheinlich, dass diese Person erwartet, oder zumindest wünscht, dass Sie eine Änderung am Projekt vornehmen, ohne die Fristen oder das Budget zu ändern. Vielleicht denken Sie, dass ein ‘Ja, Sir’ eine kundenorientierte Antwort ist. Aber in Wirklichkeit ist dies das, was wir als ‘Scope Creep’ bezeichnen. Es ist eine unkontrollierte Ausweitung des Umfangs, ohne Anpassungen am Terminplan, den Kosten und den Ressourcen.

Es gibt viele Gründe, warum der genehmigte Inhalts- und Umfangsbasisplan geändert werden kann. Beispielsweise wurde der Umfang möglicherweise anfangs nicht klar definiert.  Manchmal kommunizieren Kunden nicht alles, was sie benötigen, während die Anforderungen gesammelt werden. Vielleicht war Ihr Prozess zur Ermittlung der Anforderungen fehlerhaft. Oder vielleicht wusste der Kunde nicht genau, was er wollte, als die Anforderungen gesammelt wurden.

Die Tatsache ist, dass wenige Kunden von Anfang an alle funktionalen Anforderungen und alle Qualitätsattribute der gesuchten Lösung ausdrücken können. Daher sollten Änderungen erwartet werden, während das Projekt voranschreitet. Der Schlüsselpunkt des Inhalts- und Umfangscontrollings besteht darin, diese Änderungsanforderungen durch einen vordefinierten Prozess zur Steuerung von Inhalts- und Umfangsänderungen zu kanalisieren, um zu vermeiden, dass der Projektleiter dem Kunden ein “Nein” sagen muss.

Es ist nicht die Aufgabe des Projektleiters, ein “Ja” oder “Nein” zu einer Umfangsänderungsanforderung zu sagen, sondern vielmehr sicherzustellen, dass alle Änderungsanforderungen angemessen bewertet, dokumentiert und gegebenenfalls genehmigt werden.

Wenn Sie bei der Planung gute Arbeit geleistet haben, sollten Sie eine Änderungssteuerungsinstanz definiert haben, die bei einem großen Projekt ein Ausschuss oder bei einem kleineren Projekt der Auftraggeber (Sponsor) sein kann. Diese Änderungssteuerungsinstanz trifft Entscheidungen über Änderungen am genehmigten Inhalt und Umfang und die Auswirkungen dieser Änderungen auf den Fortschrittsmessungsbasisplan. Es kann auch Auswirkungen auf andere Teile des Projektmanagementplans geben.

Die Rolle des Projektleiters in diesem Prozess besteht darin, die notwendigen Informationen bereitzustellen. Der Sponsor muss den Zweck der Änderung kennen, also warum sie notwendig ist, sowie deren Auswirkungen auf das Projekt in Bezug auf Kosten, Termine, Qualität und Risiken. Die Rolle des Sponsors besteht darin, Entscheidungen “rechtzeitig” zu treffen, basierend auf diesen Informationen. “Rechtzeitig” bedeutet im richtigen Moment, auch wenn die erforderlichen Entscheidungen mutig sein könnten. Dies ist einer der Gründe, warum jedes Projekt unbedingt einen engagierten Sponsor benötigt.

Hier ist ein Prozess, der Ihnen helfen wird, die Änderungen am Inhalt und Umfang unter Kontrolle zu halten:

1. Um Änderungen am Inhalt und Umfang des Projekts zu kontrollieren, sollten zunächst alle Inhalt- und Umfangsänderungen schriftlich beantragt und an den Projektleiter gerichtet werden. Dies kann beispielsweise durch die Verwendung eines Formulars für Inhalt- und Umfangsänderungsanträge erfolgen. Bei einem weniger formalen Prozess könnte auch eine einfache E-Mail ausreichen.
2. Wenn jemand den Bedarf an einer Inhalt- und Umfangsänderung äußert, ist es wichtig, ihn daran zu erinnern, dass unser Projektmanagementplan die Einreichung schriftlicher Inhalt- und Umfangsänderungsanträge vorsieht. Zweitens, überprüfen Sie sorgfältig, ob es sich tatsächlich um eine Änderung des Inhalts und Umfangs handelt. Nicht alle Änderungen qualifizieren sich als Inhalt- und Umfangsänderungen. Zum Beispiel ist es keine Inhalt- und Umfangsänderung, wenn ein Lieferant die Person wechselt, die für Ihr Arbeitspaket verantwortlich ist. Obwohl dies ein Risiko darstellen kann, wenn die neue Person weniger fähig ist als die vorherige, handelt es sich nicht um eine Änderung des Inhalts und Umfangs. Möglicherweise liegt ein Problem vor, der sich anders als durch eine Inhalt- und Umfangsänderung lösen lässt.
3. Sobald Sie wissen, dass es sich tatsächlich um einen Antrag auf eine Inhalts- und Umfangsänderung handelt, tragen Sie den Punkt in das Änderungsregister zur Nachverfolgung ein. Dieses Register kann ein zusammenfassendes Tabellenblatt sein, mit dem Sie alle Änderungsanträge verfolgen können, jeweils mit einer eindeutigen Kennung.
4. Danach bitten Sie die Person, die die Änderung anfordert, den Zweck der Änderung zu erklären, also warum wir sie benötigen. Der Sponsor benötigt diese Informationen für seine Entscheidung.
5. Anschließend definiert der Projektleiter ein Arbeitspaket, um den Einfluss der Änderung auf den Projektbasisplan, mögliche Alternativen und damit verbundene Risiken zu untersuchen.
6. Daraufhin präsentiert der Projektleiter den Antrag auf Inhalts- und Umfangsänderung, dessen Zweck, die Alternativen und die Bewertung seiner Auswirkungen auf den Projektbasisplan der Änderungskontrollinstanz zur Entscheidungsfindung. Die Änderungskontrollinstanz muss den Antrag genehmigen oder ablehnen, einschließlich der Auswirkungen der Änderung auf den Projektmanagementplan. Anschließend trägt der Projektleiter die Entscheidung in das Änderungsregister ein.
7. Der nächste Schritt besteht darin, den Projektmanagementplan entsprechend zu aktualisieren. Dies könnte neue Aktivitäten im Terminbasisplan sowie möglicherweise neue Kosten im Kostenbasisplan umfassen. Außerdem könnten neue Maßnahmen zur Risikobewältigung erforderlich sein.
8. Schließlich kommuniziert der Projektleiter die Entscheidung über die Inhalts- und Umfangsänderung an die Teammitglieder und andere geeignete Stakeholder, wie im Kommunikationsmanagementplan festgelegt. Es ist wichtig zu beachten, dass Änderungen am Projektbasisplan standardmäßige Elemente in den Projektstatusberichten sowie in den Tagesordnungen der Fortschrittsbesprechungssitzungen sind.
9. Diese Änderungen am Inhalt und Umfang, sobald sie genehmigt sind, werden wie jedes andere Arbeitspaket umgesetzt. Falls notwendig, überprüfen Sie die Lektion über die Implementierung genehmigter Änderungen und korrektiver Maßnahmen, die Teil der Lektionen zur Projektausführung sind.

Es gibt jedoch einen besonderen Fall in diesem Verfahren, und zwar dann, wenn das Arbeitspaket zur Untersuchung der Auswirkungen einer Änderungsanfrage einen erheblichen Aufwand erfordert. Dies kann dazu führen, dass entweder die Risikoreserve des Arbeitspakets oder das Kontrollkonto, zu dem das Arbeitspaket gehört, gefährdet oder überschritten wird. Möglicherweise sind bedeutende Ingenieursarbeiten erforderlich, und das alles für eine Änderungsanfrage, die noch nicht einmal genehmigt wurde. In einem solchen Szenario wird das Arbeitspaket zur Untersuchung der Auswirkungen der Änderungsanfrage selbst zu einer Änderungsanfrage.

Der Projektleiter muss zunächst die Genehmigung einholen, um mit den Studienarbeiten zur Bewertung der Auswirkungen der Änderungsanfrage zu beginnen. Wenn der Sponsor dies ablehnt, bedeutet dies automatisch die Ablehnung der ursprünglichen Änderungsanfrage. Diese Ablehnung muss im Änderungsregister vermerkt und gemäß dem Kommunikationsmanagementplan kommuniziert werden.

Rationalisierung des Änderungsmanagementprozesses.

Hier sind einige zusätzliche Ideen, die Ihnen helfen können, Ihren Prozess zur Kontrolle des Projektinhalts und -umfangs zu rationalisieren:

Ihr Projektmanagementplan kann vorsehen, dass Änderungen am Inhalt und Umfang bis zu einem bestimmten definierten Schwellenwert direkt vom Projektleiter genehmigt werden können. Diese delegierte Autorität sollte entweder im Projektauftrag (Charter) oder im Änderungsmanagementverfahren klar definiert sein.

Eine weitere Idee zur Vereinfachung des Änderungsmanagementprozesses besteht darin, einen festen Wert im Projektbasisplan festzulegen, der für zukünftige Änderungen des Inhalts- und Umfangs vorgesehen ist. Letztendlich wissen wir, dass es sehr wahrscheinlich ist, dass Änderungen am Inhalt und Umfang eintreten können, auch wenn wir nicht wissen, welche es sind. Denken Sie daran, dass Risikoreserven in dem genehmigten Inhalts- und Umfangsbasisplan nicht dasselbe sind wie ein Budgetposten zur Abdeckung von Änderungen an diesem Inhalt und Umfang. Verwenden Sie keine Risikoreserven für den genehmigten Inhalt und Umfang, um eine Ausweitung des Inhalts und Umfangs zu bewältigen. Diese Elemente sind von unterschiedlicher Natur, und Sie werden es bereuen, wenn Sie dies tun. Die Risikoreserven dienen den Fall von Mehrarbeit als geschätzt beim genehmigten Inhalt und Umfang. Das ist nicht dasselbe wie die Definition eines zusätzlichen Inhalts und Umfangs.

Nach diesen Ausführungen könnte man denken, dass Änderungen am Projektinhalt und -umfang willkommen sind, solange sie einen formellen Genehmigungsprozess unter der Leitung der Änderungskontrollinstanz durchlaufen. Dies ist zwar richtig, aber es gibt Einschränkungen. Es gibt nämlich bestimmte Zeitpunkte, an denen zusätzliche Änderungen am Inhalt und Umfang sehr störend sein können, insbesondere wenn sich das Projekt bereits auf die Implementierungsphase einer bereits entwickelten und getesteten Lösung vorbereitet. In diesem Stadium ist der beste Ansatz, neue Änderungsanfragen in einem Produktbacklog zu erfassen, das ist ein Register von Arbeiten im Standby, und sie als Änderungsanfragen zu behandeln, erst wenn die Lösung implementiert und stabil ist. Es ist wichtig zu beachten, dass sich dies auf Änderungsanfragen bezieht und nicht auf eventuelle Mängel, die vor der Implementierung behoben werden müssen.

Ein Backlog kann auch verwendet werden, um Änderungen zu erfassen, die als nützlich erachtet werden, aber aus gültigen Gründen nicht in der aktuellen Version der Lösung implementiert werden können. Sobald das ursprüngliche Projekt abgeschlossen ist, können diese Änderungen in einer neuen Version des Produkts umgesetzt werden.

Wenn der Kunde noch nicht genau weiß, was er will, sollten Sie einen inkrementellen, einen iterativen Ansatz oder beides (das ist der Agile Ansatz) in Betracht ziehen. Auf diese Weise haben sowohl Sie als auch der Kunde Gelegenheiten, die Anforderungen und den sich daraus ergebenden Inhalt und Umfang jeder Iteration besser zu verstehen.

Zusammenfassend lässt sich sagen, dass die beste Art, den Inhalt und Umfang zu managen, darin besteht, ihn von Anfang an gut zu definieren. Dies ist jedoch nicht immer möglich, und daher müssen wir mit Änderungsanträgen rechnen. Verwenden Sie einen vordefinierten Prozess für die Steuerung von Inhalts- und Umfangsänderungen. Die Rolle des Projektleiters besteht darin, Informationen über die Auswirkungen der Änderungsanträge an die Änderungskontrollinstanz zu liefern. Die Aufgabe der Änderungskontrollinstanz ist es, Änderungsanträge zu genehmigen oder abzulehnen sowie die damit verbundenen Anpassungen im Projektmanagementplan vorzunehmen. Verwenden Sie ein Register für anstehende Arbeiten, technisch als ‘Backlog’ bezeichnet, für Änderungen, die sinnvoll sind, aber nicht in der aktuellen Version der Lösung implementiert werden. Wenn der Kunde noch nicht genau weiß, was er will, erwägen Sie die Verwendung eines inkrementellen, iterativen oder agilen Ansatzes.

 

 

 

 

 

4.3 Kontrolle des Terminbasisplans

Dieser Abschnitt widmet sich der Überwachung des Projektterminplans und den Techniken, die dazu beitragen, diesen zu steuern. Wir werden drei Schlüsselaspekte der Terminsteuerung behandeln:

• Erstens: Ein Überwachungsprozess, der prüft, ob die Arbeiten gemäß dem Terminbasisplan fortschreiten.
• Zweitens: Das Verständnis der Auswirkungen, die Verzögerungen auf die Gesamtdauer des Projekts haben können.
• Drittens: Die korrektiven Maßnahmen, die ergriffen werden können, um Verzögerungen effektiv aufzuholen.

Nummer eins: Überwachung des Terminbasisplans.

Der Prozess beginnt mit der Aktualisierung des Terminplans, basierend auf den neuesten Informationen, die gemäß der im Terminmanagementplan festgelegten Frequenz und Werkzeugen eingehen. Teammitglieder oder Verantwortliche für Arbeitspakete übermitteln Daten an den Projektmanager, die den Fortschrittsstatus der Aktivitäten während des letzten Arbeitszeitraums widerspiegeln. Falls das Management von tatsächlichen Arbeitsstunden erforderlich ist, sollten Teammitglieder ihre tatsächlichen Arbeitsaufwände für jede Aufgabengruppe berichten. Es ist anzumerken, dass diese Tätigkeit oft als unpopulär gilt. Der Berichtsprozess kann entweder manuell mit Tabellenkalkulationen, die an Statusberichte angehängt werden, oder mittels spezialisierter Softwareanwendungen durchgeführt werden. Der Terminplan wird mit diesen Informationen stetig aktualisiert. In umfangreichen Projekten kann diese Aufgabe einem Projektcontroller übertragen werden.

Der nächste Schritt ist die Analyse des Terminplans. Identifizieren Sie Aktivitäten oder zusammenfassende Aktivitäten, die bereits hätten abgeschlossen sein sollen, es jedoch noch nicht sind. Arbeiten Sie eng mit den zuständigen Personen zusammen, um die Ursachen für Verzögerungen zu ermitteln. Setzen Sie Problemlösungstechniken ein, um diese Herausforderungen zu adressieren oder deren Auswirkungen abzumildern. Schätzen Sie gemeinsam mit den Teammitgliedern den verbleibenden Arbeitsaufwand sowie die dafür benötigte Dauer ab.

 

Verwenden Sie in Ihrer Analyse die folgenden weichen Indikatoren für Terminplanrisiken:

• Eine anfängliche kleine Abweichung beginnt sich zu verschlechtern, besonders zu Beginn des Projekts.
• Zusammenfassende Aktivitäten, die als abgeschlossen gelten sollten, sind noch im Gange, möglicherweise aufgrund einer unklaren Definition von “abgeschlossen’, die keine Zustimmung zu bestimmten Tests einschließt.
• Das Team leistet Überstunden, um Zwischenfristen zu erfüllen, insbesondere zu Projektbeginn, was langfristig nicht nachhaltig ist.
• Der Arbeitsfortschritt erscheint zwar termingerecht, jedoch mit vielen Fehlern oder einer Verdünnung des vereinbarten Umfangs.
• Die Moral des Teams ist rückläufig.

Früher oder später werden diese Situationen den Terminplan beeinflussen. Je früher Sie die zugrunde liegenden Ursachen dieser Symptome korrigieren, desto besser.

Nummer zwei: Verstehen der Auswirkungen der erkannten Verzögerungen auf die Gesamtdauer des Projekts.

Sie erreichen dies, indem Sie den kritischen Pfad des Projekts analysieren. Jeder Projektterminplan enthält einen kritischen Pfad, der die längste Abfolge von aufeinanderfolgenden Aktivitäten darstellt.

Warum ist der kritische Pfad so entscheidend?

Es gibt drei Hauptgründe:

• Erstens, jede Verzögerung bei einer Aktivität auf dem kritischen Pfad beeinflusst direkt die Fertigstellungszeit des gesamten Projekts.
• Zweitens, durch eine Verkürzung des kritischen Pfades kann potenziell auch die Gesamtdauer des Projekts reduziert werden.
• Drittens, der kritische Pfad bietet eine frühe Einsicht in die potenziellen Auswirkungen von Verzögerungen auf die Projektlaufzeit. Diese Einsicht ist entscheidend, um zu bestimmen, auf welche Aktivitäten man sich konzentrieren und wo frühzeitig korrektive Maßnahmen eingeleitet werden sollten.

Wie kann man feststellen, welche Aktivitäten auf dem kritischen Pfad liegen? Es ist wesentlich, zu erkennen, welche Aktivitäten einen Terminspielraum besitzen und welche nicht. Der Terminspielraum, auch als Schlupf (auf Deutsch) und Slack (auf Englisch) bekannt, beschreibt die Zeitspanne, innerhalb derer eine Aktivität verzögert werden kann, ohne die darauffolgende Aktivität zu beeinträchtigen – dies wird als freier Terminspielraum bezeichnet. Der Gesamtterminspielraum ist die maximale Verzögerungszeit einer Aktivität, die möglich ist, ohne das geplante Enddatum des Projekts zu gefährden.

Aktivitäten mit einem Terminspielraum können sich bis zum vollständigen Verbrauch dieses Spielraums verzögern, ohne die Gesamtdauer des Projekts zu beeinflussen. Diese Aktivitäten sind nicht auf dem kritischen Pfad.

Andererseits müssen Aktivitäten ohne Terminfreiraum strikt gemäß der Planung beginnen und enden, da jede Verzögerung direkt das Projektenddatum beeinflusst. Diese Aktivitäten befinden sich auf dem kritischen Pfad und werden auch als kritische Aktivitäten bezeichnet. Es ist wichtig zu verstehen, dass diese nicht notwendigerweise die wichtigsten oder schwierigsten Aktivitäten im Projekt sind. Vielmehr sind sie kritisch, weil sie keinen Spielraum für Verzögerungen bieten.

Wenn Ihr Projekt klein ist und der Gantt-Diagramm leicht überwacht werden kann, können Sie die Terminfreiraum visuell erkennen, wie in diesem Beispiel.

Bei größeren Projekten empfiehlt es sich jedoch, ein Planungstool zu verwenden, das den kritischen Pfad automatisch berechnet. Normalerweise wird dieser als eine ‘rote Kette von Aktivitäten’ dargestellt. Diese kritischen Aktivitäten erfordern Ihre besondere Aufmerksamkeit.

Der kritische Pfad ist eine Schlüsseltechnik, die nicht nur zur Bestimmung der Gesamtdauer eines Projekts dient, sondern auch aufzeigt, ob und inwieweit die Verzögerung einer einzelnen Aktivität oder einer Gruppe von Aktivitäten das Projektenddatum beeinflusst. Daher ist er ein unverzichtbares Werkzeug für die Steuerung des Terminplans eines Projekts.

Nummer drei: Welche Korrekturmaßnahmen können wir für kritische Aktivitäten einsetzen, um festgestellte Verzögerungen auszugleichen?

Folgende Optionen stehen zur Verfügung:

• Anpassung der Normalabfolge.
• Einführung von Überstunden.
• Verdichtung des Terminplans durch Hinzufügen von Ressourcen.
• Beschleunigte Ausführung durch Parallelisierung von Vorgängen.
• Optimierung der Prozesse.
• Präventive Maßnahmen.
• Stärkung der Moral und Erneuerung der Verpflichtungen.

Lassen Sie uns diese Optionen im Detail betrachten.

Anpassung der Normalabfolge.

Anordnungsbeziehungen in einem Terminplan legen fest, in welcher zeitlichen Reihenfolge die einzelnen Vorgänge umgesetzt werden müssen. Zum Beispiel ist es beim Hausbau erforderlich, zuerst das Fundament zu gießen, bevor die Wände errichtet werden. Diese Form der Anordnungsbeziehung wird als „zwingende Abhängigkeit“ klassifiziert.

Aus rein technischer Sicht könnten Sie ein Elektrikerteam parallel zu einem Team arbeiten lassen, das sich um die Wasseranschlüsse kümmert. Bevorzugen Sie jedoch aus spezifischen Gründen, dass das Team für die Wasseranschlüsse erst nach Abschluss der Elektrikerarbeiten beginnt, etablieren Sie eine “bevorzugte Abhängigkeit” des Typs „Normalabfolge“. Eine parallele Durchführung der Vorgänge wäre technisch möglich, doch Sie entscheiden sich für eine sequenzielle Ausführung. Dies ist ein Beispiel für bevorzugte Abhängigkeiten, die wir im Zuge der Suche nach Möglichkeiten zur Komprimierung des Terminplans identifizieren und möglicherweise neu definieren möchten. Da die sequenzielle Durchführung zwar bevorzugt, aber nicht zwingend notwendig ist, wollen wir prüfen, ob eine parallele Ausführung machbar ist, um Verzögerungen im Terminplan auszugleichen, indem wir die Art der Anordnungsbeziehung anpassen.

Ein ähnliches Szenario betrifft die Normalabfolgen, die irrtümlich festgelegt wurden. Manchmal legt das Team für mehrere Vorgänge eine Normalabfolge fest, doch eine nachträgliche Überprüfung zeigt, dass diese Art von Abhängigkeit tatsächlich nicht zwingend ist.

Der Ansatz besteht darin, das Team dazu aufzufordern, diese optionalen Normalabfolgen zu identifizieren und zu prüfen, ob Änderungen möglich sind. Dies ist der erste zu überprüfende Punkt, da er erhebliches Zeitersparnispotenzial bietet. Wenn beispielsweise ein Vorgang so geplant war, dass er erst nach Abschluss eines vierwöchigen Vorgängers beginnen sollte, aber wir nun erkennen, dass beide tatsächlich parallel starten könnten, würden wir vier Wochen Zeit gewinnen, ohne zusätzliche Kosten für Überstunden oder zusätzliche Ressourcen zur Beschleunigung der Arbeit aufwenden zu müssen.

Überstundenarbeit ist eine weitere offensichtliche Option.

Überstundenarbeit stellt eine weitere offensichtliche Option dar. Zwar ist sie bei den meisten Beteiligten unbeliebt, doch erweist sie sich als logischer Ansatzpunkt, wenn die Projektdauer direkt von der Anzahl der Arbeitsstunden abhängt. Überstunden ermöglichen es dem Team, in derselben Zeitspanne mehr Arbeit zu leisten. Sie werden häufig gegen Ende des Projekts eingesetzt, wenn ein letzter Anstrengungsschub nötig ist, um die Fristen einzuhalten. Befindet sich das Projekt jedoch noch in einer frühen Phase, gibt es wahrscheinlich effizientere Maßnahmen. Überstunden können die Projektkosten beeinflussen, insbesondere wenn sie zu einem höheren Tarif als die reguläre Arbeitszeit vergütet werden. Zudem kann die Motivation des Teams durch zu viele Überstunden beeinträchtigt werden, sodass motivierende Maßnahmen notwendig sind, um die Moral zu stärken.

Verdichtung des Terminplans durch Hinzufügen von Ressourcen.

Die Verdichtung durch Hinzufügen von Ressourcen, auch als “Crashing” bekannt, ist eine weitere Methode zur Beschleunigung des Terminplans. Dabei werden zusätzliche Ressourcen für Aktivitäten auf dem kritischen Pfad bereitgestellt. Statt die vorhandenen Ressourcen zu Überstunden zu veranlassen, werden mehr Ressourcen eingesetzt. Je nach Art der zusätzlichen Ressourcen und deren Herkunft kann dies jedoch auch zu erhöhten Kosten führen. Es ist daher wichtig, die Kosten-Nutzen-Relation dieser Maßnahme sorgfältig zu bewerten, bevor eine Entscheidung getroffen wird.

Beschleunigte Ausführung durch Parallelisierung von Vorgängen.

Beschleunigte Ausführung durch Parallelisierung von Vorgängen, oft als „Fast Tracking“ bezeichnet, ähnelt der Anpassung der Normalabfolge, ohne jedoch die Art der Beziehung zwischen den Vorgängen explizit zu ändern. Dabei wird die nachfolgende Aktivität gestartet, bevor die vorherige vollständig abgeschlossen ist. Dies birgt Risiken, insbesondere wenn eine sequenzielle Anordnung der Aktivitäten zwingend erforderlich ist. Ein typisches Beispiel wäre der Start von Produktionsaktivitäten, bevor das Design endgültig abgeschlossen ist, was zu nachträglichen Änderungen am Design und potenziell zu einer Neuausführung von Teilen der Produktion führen könnte. Erfahrene Projektmanager weisen jedoch darauf hin, dass sequenzielle Aktivitäten oft um bis zu 25% beschleunigt werden können, indem man die nachfolgende Aktivität bereits beginnt, wenn der Vorgänger zu 75% fertiggestellt ist. Trotz der Risiken kann die beschleunigte Ausführung, sofern das Risikoniveau als akzeptabel bewertet wird, eine effektive Strategie sein, um den Terminplan zu straffen und Verzögerungen effektiv zu begegnen.

Optimierung der Prozesse.

Die Optimierung der Prozesse ist stets eine Option. Es steht außer Frage, dass nahezu jede Arbeit besser und schneller ausgeführt werden könnte. Der Projektmanager kann eine retrospektive Besprechung nutzen, um Möglichkeiten zur Prozessverbesserung zu identifizieren. Zu eliminieren sind alle Quellen von Verschwendung, wie sie in der Qualitätssicherung thematisiert werden. Auch Prozessengpässe stellen eine Form der Verschwendung dar, beispielsweise wenn abgeschlossene Arbeiten auf die weitere Verarbeitung warten müssen, einschließlich der Wartezeiten auf Genehmigungen. Eine weitere Gelegenheit zur Verbesserung ergibt sich, wenn Teammitglieder von den Projektarbeiten abgezogen werden, um andere, außerhalb des Projekts liegende Aufgaben zu erledigen, die aufgeschoben werden könnten, bis das Projekt seinen Rückstand aufgeholt hat. In diesem Fall wäre Verhandlung die Schlüsseltechnik, die angewendet werden sollte.

Präventive Maßnahmen.

Präventive Maßnahmen sind entscheidend, um Verzögerungen im Projektmanagement zu verhindern, bevor sie überhaupt entstehen. Bisher haben wir über “Korrekturmaßnahmen” gesprochen, die darauf abzielen, bereits festgestellte Verzögerungen bei kritischen Aktivitäten aufzuholen. Einige Verzögerungen entstehen unvermeidlich durch unvorhergesehene Ereignisse, jedoch können viele durch Fehler im Projektmanagement vermieden werden.

Ein wichtiger präventiver Ansatz ist es, sicherzustellen, dass alle Teammitglieder ihre Fristen genau kennen und verstehen. Dies umfasst nicht nur die Kenntnis der Termine, sondern auch das Bewusstsein für die Bedeutung dieser Fristen im Kontext des gesamten Projektplans. Durch regelmäßige Updates und die Verwendung klarer, transparenter Kommunikationskanäle kann sichergestellt werden, dass jedes Teammitglied über die notwendigen Informationen verfügt, um seine Aufgaben rechtzeitig zu erfüllen.

Zunächst müssen der Projektmanager und das jeweilige Team ein klares Verständnis der zu erledigenden Arbeit, der Zeitpunkte ihrer Durchführung und der dafür verantwortlichen Personen haben. Dies erreicht man durch die Entwicklung eines Projektstrukturplans, eine fachgerechte Definition der Arbeitspakete und die Erstellung eines sachgerechten Terminplans. Sollten diese Planungswerkzeuge fehlerhaft sein oder gänzlich fehlen, ist mit Problemen während der Ausführungsaktivitäten zu rechnen. Der Detaillierungsgrad des Terminplans sollte genau darlegen, wann jedes Arbeitspaket beginnen und enden sollte und wer die Verantwortung trägt.

Diese Informationen sind entscheidend, um die nächsten Anfangstermine zu bestimmen. Es ist daher wichtig, mit den zuständigen Personen in Kontakt zu treten, um Verpflichtungen und Fristen zu aktualisieren und zu validieren. Diese Maßnahmen können in vielen Fällen dazu beitragen, zukünftige Verzögerungen zu vermeiden, die durch Unklarheiten, Missverständnisse oder Prioritätskonflikte mit anderen Arbeiten entstehen könnten.

Stärkung der Moral und Erneuerung der Verpflichtungen.

Stärkung der Moral und Erneuerung der Verpflichtungen sind ebenfalls essenzielle präventive Maßnahmen. Nachdem Zwischenfristen verpasst wurden, könnte das Engagement einiger Teammitglieder nachlassen, insbesondere wenn sie zweifeln, ob angesichts der verfehlten Fristen weiterhin strenge Bemühungen nötig sind. In solchen Fällen ist es wichtig, die Verpflichtungen zur termingerechten Fertigstellung der zugewiesenen Arbeiten zu erneuern, sowohl auf individueller als auch auf kollektiver Ebene.

Zudem sollten Sie Teambuildingaktivitäten in Betracht ziehen, wie sie in den Lektionen zur Projektausführung beschrieben sind. Solche Aktivitäten können dazu beitragen, die Beziehungen innerhalb des Teams zu stärken und eine positive Arbeitsatmosphäre zu fördern, was wiederum die Produktivität und die Einhaltung von Projektfristen positiv beeinflussen kann.

Kommunikation von Terminplanrisiken.

Die Kommunikation von Terminplanrisiken ist essenziell. Sollten Sie trotz angewandter Korrekturmaßnahmen weiterhin das Risiko sehen, die Projektfrist nicht einhalten zu können, ist es unerlässlich, dieses Risiko dem Sponsor mitzuteilen. Neben den bereits in Betracht gezogenen Korrekturmaßnahmen ist es auch notwendig, neue Schätzungen der Projektdauer vorzulegen. Die offene Kommunikation über Terminplanrisiken ist wichtig, da der Sponsor als Reaktion darauf möglicherweise den Projektumfang reduzieren könnte, um die ursprünglichen Fristen einzuhalten, besonders wenn die Einhaltung der Frist wichtiger ist als der volle Umfang des Projekts.

Zusammenfassend lassen sich die drei Hauptachsen des Terminplanüberwachung identifizieren: regelmäßige Überwachung des Terminplans, Verständnis für die Auswirkungen von Verzögerungen und die Anwendung von Korrektur- und Präventivmaßnahmen, wo erforderlich.

Um die Auswirkungen von Verzögerungen vollständig zu verstehen, ist es entscheidend, den kritischen Pfad des Projekts zu analysieren. Dieser repräsentiert die längste Sequenz von Aktivitäten im Projektterminplan, wobei jede Verzögerung auf diesem Pfad das Enddatum des Projekts verzögert. Die Überwachung und Steuerung des kritischen Pfades ist daher eine wesentliche Technik für die effektive Steuerung des Terminplans.

Korrekturmaßnahmen bei Verzögerungen kritischer Aktivitäten des Terminplans umfassen die Anpassung der Normalabfolge der Vorgänge, die Einführung von Überstunden, die Verdichtung des Terminplans, die beschleunigte Ausführung und die Optimierung von Prozessen. Präventive Maßnahmen beinhalten die Sicherstellung, dass jedes Teammitglied mit den jeweiligen Fristen vertraut ist, die Stärkung der Teammoral und das kontinuierliche Einhalten der Terminverpflichtungen, sowie die aktive Kommunikation von Terminrisiken, um mögliche Verzögerungen vorwegnehmend anzugehen.

 

 

 

4.4 Kontrolle des Kostenbasisplans

Das Controlling des Kostenbasisplans umfasst drei wesentliche Aspekte:

• Ein Überwachungsprozess zur Prüfung, ob die Kosten entsprechend den Kostenschätzungen und der tatsächlichen Mittelfreigabe der Organisation verlaufen.
• Die Analyse des Fertigstellungswerts (Earned Value Analysis, EVA), welche die tatsächlichen Kosten mit den budgetierten Kosten der erledigten Arbeit vergleicht und durch Aufdecken von Abweichungen ein tiefergehendes Verständnis der Kostenperformance ermöglicht.
• Die Entwicklung möglicher Korrekturmaßnahmen zur Korrektur von Kostenüberschreitungen.

Warnhinweis: Diese Lektion vermittelt Ihnen effektive Werkzeuge zur Steuerung Ihres Projekts. Da es um finanzielle Aspekte geht, sind Zahlen unerlässlich, und die Lektion dauert beinahe 30 Minuten. Wenn Sie also in Eile sind, sich müde fühlen oder versuchen, das Kursvideo anzusehen bzw. den Text zu lesen, während Sie ein Flugzeug steuern oder Auto fahren, empfehlen wir Ihnen, das Video jetzt zu pausieren. Schauen Sie es sich besser in einem entspannten Zustand, konzentriert und mit klarem Kopf an.

Szenarien für das Kostenmanagement im Projektmanagement.

Es gibt drei Szenarien für den Projektmanager in Bezug auf das Kostenmanagement.

• Im ersten Szenario, das für den Projektmanager am unkompliziertesten ist, ist die Organisation nicht darauf ausgerichtet, dass der Projektmanager das Kostenmanagement übernimmt. Diese Verantwortung liegt beim Finanzbereich. In diesem Fall fokussiert sich der Projektmanager vollständig auf die Einhaltung des Inhalts- und Umfangsbasisplans sowie des Terminbasisplans. Ein spezialisierter Mitarbeiter des Finanzbereichs trägt die Verantwortung für das Kostenmanagement.
• Im zweiten Szenario wird vom Projektmanager nicht erwartet, die Kontrolle der zurechenbaren Kosten interner Ressourcen zu übernehmen, da hierfür keine direkten Ausgaben anfallen. Der Projektmanager konzentriert sich daher ausschließlich auf das Management der externen Kosten, die durch Lieferanten entstehen und beglichen werden müssen.
• Im dritten und anspruchsvollsten Szenario ist der Projektmanager verantwortlich für die Kontrolle sowohl der externen Kosten als auch der zurechenbaren Kosten für den Einsatz interner Ressourcen. Dies schließt Kosten ein, die durch die Nutzung von internem Personal sowie der Unternehmensinfrastruktur und -ausrüstung entstehen. Eine zentrale Aufgabe besteht darin, die Einsatzdauer der internen Ressourcen zu überwachen und zu steuern. Typischerweise werden hierfür Tabellenkalkulationen oder IT-Tools verwendet, um die Arbeitszeit, die interne Ressourcen für das Projekt aufwenden, präzise zu erfassen. Diese Überwachung kann allerdings von den Mitarbeitern oft als negativ empfunden werden. Der Prozesskontrolle umfasst zudem die Umrechnung der Arbeitsstunden in monetäre Werte, basierend auf den im Kostenbasisplan festgelegten Tarifen.

Beginnen wir mit dem Überwachungsprozess, einem der drei Aspekte, die wir in dieser Lektion betrachten. Die Kontrolle des Kostenbasisplans und des Terminbasisplans ist eng miteinander verbunden, weil die meisten Kosten sich parallel zum Arbeitsfortschritt entwickeln.

Der Prozess beginnt mit der Aktualisierung der tatsächlichen Ausgaben, die gemäß der im Kostenmanagementplan definierten Häufigkeit und den dort festgelegten Werkzeugen erfolgt. In den meisten Organisationen erfolgt die Erstellung der Finanzberichte auf monatlicher Basis.

Der Überwachungsprozess konzentriert sich auf zwei Hauptaspekte: Erstens den Vergleich der tatsächlichen Kosten mit den geplanten Kostenschätzungen und zweitens die Gegenüberstellung der tatsächlichen Kosten mit der Freigaberate der Finanzmittel durch die Organisation.

• Der erste Aspekt umfasst den Vergleich der realen Kosten mit den Kostenschätzungen, der erfolgt, nachdem der Terminplan aktualisiert wurde und eine Einschätzung über die noch erforderliche Anstrengung und ihre Dauer vorliegt. Der Projektmanager kalkuliert ebenfalls die Kosten der verbleibenden Arbeiten und erstellt eine Prognose für die Gesamtkosten am Projektende. Konkret betrachtet er die tatsächlichen Ausgaben für die bereits abgeschlossene und laufende Arbeit und addiert die geplanten Ausgaben für die verbleibende Arbeit. Dies bedeutet eine Addition der bereits getätigten Ausgaben zu den erwarteten zukünftigen Ausgaben. Der Vergleich dieser kumulierten Kosten mit dem ursprünglichen Budget gibt Aufschluss darüber, ob das Projekt im Rahmen des Budgets bleibt oder ob Abweichungen vorliegen.

Diese Berechnungen und Aktualisierungen können entweder manuell mittels Tabellenkalkulationen oder durch spezielle Kostenkontrollfunktionen in Planungstools erfolgen wie Microsoft Project. Alternativ könnten sie auch innerhalb eines ERP-Systems wie SAP oder Oracle durchgeführt werden. In großen Projekten wird diese Aufgabe oft einem Projektcontroller übertragen.

• Der zweite Aspekt der Kostenüberwachung konzentriert sich auf den Vergleich der realen und geplanten Kosten mit der Freigaberate der Finanzmittel Ihrer Organisation. Es kann zu Abweichungen auf beiden Seiten dieser Gleichung kommen. Einerseits könnte das Projekt Finanzmittel schneller verbrauchen als erwartet, nicht notwendigerweise durch Budgetüberschreitungen, sondern möglicherweise, weil die Arbeiten schneller voranschreiten als geplant oder bestimmte Zahlungen vorgezogen werden müssen.

Auf der Seite der Organisation wurde die Genehmigung der Finanzierungsanforderungen des Projekts erteilt, die den Zeitplan der geplanten Ausgaben festlegt. Theoretisch sollte die Zustimmung zum Projektmanagementplan durch den Sponsor gewährleisten, dass die Organisation die Finanzmittel entsprechend diesem Plan freigibt. Allerdings leben wir nicht in einer idealen Welt. Im Laufe der Zeit, insbesondere bei langfristigen Projekten, können sich Umstände ändern. In einigen Fällen, besonders bei kleineren Projekten, steht möglicherweise das gesamte Budget zu Beginn zur Verfügung. Bei größeren Projekten wird das Budget jedoch normalerweise in Tranchen freigegeben.

Der Kern dieses Aspekts der Kostenüberwachung liegt in der Beobachtung der tatsächlichen und zukünftigen Ausgaben einerseits und der Freigaberate der Finanzmittel andererseits. Wir überwachen, wie viel Geld uns für den nächsten Zeitraum im Vergleich zu den dafür geplanten Ausgaben zur Verfügung stehen wird. Sollte sich ein Defizit abzeichnen, könnte es notwendig werden, eine frühere Freigabe der nächsten Finanzmittel zu beantragen. Es wäre nicht ratsam, Verpflichtungen einzugehen, die zu Ausgaben führen, wenn absehbar ist, dass die benötigten Mittel nicht rechtzeitig verfügbar sein werden.

Für Ihre Analyse können Sie die folgenden weichen Indikatoren für Kostenrisiken heranziehen:

• Eine geringe Kostenabweichung, die sich insbesondere zu Beginn des Projekts zu verschlechtern beginnt, kann ein frühes Warnsignal darstellen.
• Arbeitspakete, die bereits als abgeschlossen gelten sollten, sind weiterhin in Bearbeitung, weil später Fehler oder fehlende Merkmale aufgedeckt werden. Die notwendigen Überarbeitungen werden die Kosten beeinflussen.
• Verzögerungen im Projekt führen dazu, dass Terminplan-Komprimierungstechniken eingesetzt werden müssen, die höhere Kosten als ursprünglich geplant verursachen.
• Eine sinkende Teammoral kann ebenfalls ein Kostenrisiko darstellen, da ein demotiviertes Team weniger produktiv ist und somit höhere Kosten verursachen kann.

Es ist wichtig, diese Situationen frühzeitig zu erkennen und zu adressieren, um die zugrunde liegenden Ursachen zu korrigieren und so die Kostenrisiken zu minimieren.

Nummer zwei: Analyse des Fertigstellungswerts (EVA).

Die Analyse des Fertigstellungswerts, setzt die tatsächlichen Kosten ins Verhältnis zum Budget der abgeschlossenen Arbeit. Dadurch ermöglicht sie ein umfassenderes Verständnis der Kostenleistung. Dies ist von großer Bedeutung, denn eine bloße Gegenüberstellung von Ist- und Plankosten kann trügerisch sein und zu einer scheinbaren Kostenüberschreitung führen, wie zum Beispiel:

• Einige tatsächlich angefallene Kosten während des Berichtszeitraums waren möglicherweise ursprünglich für einen späteren Zeitpunkt geplant. Wenn beispielsweise ein größerer Kauf, der erst später vorgesehen war, bereits getätigt wird, erscheint dies im aktuellen Zeitraum als Kostenüberschreitung. In Wahrheit handelt es sich jedoch nicht um eine echte Kostenüberschreitung, sondern lediglich um eine zeitliche Verschiebung der Ausgabenrate. Hierbei ist entscheidend, ob die von Ihrer Organisation bereitgestellten Mittel die gemäß den Finanzierungsanforderungen Ihres Projekts vorgesehene spätere Geldbedarf decken können.
• Ein zweiter Fall tritt auf, wenn mehr ausgegeben wird, weil das Projekt mehr Arbeit als geplant abgewickelt hat. Auch dies stellt keine reale Kostenüberschreitung dar, sondern erneut eine zeitliche Verschiebung in der Ausgabenrate.

Sie haben Ihr Budget tatsächlich überschritten, wenn eine der folgenden Situationen Eintritt:

• Die definierten Arbeitspakete erfordern mehr Aufwand als ursprünglich geplant und verbrauchen somit mehr Ressourcen.
• Ihr Projektstrukturplan (WBS) war unvollständig, und es müssen mehr Arbeitselemente bearbeitet werden als vorgesehen.
• Die eingesetzten Ressourcen sind kostspieliger als angenommen.
• Ein Teil Ihres Teams arbeitet außerhalb des genehmigten Inhalts und Umfangs.

Ihre Analyse sollte klar zwischen scheinbaren und tatsächlichen Kostenüberschreitungen differenzieren. Hierbei leistet die Analyse des Fertigstellungswerts (EVA) wertvolle Unterstützung. Diese Methode ermöglicht eine detaillierte Untersuchung der Kosten- und Terminperformance und stützt sich auf eine zentrale Kennzahl: den Fertigstellungswert (EV) des Projekts. Dieser Wert wird definiert als der budgetierte Wert der bereits erledigten Arbeit.

Stellen Sie sich vor, das folgende Bild repräsentiert Ihr Projekt, vereinfacht dargestellt in einer einzigen Gantt-Diagramm-Leiste:

Das ursprünglich geplante Gesamtkostenbudget (BAC) für das gesamte Projekt beträgt 100 €. Die geplante Dauer umfasst 100 Tage, und heute ist der 70. Tag. Sie haben bereits 80 € ausgegeben und 50 % der Arbeit abgeschlossen. Der farbig markierte Abschnitt der Leiste im Gantt-Diagramm zeigt die “abgeschlossene Arbeit”, die 50 % entspricht.

Der Fertigstellungswert (EV) wird als der für die geleistete Arbeit geplante Betrag definiert. Wenn also das Gesamtbudget 100 € beträgt und Sie 50 % der Arbeit abgeschlossen haben, entspricht der proportionale Budgetbetrag für die geleistete Arbeit 50 €. Daher beträgt der Fertigstellungswert 50 €.

Der nächste Schritt besteht darin, den Fertigstellungswert (EV) mit dem geplanten Wert (PV) zu vergleichen. Der geplante Wert (PV) repräsentiert den Budgetbetrag für den Teil der Arbeit, der bis zu einem bestimmten Zeitpunkt abgeschlossen sein sollte. In diesem Beispiel war geplant, dass 70 % der Arbeit zu diesem Zeitpunkt abgeschlossen sein sollten, daher beträgt der proportionale Budgetbetrag für 70 % der Arbeit 70 €.

Der Fertigstellungswert von 50 € abzüglich des geplanten Werts von 70 € ergibt eine Terminplanabweichung (SV) von -20 €. Dies zeigt, dass das Projekt “weniger Wert erarbeitet” hat, als bis zu diesem Zeitpunkt geplant war, was bedeutet, dass wir im Rückstand sind. Eine negative Terminplanabweichung ist in der Tat eine schlechte Nachricht und deutet darauf hin, dass das Projekt hinter dem Zeitplan zurückbleibt. Wahrscheinlich wäre diese Verzögerung auch visuell im Gantt-Diagramm erkennbar gewesen, selbst ohne diese spezifische Berechnung.

Die Kostensituation ist allerdings weniger offensichtlich. Man könnte argumentieren, dass, da 80 € ausgegeben wurden und das Budget 100 € beträgt, keine Kostenüberschreitung vorliegt. Das eigentliche Problem tritt jedoch zutage, wenn man die tatsächlich entstandenen Kosten mit dem proportionalen Budget für die geleistete Arbeit vergleicht, also dem Fertigstellungswert. Dieser liegt, wie erwähnt, bei 50 €, da 50 % der Arbeit abgeschlossen sind. Hier offenbart sich, dass mehr Kosten entstanden sind, als für den erreichten Arbeitsfortschritt geplant war.

Der Fertigstellungswert von 50 € abzüglich der tatsächlichen Kosten von 80 € ergibt eine Kostenabweichung (CV) von -30 €. Das bedeutet, dass das Budget um 30 € überschritten wurde. Diese Kostenüberschreitung wird nicht offensichtlich, wenn man lediglich die tatsächlichen Ausgaben mit dem Gesamtbudget vergleicht. Die Analyse des Fertigstellungswerts zeigt deutlich auf, dass mehr ausgegeben wurde, als es der Wert der geleisteten Arbeit rechtfertigt.

Daher haben wir sowohl die Terminplanabweichung als auch die Kostenabweichung berechnet. Diese beiden Indikatoren verdeutlichen, dass wir im Rückstand sind und das Budget deutlich überschritten haben. Sie bieten wichtige Einblicke in die tatsächliche Leistung des Projekts im Vergleich zu den Planungen und sind entscheidend für das Ergreifen von korrigierenden Maßnahmen.

Wenn wir statt zu subtrahieren den Fertigstellungswert durch den geplanten Wert und die tatsächlichen Kosten teilen, erhalten wir das gleiche Ergebnis, jedoch in Prozent ausgedrückt. Diese relativen Indizes werden als Terminentwicklungsindex (SPI) und Kostenentwicklungsindex (CPI) bezeichnet. Der SPI berechnet sich also durch das Verhältnis von Fertigstellungswert (EV) zu geplantem Wert (PV) und gibt an, wie effizient das Projekt im Hinblick auf den Zeitplan vorankommt. Der CPI ergibt sich aus dem Verhältnis von Fertigstellungswert (EV) zu tatsächlich angefallenen Kosten (AC) und zeigt auf, wie effizient das Budget genutzt wird.

• Ein Fertigstellungswert von 50 € geteilt durch die tatsächlichen Kosten von 80 € ergibt einen Kostenentwicklungsindex (CPI) von 0,625 oder 62,5%, was darauf hinweist, dass das Budget um 37,5% überschritten wurde. Ein Kostenentwicklungsindex von 1 bedeutet, dass das Budget zu 100% eingehalten wird.
• Ein Fertigstellungswert von 50 € geteilt durch den geplanten Wert von 70 € ergibt einen Terminentwicklungsindex (SPI) von 0,71 oder 71%, was darauf hindeutet, dass wir im Terminplan um 29% im Rückstand sind. Ein Terminentwicklungsindex von 1 zeigt eine 100%ige Einhaltung des geplanten Terminplans an.

Daher bedeutet es in mathematischer Hinsicht, ein Projekt gemäß dem Fortschrittsmessungsbasisplan zu managen, dass sowohl der Terminentwicklungsindex (SPI) als auch der Kostenentwicklungsindex (CPI) bei 1 liegen sollten. Dies entspricht einer 100%igen Übereinstimmung mit dem Terminbasisplan und dem Kostenbasisplan. Ein SPI und CPI von 1 zeigen an, dass das Projekt genau nach diesen Plänen verläuft, sowohl hinsichtlich der Termine als auch der Kosten. Dies ist das zentrale Ziel eines effektiven Projektmanagements.

Die Vorstellung, Zeit in monetären Einheiten zu bewerten, mag anfangs ungewohnt erscheinen. Dennoch ist uns allen klar, dass Zeit Geld bedeutet. Die Umrechnung von Zeit in Geldwerte macht die entscheidende Verbindung zwischen diesen beiden Facetten der Projektperformance sichtbar.

In Anbetracht des früheren Beispiels ergeben sich aus dieser konsistenten Betrachtungsweise der Leistung folgende praktische Erkenntnisse:

• Wenn wir das Budget stärker überschreiten als den Terminplan, ist es ratsam, von Terminplan-Komprimierungstechniken, die zusätzliche Kosten verursachen, Abstand zu nehmen.
• Befinden wir uns jedoch zeitlich in einem stärkeren Rückstand als wir das Budget überschreiten, kann der Einsatz kostenintensiver Maßnahmen zur Beschleunigung des Terminplans trotz des bestehenden Budgetüberschreitung gerechtfertigt sein, da der Zeitverzug das vorrangige Problem darstellt.

Die nächste Frage ist: In welcher Situation werden wir uns am Ende des Projekts befinden? Um diese Frage zu beantworten, müssen wir das ursprünglich geplante Gesamtkostenbudget (Budget at Completion: BAC), das im Fortschrittsmessungsbasisplan festgelegt wurde, betrachten und den Einfluss der aktuellen Kostensituation bis zum Projektende extrapolieren. Diese Berechnung, bekannt als die erwarteten Gesamtkosten bei Fertigstellung (Estimate at Completion: EAC), gibt uns eine Prognose über die voraussichtlichen Gesamtkosten des Projekts.

Wir müssen noch 50 % der Arbeit erledigen. Der aktuell ermittelte Kostenentwicklungsindex von 0,625 ermöglicht es uns, die erwarteten Gesamtkosten bei Fertigstellung (EAC) durch Extrapolation zu berechnen. Dies geschieht, indem das ursprünglich geplante Gesamtkostenbudget (BAC) von 100 € in unserem Beispiel durch den Kostenentwicklungsindex von 0,625 geteilt wird, was zu erwarteten Gesamtkosten von 160 € führt. Sollten wir im bisherigen Tempo weitermachen, wird eine Kostenüberschreitung von 60 % gegenüber dem genehmigten Kostenbasisplan prognostiziert. Dies ist nicht hinnehmbar, daher sind umgehend korrektive Maßnahmen erforderlich.

Aber selbst, wenn wir das problematische Szenario für die verbleibende Arbeit korrigieren, können wir die bisher entstandenen Mehrkosten nicht rückgängig machen. Das bereits ausgegebene Geld und die verstrichene Zeit sind unwiederbringlich verloren.

Betrachten wir, wie wir die erwarteten Gesamtkosten bei Fertigstellung (EAC) in einem optimistischen Szenario berechnen können, unter der Annahme, dass es uns gelingt, die Ursachen für die bisherigen Kostenüberschreitungen zu beseitigen.

Die bisher angefallenen Kosten von 80 € bleiben bestehen. Hinzu kommen die Kosten für die verbleibende Arbeit. Im optimistischen Szenario nehmen wir an, dass es uns gelingt, die Ursachen der Mehrkosten zu beseitigen. Unter dieser Annahme würde die verbleibende 50%ige Arbeit gemäß der ursprünglichen Schätzung von 50 € durchgeführt werden. Das entspricht den ursprünglich geplanten Gesamtkosten (BAC) von 100 €, abzüglich des Fertigstellungswerts (EV) von 50 €.

Die bereits ausgegebenen 80 € plus die 50 €, die für die verbleibende Arbeit gemäß den ursprünglichen Planungsschätzungen vorgesehen sind, ergeben zusammen 130 €.

Wenn die Korrekturmaßnahmen zur Behebung der Abweichung “mutige” und potenziell schmerzhafte Schritte umfassen, können Sie die beiden Szenarien wie folgt darlegen:

• Wenn wir die Situation nicht korrigieren, werden die erwarteten Gesamtkosten bei Fertigstellung (EAC) voraussichtlich bei 160 € liegen.
• Wenn wir die Situation jetzt korrigieren, könnten die erwarteten Gesamtkosten bei Fertigstellung (EAC) auf 130 € reduziert werden. Dies erfordert jedoch die Umsetzung der vorgeschlagenen, schmerzhaften Korrekturmaßnahmen.

Wir steigen nun auf eine höhere Ebene auf und wenden die Analyse des Fertigstellungswerts (Earned Value Analysis, EVA) an, um ein in Arbeitspakete unterteiltes Projekt zu analysieren. Die hier dargestellte Tabelle könnte ein Bestandteil Ihres Projektberichts sein. In diesem Beispiel haben wir dieselben Arten von Berechnungen angewendet, die zuvor erläutert wurden. Der einzige Unterschied besteht darin, dass wir nun jedes Arbeitspaket oder jedes Kontrollkonto einzeln untersuchen und anschließend die Ergebnisse auf das gesamte Projekt konsolidieren. Keine Sorge wegen der Zahlen; basierend auf dem, was Sie bereits gelernt haben, wird dies einfacher sein, als es zunächst erscheint, und wir werden Ihnen jeden Schritt detailliert erklären.

Hinweis: Die nachfolgende Tabelle zeigt die absoluten Werte in Tausend Euro. Zum Beispiel bedeutet 200 einen Betrag von 200.000 €

AP oder Kontrollkonto	EV	PV	AC	BAC	SV EV – PV	SPI EV / PV	CV EV – AC	CPI EV / AC	EAC gelöst (AC + BAC-EV)	EAC Ungelöst BAC/CPI
A	200	200	200	200	200-200 = 0	200/200 = 1	200-200 = 0	200/200 = 1	200+200–200 = 200	200/1 = 200
B	90	180	100	180	90-180 = -90	90/180 = 0,5	90-100 = -10	90/100 = 0,90	100+180-90 = 190	180/0,9 = 200
C	100	100	130	200	100-100 = 0	100/100 = 1	100-130 = -30	100/130 = 0,77	130+200-100 = 230	200/0,77 = 260
D	10	60	20	300	10-60 = -50	10/60 = 0,17	10-20 = -10	10/20 = 0,50	20+300-10 = 310	300/0,5 = 600
∑	400	540	450	880	-140	400/540 = 0,89	-50	390/450 = 0,87	450+880-400 = 930	880/0,87 = 1011

Beginnen wir also mit der Analyse des gesamten Projekts, indem wir dieselbe Logik anwenden wie im vorherigen Beispiel.

Wir stellen fest, dass wir im Rückstand sind und unser Budget überschritten haben, da sowohl der Terminentwicklungsindex (Schedule Performance Index: SPI) als auch der Kostenentwicklungsindex (Cost Performance Index: CPI) unter 1 liegen. Jedoch hat uns die Analyse des Fertigstellungswerts (Earned Value Analysis: EVA) wertvolle Einblicke in die problematischen Arbeitspakete geliefert und aufgezeigt, welche Korrekturmaßnahmen sinnvoll sein könnten.

Gehen wir schrittweise vor.

In den Arbeitspaketen B und D zeigen sich Terminplanprobleme, wobei der Terminentwicklungsindex (Schedule Performance Index: SPI) für Arbeitspaket B bei 0,5 liegt und für Arbeitspaket D noch ungünstiger bei 0,17. Offiziell verwendet die Analyse des Fertigstellungswerts (Earned Value Analysis: EVA) keine Tage zur Berechnung der Zeit, aber wir können den Terminentwicklungsindex (SPI) nutzen und diesen in Tage umrechnen. Wenn beispielsweise Arbeitspaket B ursprünglich für 20 Tage geplant war, zeigt eine Division der geplanten Dauer durch den SPI von 0,5, dass es – bei aktuellem Tempo – 40 Tage dauern wird, das Arbeitspaket abzuschließen. Also 20 Tage geteilt durch 0,5 ergibt 40 Tage.

Und bei Arbeitspaket D sieht es noch schlechter aus. Die geplante Dauer beträgt 60 Tage. Teilt man diese Dauer durch einen Terminentwicklungsindex von 0,17, ergibt sich eine erwartete Fertigstellung erst nach 17 Monaten statt der geplanten 3 Monate, basierend auf einer Fünf-Tage-Arbeitswoche. 60 geteilt durch 0,17 ergibt 352 Arbeitstage. Eine solche Verzögerung wäre für das Projekt wahrscheinlich katastrophal. Daher sollten wir Komprimierungstechniken auf den Terminplan dieser beiden Arbeitspakete anwenden.

Nun zu den Kosten. Die Arbeitspakete B, C und D überschreiten das Budget, doch der Kostenentwicklungsindex (CPI) zeigt, dass das größte Problem beim Arbeitspaket D liegt, mit einem CPI von 0,5. Bei dieser Ausgabenrate würde es 600.000 € statt der geplanten 300.000 € kosten, es abzuschließen (300.000 € / 0,5 = 600.000 €). Arbeitspaket D sollte daher unser Hauptziel für korrektive Kostenmaßnahmen sein.

Wir sehen auch zwei erwartete Kosten bei Fertigstellung (EAC). Wenn wir das Problem lösen, indem wir vielleicht eine mutige Entscheidung treffen, könnten wir fast die gesamte Kostenabweichung zurückgewinnen, da dieses Arbeitspaket bisher nur einen Fertigstellungswert (EV) von 10.000 € von insgesamt 300.000 € erbracht hat. Das bedeutet, dass noch 97 % der Arbeit zu erledigen sind. Daher besteht ein großes Potenzial zur Kostensenkung. Auf jeden Fall sollte dort zuerst angesetzt werden.

Die Arbeitspakete B und C bieten ebenfalls ein Potenzial zur Kostensenkung. Allerdings sehen wir, dass das Einsparpotenzial bei Arbeitspaket B nur 10.000 € und bei Arbeitspaket C 30.000 € beträgt.

Was sehen wir hier noch? Zunächst sollten wir ein Budgetrisiko kommunizieren, denn selbst wenn wir die bestehenden Probleme lösen, würden wir letztendlich 930.000 € statt 880.000 € ausgeben, was eine Kostenüberschreitung von 5 % bedeutet. Die gute Nachricht ist, dass Sie, wenn Sie das in diesem Kurs Gelehrte umgesetzt haben, Risikozuschläge (Contingency Reserve) von mindestens 5 % eingeplant haben sollten.

Falls Sie die Probleme jedoch nicht lösen und am Ende über 1 Million Euro statt 880.000 € ausgeben, stellt sich die Frage, ob Sie eine Reserve von 15 % haben. Wenn Ihr Sponsor unserer Methode folgt, sollte er eine Managementreserve haben, um die Differenz auszugleichen. Mit dieser Managementreserve müsste der Sponsor gegenüber der Unternehmensleitung keine weiteren Erklärungen abgeben. Sollten Sie jedoch Ihren Sponsor bitten müssen, seine Managementreserve zu verwenden, würde dies den Fortschrittsmessungsbasisplan des Projekts überschreiten, der die Messlatte für die Leistung des Projektmanagers darstellt.

Also, genug mit den Zahlen. Haben Sie es überstanden? Der Rest über das Controlling des Kostenbasisplans ist sehr einfach und dauert nicht mehr lange.

Kommunizieren Sie Budgetrisiken.

Sobald es Anzeichen für eine wahrscheinliche Überschreitung des Kostenbasisplans gibt, müssen Sie dieses Risiko gemäß dem Risikomanagementplan an den Sponsor und die relevanten Stakeholder weitergeben. Es geht nicht darum, mitzuteilen, dass die Kostenschätzungen definitiv überschritten werden. Sie sollten jedoch damit beginnen, das Risiko zu kommunizieren, um Erwartungen zu managen und den Weg für die Umsetzung von Korrekturmaßnahmen zu ebnen.

Diese Informationen sind wichtig, da es Bereiche geben kann, in denen die Stakeholder und die Unternehmensleitung helfen können. Zum Beispiel könnte der Sponsor bereit sein, die Anforderungen und damit den Projektumfang zu reduzieren, um sicherzustellen, dass das Projekt innerhalb der ursprünglichen Zeit- und Kostenschätzungen abgeschlossen wird.

Nummer drei: Korrekturmaßnahmen für den Kostenbasisplan.

Wenn Sie als Projektmanager die Budgetverantwortung tragen und Korrekturmaßnahmen für die Kosten umsetzen müssen, stehen Ihnen die folgenden wichtigen Optionen zur Verfügung:

• Nummer eins: Prozessverbesserungen können immer angewendet werden, wie in der Lektion über das Controlling des Terminbasisplans erläutert.
• Nummer zwei: Wo immer möglich, vermeiden Sie höhere Kosten für Überstunden. Dies ist möglicherweise nicht immer machbar und könnte durch Tarifverträge eingeschränkt oder unmöglich sein. Es gibt jedoch manchmal Vereinbarungen, bei denen Überstunden nach Projektabschluss mit zusätzlichen Urlaubstagen ausgeglichen werden können.
• Nummer drei: Ersetzen Sie teure Ressourcen durch günstigere. Wenn Ihr Unternehmen die Kosten interner Ressourcen nicht einbezieht und einen externen Berater durch einen internen Mitarbeiter ersetzt, führt dies zu einer sofortigen Kostenreduzierung, zumindest oberflächlich, aufgrund der (irrigen) Annahme, dass interne Ressourcen keine Kosten für das Projekt verursachen. Oder vielleicht nutzen Sie Ressourcen, die aufgrund ihrer vielseitigen Fähigkeiten auf vielen Gebieten besonders teuer sind und in einer früheren Projektphase erforderlich waren. Möglicherweise können Sie diese vielseitigen, aber kostspieligen Ressourcen nun durch günstigere ersetzen, die dennoch die für die aktuelle Projektphase notwendigen Fähigkeiten besitzen.
• Nummer vier: Reduzieren Sie die Nebenkosten. Beispiele hierfür sind die Wahl eines günstigeren Hotels anstelle eines regulären Geschäftshotels, das Reisen in der Economy-Klasse statt in der Business-Klasse, der Ersatz einer fünftägigen Schulung in einem 5-Sterne-Resort durch Online-Training oder das Senden einer einzelnen Person auf eine Geschäftsreise anstelle von zwei. Natürlich sind diese Maßnahmen nicht angenehm, aber unser Ziel ist es, die Kosten zu senken.
• Nummer fünf: Neuverhandlung externer Verträge. Natürlich ist ein Vertrag bindend und sollte respektiert werden. Es stimmt aber auch, dass es oft ein partnerschaftliches Verhältnis zwischen Verkäufer und Käufer gibt. Ihr Lieferant ist möglicherweise bereit, Sie bei Ihren Bemühungen zur Kostenreduzierung zu unterstützen. Eine Vertragsressource könnte zum Beispiel bereit sein, ihre Rate gegen zusätzliche Arbeitsstunden zu reduzieren. Ein anderer Lieferant akzeptiert vielleicht weniger Geld im Austausch für schnellere Bezahlung oder die Aussicht, auf die Liste der bevorzugten Lieferanten aufgenommen zu werden. Verhandlungsgeschick ist hier von großem Vorteil.

Fassen wir zusammen:

• Budgetsituation überwachen: Die Budgetsituation sollte gemäß den Richtlinien im Kostenmanagementplan überwacht werden, der die Regeln der Organisation berücksichtigt. Es ist jedoch nicht verboten, die Kosten zweimal im Monat zu kontrollieren, auch wenn das Unternehmen nur einen monatlichen Finanzbericht verlangt.
• Analyse des Fertigstellungswerts (EVA): Die Analyse des Fertigstellungswerts bildet das Kernstück der Kostenanalyse. Sie zeigt nicht nur den aktuellen Kostenstatus und die Aussichten des Projekts, sondern weist auch auf problematische Arbeitspakete sowohl in Bezug auf die Kosten als auch auf die Termine hin.
• Korrekturmaßnahmen bestimmen: Identifizieren Sie erforderliche Korrekturmaßnahmen, insbesondere dort, wo das größte Potenzial besteht. Die Bestimmung dieser Maßnahmen ist ein Prozesskontrolle. Ihre Umsetzung erfolgt als Arbeitspakete und ist Teil der Projektumsetzungsaktivitäten.
• Risikozuschläge nutzen: Nutzen Sie die Risikozuschläge, die Sie eingeplant haben. Falls aufgrund übermäßigen Optimismus keine oder unzureichende Risikozuschläge berücksichtigt wurden, müssen Sie jetzt Änderungsanträge an den Projektbasisplänen stellen. Beachten Sie, dass dies Ihre Leistung als Projektmanager beeinträchtigen kann.
• Kostenrisiken kommunizieren: Denken Sie daran, wie wichtig es ist, Erwartungen rechtzeitig zu steuern und unangenehme Überraschungen am Ende des Projekts zu vermeiden.

 

 

 

 

 

4.5 Kontrolle der Qualität

Dieser Abschnitt beschäftigt sich mit der Überprüfung von Liefergegenständen, um sicherzustellen, dass sie vollständig und korrekt sind. Beginnen wir mit einer Auffrischung der Definition von Qualität gemäß der ISO 9000-Norm: “Qualität ist das Maß, in dem ein Satz inhärenter Eigenschaften die Anforderungen erfüllt.” Der Schlüssel liegt darin, die Anforderungen zu erfüllen.

Im Projektmanagement sind zwei Aspekte der Qualität zu berücksichtigen:

• Qualitätssicherung: Die Implementierung von Standards, Richtlinien und Prozessen, um sicherzustellen, dass die Liefergegenstände den Anforderungen entsprechen.
• Qualitätskontrolle: Die Messung, inwieweit die Liefergegenstände den Anforderungen gerecht werden. Das ist das Thema dieser Lektion.

Falls erforderlich, wiederholen Sie die Lektion zur “Qualitätssicherung”, die Bestandteil der Inhalte zur Projektausführung ist.

Denken Sie daran, dass nicht nur das Endlieferobjekt eines Projekts den Anforderungen entsprechen muss. Jedes Arbeitspaket hat eigene Akzeptanzkriterien und muss eine Qualitätsprüfung bestehen. Jede Phase eines Projekts sowie das gesamte Projekt sollten klar definierte Erfolgskriterien haben.

Sie überprüfen die Konformität eines Objekts mit den Anforderungen, um festzustellen, ob es vollständig und korrekt ist. Diese Überprüfungen führen Sie durch, bevor Sie den Liefergegenstand dem Kunden zur Abnahme und endgültigen Übergabe vorlegen. Sie möchten nicht, dass der Kunde Fehler oder unerfüllte Anforderungen entdeckt, die Sie vor der Präsentation zur Kundenabnahme und -übergabe hätten erkennen sollen.

Qualitätskontrolle.

In der Lektion über “Autorisierung, Delegierung und Annahme von Arbeitspaketen,” die Teil der Projektausführung ist, haben wir einen spezifischen Qualitätskontrollprozess für Arbeitspakete vorgestellt. Lassen Sie uns diesen hier im Kontext von Liefergegenständen allgemein auffrischen, da dieser Qualitätskontrollprozess für jede Art von Liefergegenstand angewendet werden kann und die praktische Umsetzung der Qualitätskontrolle repräsentiert.

An einer Qualitätskontrollsitzung nehmen mindestens zwei Personen teil. Eine dieser Personen ist diejenige, die die Ausführungsarbeit des Liefergegenstands geleitet hat und nun als Präsentator agiert. Der Präsentator kann dabei von einer administrativen Kraft für Notizen unterstützt werden. Die andere Person, die die Sitzung leitet, fungiert als Prüfer. Unter keinen Umständen kann die Person, die die Ausführungsarbeit des Liefergegenstands geleitet hat, die Rolle des Prüfers übernehmen. Auch der Prüfer kann von einer administrativen Kraft für Notizen unterstützt werden.

Wer übernimmt welche Rolle?

• Liefergegenstand als Teil eines Arbeitspakets: Der Präsentator ist das Teammitglied oder sind die Teammitglieder, die die Arbeit ausgeführt haben. Der Arbeitspaketleiter agiert als Prüfer.
• Liefergegenstand als Arbeitspaket: Der Präsentator ist der Arbeitspaketleiter, während der Projektleiter als Prüfer fungiert.
• Liefergegenstand als Projektphase: Der Präsentator ist der Projektleiter, der Sponsor übernimmt die Rolle des Prüfers.
• Liefergegenstand als komplettes Projekt beim Abschluss: Der Präsentator ist der Projektleiter, der Sponsor fungiert als Prüfer. Gemäß den organisatorischen Governance-Prozessen kann der Präsentator auch der Sponsor sein, unterstützt vom Projektleiter, während eine Managementinstanz des Unternehmens die Prüferrolle übernimmt.

Während der Qualitätskontrollsitzung untersucht der Prüfer den Liefergegenstand in Bezug auf die Akzeptanzkriterien. Er fordert Nachweise der Übereinstimmung des vorgelegten Liefergegenstands mit den bei dessen Definition festgelegten Akzeptanzkriterien an. Der Präsentator legt diese Nachweise vor. Fragen werden gestellt und beantwortet. Erforderliche Maßnahmen werden vereinbart und dokumentiert.

Die Qualitätsprüfung kann eines der folgenden Ergebnisse haben:

• Akzeptiert: Der Liefergegenstand ist korrekt und vollständig und wird daher akzeptiert.
• Akzeptiert mit Bedingungen: Der Liefergegenstand ist nahezu korrekt und vollständig, wird aber unter bestimmten Bedingungen akzeptiert. Einige Maßnahmen sind noch erforderlich und werden dokumentiert, aber eine zweite Qualitätskontrollsitzung ist nicht nötig.
• Nicht akzeptiert: Der Liefergegenstand ist entweder nicht korrekt oder unvollständig, wird daher nicht akzeptiert und zur Nacharbeit zurückgeschickt. Eine weitere Qualitätsprüfung ist notwendig.

Wenn der überprüfte Liefergegenstand ein Projekt ist, wird ein negatives Ergebnis im Portfoliomanagementprozess erfasst. Die Organisation muss dann entscheiden, ob ein Folgeprojekt durchgeführt wird, um die fehlenden Anforderungen zu erfüllen. Dies hängt vom organisatorischen Kontext ab.

Beachten Sie, dass die Konformität mit den Anforderungen nicht während der Qualitätskontrollsitzung gemessen wird. Während dieser Sitzung wird überprüft, ob Nachweise für die Konformität mit den Anforderungen vorhanden sind. Der Nachweis der Konformität selbst muss bereits vor der Qualitätskontrollsitzung erbracht worden sein. Zum Beispiel durch erfolgreich bestandene und dokumentierte Tests, eine Zufriedenheitsumfrage mit einem vordefinierten Mindestergebnis oder eine Analyse, die die Konformität des Liefergegenstands mit den Anforderungen nachweist und in einem Bericht festgehalten wurde. All dies muss vor der Qualitätskontrollsitzung erfolgt sein.

Die Prozesse zur Sammlung dieser Nachweise sind ebenfalls Teil des “Qualitätskontrollprozesses”. Die Art der erforderlichen Nachweise und die Methode ihrer Erstellung hängen jedoch vom Produkt und der jeweiligen Branche ab. In der Pharma-, Gesundheits-, Transport- und Nuklearindustrie ist der Prozess zum Nachweis der Konformität mit Qualitätsattributen beispielsweise besonders streng und umfangreich. Die Anforderungen, Akzeptanzkriterien und somit die Methoden zur Überprüfung der Konformität unterscheiden sich erheblich zwischen einem Netflix-Film, einer Lachszuchtfarm, einer Flugzeugturbine für Airbus und einem maßgeschneiderten Weizensamen, der entwickelt wird, um den einzigartigen Geschmack einer Pizza bei Pizza Hut zu schaffen.

Darüber hinaus spielt der angewandte Entwicklungsansatz eine wichtige Rolle bei der Durchführung der Qualitätskontrolle. In agilen Projekten oder Komponenten können beispielsweise alle Teammitglieder in jeder Iteration die Qualitätskontrollaktivitäten durchführen. In einem Projekt mit einem Wasserfallentwicklungsmodell werden die Qualitätskontrollaktivitäten hingegen zu bestimmten Zeiten, etwa gegen Ende jeder Phase und des Projekts, von spezialisierten Teammitgliedern durchgeführt, die auf Qualitätskontrolle spezialisiert sind.

Schauen wir uns einige Beispiele für Akzeptanzkriterien oder Anforderungen bei unterschiedlichen Produktarten an und wie die Konformität nachgewiesen werden könnte.

Art der Anforderung	Anforderung	Mittel zur Demonstration der Konformität
Funktionsanforderung	Das System muss die Zustimmung des Anrufers zur Aufzeichnung des Anrufs einholen	Funktionstest
Funktionsanforderung	Das System verbindet sich mit dem allgemeinen Kundendienst, wenn der Anrufer den Zweck des Anrufs nicht angibt	Funktionstest
Qualitätsattribut	Das Material muss einer Hitze von 500°C standhalten, mit einer Verformung, die x% nicht überschreitet	Belastungstest
Qualitätsattribut	Der Redner muss von der Zuhörerschaft mit einem Verständlichkeitsgrad von 8 auf einer Skala von 1 bis 10 von mindestens 80% der Zuhörerschaft verstanden werden	Umfrage und strukturiertes Interview einer Stichprobengruppe der Zuhörerschaft
Anforderung an das Projektmanagement	Eine Abweichung vom Kostenleistungsindex darf am Ende jeder Phase 20% nicht überschreiten	EVA-Bericht
Geschäftsanforderung	Fähigkeit, die Dienstleistungen der Organisation potenziellen chinesischen Kunden zu präsentieren	Akzeptanz des Lieferergebnisses eines Projekts zur Entwicklung dieser Geschäftsfähigkeit
Qualitätsattribut	Immunität gegen Covid-19 mit eine Wirksamkeit von mindestens 70% bei Personen über 60 Jahren	Testreihe wie im Ausnahmegesetz für Covid-19 definiert

Wie Sie sehen können, ist es nicht möglich, alle Test- oder Produktbewertungstechniken zu verallgemeinern, da sie produktspezifisch sind. Das Ziel bleibt jedoch stets dasselbe: Fehler, Mängel oder andere Nichtkonformitäten in einem Produkt oder einer Dienstleistung zu finden. Der Umfang der Tests und Bewertungen hängt zudem von Einschränkungen wie Budget, verfügbarer Zeit und den Vorgaben des Qualitätsmanagementplans ab.

Nachfolgend einige Beispiele für gängige Tests in verschiedenen Branchen:

• In der Softwareindustrie: Einheitstests, Integrationstests, Schnittstellentests usw.
• In Bauprojekten: Zementfestigkeits-, Betonarbeitsfähigkeits- und Bodentests usw.
• Bei der Entwicklung von Computergeräten: Umweltstresstests, Alterungstests, Systemtests usw.
• Tests an zivilen Flugzeugen: Sicherheitstests, Leistungstests usw.
• Bericht zur Fertigstellungswert (EVA): Der im Abschnitt über Controlling des Kostenbasisplans verwendete Bericht ist ein Beispiel für die Demonstration der Übereinstimmung mit einer Anforderung an das Projektmanagement im Zusammenhang mit Kosten.

Ein letztes Wort zu den Verbindungen zwischen “Qualitätssicherung,” “Qualitätskontrolle,” “Eskalationsproblemen” und größeren “Projektänderungen”:

Der Prozess der Produktion oder Beschaffung jedes Lieferobjekts innerhalb eines Arbeitspakets wird vom jeweiligen Projektteam so gestaltet, dass die Qualitätssicherungsmaßnahmen des Qualitätsmanagementplans und die spezifischen Akzeptanzkriterien des Arbeitspakets eingehalten werden. Dazu verwendet das Team die dafür vorgesehenen Werkzeuge, Prozesse und Materialien. Die Qualitätssicherung umfasst somit alle Aktivitäten, die sicherstellen, dass die definierten Anforderungen und Standards während der Produktion erfüllt werden.

Die daraus resultierenden Lieferobjekte müssen anschließend die Prozesse der Qualitätskontrolle durchlaufen, um sicherzustellen, dass sie den festgelegten Anforderungen tatsächlich entsprechen. Abweichungen von diesen Anforderungen werden in Nichtkonformitätsberichten festgehalten, woraufhin das defekte Lieferobjekt zur Nacharbeit in die Produktion zurückkehrt, um die Mängel zu beheben. Dies verdeutlicht das Zusammenspiel zwischen ‘Qualitätssicherung’ und ‘Qualitätskontrolle’.

Manchmal müssen jedoch nicht nur punktuelle Produktfehler behoben werden, sondern sich wiederholende Mängel, die auf systematische Abweichungen von den Anforderungen hindeuten. Solche Abweichungen weisen auf Mängel in den übergeordneten Qualitätssicherungsprozessen hin, beispielsweise in den Produktionsprozessen, Materialien, Werkzeugen, Fähigkeiten oder der Einstellung der beteiligten Personen. Die Behebung der zugrunde liegenden Ursachen dieser ständigen Abweichungen ist kein gewöhnliches Problem, das der Projektmanager im Rahmen seiner Befugnisse durch einfache Nacharbeit lösen kann. Stattdessen handelt es sich per Definition um „Eskalationsprobleme“, wenn die Lösung des Problems die Befugnisse des Projektmanagers übersteigt. Die Handhabung solcher Eskalationsprobleme sollte einen formellen Abwicklungsprozess durchlaufen, da ihre Lösung oft auch größere Projektänderungen umfasst. Sowohl die Steuerung von Eskalationsproblemen als auch von Änderungen jenseits der definierten Risikozuschläge wird in den nachfolgenden Absätzen über Problem- und Änderungscontrolling erläutert.

Zusammenfassend lässt sich festhalten, dass das Ziel der Qualitätssicherung darin besteht, das erforderliche Qualitätsniveau zu gewährleisten. Die Qualitätskontrolle misst, inwieweit die Lieferobjekte den Anforderungen entsprechen. Jeder Liefergegenstand hat eine Reihe spezifischer Anforderungen, einschließlich Qualitätsattributen. Das Team muss die Übereinstimmung mit den Akzeptanzkriterien vor der Qualitätskontrollsitzung verifizieren. Die Eigenschaften und Attribute eines Lieferobjekts sowie die Mittel zu ihrer Messung sind je nach Produkttyp und Branche unterschiedlich.

 

 

4.6 Kontrolle der Probleme

Dieser Abschnitt behandelt die Handhabung allgemeiner Probleme und das, was wir als Eskalationsprobleme bezeichnen.

In der Lektion über die Implementierung genehmigter Änderungen, Korrektur- und Präventivmaßnahmen haben wir den gesamten Prozess der Problemlösung dargestellt. Der Ausgangspunkt waren die Ausführungsaktivitäten zur Produktion von Lieferobjekten, während derer die Probleme durch ihre Symptome sichtbar werden.

Kontrollaktivitäten umfassen die Analyse dieser Symptome, um die zugrunde liegenden Ursachen zu identifizieren. Im Rahmen des Controllings entwickeln wir dann Lösungsoptionen und wählen eine oder mehrere Korrekturmaßnahmen aus. Der Prozess geht weiter mit der Planung dieser Korrekturmaßnahmen und endet mit der Rückkehr zu den Ausführungsprozessen, um die beschlossenen Korrekturmaßnahmen umzusetzen, die das Problem beheben sollen. Bei Bedarf können Sie sich diese Lektion erneut ansehen.

In dieser Lektion wollen wir die Natur von Problemen genauer betrachten und die Technik der Ursachenanalyse für alle Problemtypen untersuchen. Außerdem möchten wir eine spezielle Art von Problemen definieren, die wir als Eskalationsprobleme bezeichnen, und einen Prozess zu deren Bewältigung entwickeln.

Zunächst zur Definition eines Eskalationsproblems: Es ist zunächst ein Problem und bedroht, wie jedes andere Problem, die Projektziele. Allerdings handelt es sich hierbei nicht um ein alltägliches Problem. Die Problemlösung zählt zu den Kernaufgaben eines Projektmanagers. Ein Eskalationsproblem zeichnet sich jedoch dadurch aus, dass seine Lösung die Kompetenzen des Projektmanagers übersteigt und die Intervention des Sponsors erfordert.

Zunächst erinnern wir uns daran, dass alle Probleme vor ihrer Entstehung Risiken sind. Sie wurden von Risiken zu Problemen, weil sie nicht rechtzeitig erkannt wurden oder weil die im Risikomanagement entwickelten Risikobewältigungsstrategien nicht ausreichten. Daher sind die Quellen von Problemen genauso vielfältig wie die von Risiken; nur der Zeitpunkt unterscheidet sie. Ein Risiko ist ein potenzielles Problem, während ein Problem oder ein Eskalationsproblem bereits eingetretene negative Ereignisse sind.

Wenn Sie bei der Planung gute Arbeit geleistet haben, sollten Sie bereits ein Verfahren zur Bewältigung von Eskalationsproblemen definiert haben. Vielleicht ist ein solches Verfahren auch bereits Teil der Standardprozesse Ihrer Organisation. Wenn Sie jedoch ein Verfahren zur Handhabung von Eskalationsproblemen von Grund auf neu entwickeln müssen, können Sie die folgenden Ratschläge berücksichtigen.

Der erste Schritt besteht darin, die Situation entweder als Eskalationsproblem oder als normales Problem zu klassifizieren, das der Projektmanager selbst lösen kann. Wenn das Problem bedeutend ist und seine Lösung die Befugnisse des Projektmanagers übersteigt, handelt es sich um ein Eskalationsproblem.

Der nächste Schritt besteht darin, das Eskalationsproblem zu dokumentieren. Es kann zunächst mündlich oder durch eine informelle schriftliche Mitteilung gemeldet worden sein, muss aber formell mittels eines Formulars für Eskalationsprobleme erfasst werden. Die schriftliche Dokumentation trägt dazu bei, das Problem besser zu verstehen. Wenn Sie die Natur des Eskalationsproblems nicht klar schriftlich festhalten können, bedeutet das, dass Sie es noch nicht vollständig verstanden haben. Während des Lösungsprozesses wird die erste Definition des Eskalationsproblems wahrscheinlich aktualisiert, sobald Sie ein tieferes Verständnis erlangen.

Tragen Sie das Eskalationsproblem auch in ein spezielles Problemregister zur Nachverfolgung ein. Dieses Register kann eine einfache Tabelle sein, in der Sie alle Eskalationsprobleme erfassen und jedem eine eindeutige Kennung zuordnen.

Ermitteln Sie anschließend, wer an der Lösung des Eskalationsproblems beteiligt sein sollte. Da es sich per Definition um ein Problem handelt, das hierarchieübergreifend gelöst werden muss, wird der Sponsor auf jeden Fall einbezogen. Zusätzlich zum Sponsor könnten jedoch auch andere Stakeholder in unterschiedlichem Ausmaß konsultiert und eingebunden werden. Handelt es sich beispielsweise um eine vertragliche Angelegenheit, sollten möglicherweise die Rechts- oder Einkaufsabteilung, andere hochrangige Verantwortliche oder externe Partner je nach Art des Eskalationsproblems hinzugezogen werden.

Die Problemlösung funktioniert am besten im Team. Sie setzt die Zusammenarbeit mit den beteiligten Stakeholdern voraus, um mögliche Optionen zu identifizieren, zu analysieren und ihre jeweiligen Auswirkungen zu bewerten. Manchmal gibt es keine ideale Lösung für ein Problem, und das Team muss möglicherweise die am wenigsten ungünstige Option aus einer Reihe von unvorteilhaften Alternativen auswählen.

Die Entscheidung für den optimalen Handlungsverlauf kann Auswirkungen auf den Projektbasisplan haben. In diesem Fall genehmigt die Zustimmung zur Problemlösung auch die damit verbundenen Anpassungen am Projektbasisplan, was zu einem aktualisierten Projektbasisplan führt.

Aktualisieren Sie dann das Formular und das Register für Eskalationsprobleme, um die getroffene Entscheidung zu dokumentieren.

Als Nächstes passen Sie den Projektmanagementplan entsprechend an. Wahrscheinlich wird es im Terminbasisplan neue Aktivitäten geben. Im Kostenbasisplan könnten neue Kosten entstehen, und möglicherweise werden neue Risikobewältigungsstrategien erforderlich. Definitiv wird es aus dem Vorfall gesammelte Erfahrungen geben, die im Register für gesammelte Erfahrungen festgehalten und weitergegeben werden sollten.

Informieren Sie schließlich die Projektteammitglieder und andere relevante Stakeholder über die Lösung des Eskalationsproblems mithilfe der im Kommunikationsmanagementplan festgelegten Methoden. Denken Sie daran, dass Eskalationsprobleme ein regelmäßiger Bestandteil Ihrer Projektstatusberichte und der Tagesordnung Ihrer Teammeetings sein sollten.

Falls erforderlich, überprüfen Sie die Abschnitte über die Umsetzung genehmigter Änderungen und Korrekturmaßnahmen, die Teil der Inhalte zur Projektausführung sind.

Die Analyse der zugrunde liegenden Ursachen von Problemen.

Zu den gängigen Techniken zur Problemlösung gehören das Ishikawa-Diagramm, auch als Fischgrätendiagramm bekannt, die Fünf-Warum-Technik und das Brainstorming.

Um die grundlegende Idee der Ursachenanalyse zu veranschaulichen, können wir die Analogie eines Unkrauts verwenden. Der sichtbare Teil der Pflanze, das Unkraut über der Oberfläche, symbolisiert das Symptom des Problems. Die Wurzel liegt unter der Oberfläche und ist daher unsichtbar. Die Wurzeln eines Problems sind die zugrunde liegenden Faktoren, die das Problem entstehen lassen. Wenn wir das Unkraut nur oberflächlich abschneiden, verschwindet es für eine Weile, taucht jedoch immer wieder auf, solange wir die Wurzel nicht entfernen. Daher ist es entscheidend, die Wurzeln auszugraben, um ihre Verästelungen zu verstehen und sie vollständig zu beseitigen.

Eine Wurzel ist jedoch ein System, eine Kombination aus Teilen. Und das Wort Analyse bedeutet, das System in seine Teile zu zerlegen und alle Teile zu verstehen, die die Wurzel ausmachen.

Das Fischgrätendiagramm, die Fünf-Warum-Technik und das Brainstorming helfen dabei, die Ursachen eines Problems in ihre Bestandteile zu zerlegen, sie zu gruppieren und grafisch zu organisieren.

Ein Beispiel dafür ist die Titanic. Die Fünf-Warum-Technik könnte bei der Analyse einige Teilnehmer zu dem Schluss führen, dass die Hauptursache des Unglücks in der unzureichenden Aufmerksamkeit des Personals auf der Aussichtsplattform lag. Andere könnten feststellen, dass das Schiff zu schnell fuhr. Weitere Teilnehmer könnten auf Baumängel hinweisen, insbesondere auf die kritischen Nieten, deren minderwertige Qualität und fehlerhafte Installation dazu führten, dass das Schiff so schnell sank. Zudem könnten andere Teilnehmer die unzureichende Anzahl von Rettungsbooten oder das Fehlen von Ferngläsern auf der Aussichtsplattform als Ursachen anführen.

Alle diese Aussagen sind zutreffend und widersprechen sich nicht. Sie zeigen gut, wie ein Problem, in diesem Fall ein Unglück, wie die meisten Probleme auf mehreren kausalen Wegen entsteht.

Unser Ziel ist es, diese verschiedenen Ursachenwege zu identifizieren. Dabei muss nicht bei null begonnen werden. Viele Projektmanagementprobleme lassen sich in vier Hauptkategorien einordnen: Prozesse, Werkzeuge, Kenntnisse und Einstellung. Ein Problem kann etwa auf fehlende Standardverfahren zurückzuführen sein, oder bestehende Verfahren könnten fehlerhaft sein. Dem Projektteam könnten geeignete Instrumente oder Werkzeuge fehlen. Das Personal könnte nicht ausreichend über die Prozesse, Themen oder Werkzeuge informiert sein, oder die Einstellung des Teams könnte einer guten Leistung im Weg stehen. Mithilfe der Fünf-Warum-Technik lassen sich diese Ursachen weiter aufschlüsseln, um Lösungswege für die einzelnen Komponenten zu finden.

Ein letzter Hinweis zur Identifizierung bevorstehender Eskalationsprobleme: Je früher wir sie erkennen, desto schneller können wir an ihrer Lösung arbeiten und desto weniger Schaden verursachen sie. Ideal wäre es, sie gar nicht erst entstehen zu lassen und als Risiken zu vermeiden.

Natürlich lässt sich nicht alles vorhersehen oder verhindern. Aber sobald wir erste Anzeichen eines Problems erkennen, ist es besser, es zügig zu lösen.

Wie können wir Probleme frühzeitig erkennen?

Retrospektiven bieten hervorragende Möglichkeiten, Probleme frühzeitig zu erkennen, wenn sie noch minimal sind. Falls erforderlich, überprüfen Sie die Abschnitte über die Prozessverbesserung durch Retrospektiven, die Teil der Inhalte zur Projektausführung sind.

Die Analyse des Fertigstellungswerts (EVA) dient ebenfalls als effektiver Frühindikator. Sie zeigt zwar nicht die Wurzelursachen auf, sondern nur die Symptome des Problems, kann jedoch die spezifischen Arbeitspakete identifizieren, die zugrunde liegende Probleme aufweisen.

Beobachtungen sind ebenfalls ein nützliches Werkzeug zur Erkennung bevorstehender Probleme. Projektmanager sollten einen Teil ihrer Zeit mit dem Projektteam verbringen und dabei Techniken aus der Lektion „Teamentwicklung“ anwenden. Eine hilfreiche Technik ist das Management durch Herumlaufen. Dessen Prinzip ist einfach und fast selbstverständlich: Ein Manager besucht seine Mitarbeiter spontan, ohne einen bestimmten Zweck zu verfolgen. Das Ziel ist es, zu erfahren, was vor Ort passiert. Tom Peters und Robert Waterman erklären dies in ihrem Klassiker „Auf der Suche nach Spitzenleistungen“ sehr anschaulich.

Konfliktmanagement ist ein verwandtes Thema. Wenn Sie Ihr Wissen darüber vertiefen möchten, lesen Sie das Buch Die Kunst des Konfliktmanagements von Professor Michael Dues. Es erklärt die Prinzipien der “Win-Win”-Lösungen, das berühmte Harvard-Verhandlungsmodell und vieles mehr. Zudem enthält es eine umfangreiche Bibliografie, die sämtliche Aspekte des Konfliktmanagements abdeckt.

Zusammenfassung:

Die beste Methode, Probleme zu kontrollieren, ist es, sie gar nicht erst entstehen zu lassen. Vermeiden Sie sie, solange sie noch Risiken darstellen. Wenn es dennoch dazu kommt, sollten Probleme zügig gelöst werden, denn im Projektmanagement sind Zeitbegrenzungen entscheidend. Ein zu langes Zögern kann kontraproduktiv sein.

Integrieren Sie Ihr Team aktiv in das Problemmanagement und nutzen Sie dafür einen klar strukturierten Prozess. Retrospektiv-Meetings, die Analyse des Fertigstellungswerts (EVA) und Management durch Herumlaufen sind bewährte Methoden, um Probleme frühzeitig zu erkennen.

Bei der Problemanalyse reicht es nicht aus, nur die sichtbaren Symptome zu behandeln. Sie müssen tief graben, bis Sie die Wurzelursache finden – ein System aus mehreren kausalen Pfaden. Diese gilt es zu identifizieren, zu analysieren und zu lösen, und das am besten im Team.

Die Umsetzung von Korrekturmaßnahmen erfolgt über Arbeitspakete. Sie müssen wie alle anderen Arbeitspakete definiert, geplant und umgesetzt werden.

4.7 Kontrolle der Änderungen

Dieser Abschnitt befasst sich mit dem integrierten Management von Veränderungen, die sich aus den verschiedenen Überwachungs- und Steuerungsaktivitäten ergeben.

Während dieser Aktivitäten wertet der Projektmanager die Rohdaten aus den Ausführungsaktivitäten aus, analysiert, synthetisiert und kontextualisiert sie, um sie in aussagekräftige Informationen über die Arbeitsleistung zu transformieren. Anschließend vergleicht er diese Informationen mit dem Projektmanagementplan, um etwaige Abweichungen zu identifizieren. Zur Korrektur dieser Abweichungen leitet der Projektmanager entsprechende Änderungen an verschiedenen Aspekten des Projektmanagementplans ein. Dies ist der Kern dieses Abschnitts.

Die erforderlichen Änderungen umfassen korrektive Maßnahmen, die darauf abzielen, das Projekt wieder in Übereinstimmung mit dem Projektbasisplan zu bringen oder Mängel in den Lieferobjekten zu beheben, die nicht den festgelegten Anforderungen genügen. Diese Änderungen sind reaktiver Natur. Zusätzlich könnten Änderungen als proaktive Maßnahmen eingeführt werden, um zukünftige Abweichungen vom Projektbasisplänen vorzubeugen. Diese Maßnahmen sind präventiver Art.

Die notwendigen Änderungen können sich entweder auf den Projektbasisplan auswirken oder nicht:

• Wenn sie den Projektbasisplan nicht beeinflussen, fallen sie in den Zuständigkeitsbereich des Projektmanagers.
• Beeinflussen die erforderlichen Änderungen jedoch den Projektbasisplan, so müssen sie einem formalen Änderungskontrollprozess unterzogen werden. Dieser Prozess dient der Überprüfung und Genehmigung durch die zuständige Änderungskontrollinstanz, die entweder der Sponsor oder ein spezieller Ausschuss sein kann. In großen Projekten, bei denen die ausführende Organisation ein Konsortium ist, kann dieser Änderungskontrollausschuss alle Mitglieder des Projektmanagementausschusses einschließen, um über signifikante Änderungen zu beraten.

Der Änderungskontrollprozess, die beteiligten Akteure und die entsprechenden Autoritätsniveaus sind im Änderungsmanagementplan definiert. Dieser Plan ist ein wesentlicher Bestandteil des Projektmanagementplans und zählt zu den Hilfsmanagementplänen, die zusammen den gesamten Projektmanagementplan bilden.

Die Notwendigkeit einer ganzheitlichen Betrachtung von Änderungen resultiert aus der Interdependenz aller Projektbereiche. Sicherlich ist es nicht ratsam, Überstunden einzuplanen, um den Terminplan wegen einer Verzögerung bei einer kritischen Aktivität zu straffen, ohne dabei die Auswirkungen auf die Kosten, das Teamgefühl und die Qualität in Betracht zu ziehen. Ebenso wenig ist es zielführend, Kosten zu senken, indem Testphasen reduziert werden, ohne die daraus resultierenden möglichen Einbußen bei der Kundenzufriedenheit durch eine verringerte Qualität zu bedenken.

Den Änderungskontrollprozess haben wir bereits in der Lektion über das Controlling des Projektinhalts und -umfangs behandelt. In dieser Lektion präsentieren wir eine Zusammenfassung dieses Prozesses, die sich nicht nur auf Änderungen des Inhalts- und Umfangsbasisplans beschränkt. Stattdessen erweitert sie den Fokus auf alle Arten von Projektänderungen, die einen der Projektbasispläne beeinträchtigen, nicht ausschließlich den Inhalts- und Umfangsbasisplan.

Hier ist der Ablauf des Änderungskontrollprozesses:

• Änderungsanfragen müssen schriftlich eingereicht werden, um sie nachverfolgbar zu machen. Hierzu ist das Änderungsantragsformular sowie das Änderungsregister zu verwenden.
• Die Person, die die Änderung beantragt, muss den Zweck und das Leitziel der Änderung erläutern.
• Der Projektmanager erstellt ein Arbeitspaket, um die Auswirkungen der Änderung auf den Projektbasisplan, mögliche Alternativen zu der Änderung und die damit verbundenen Risiken der Änderung und der Alternativen zu analysieren.
• Die Änderungsanfrage wird zur Entscheidung an die Änderungskontrollinstanz weitergeleitet.
• Die Änderungskontrollinstanz genehmigt, lehnt ab oder verschiebt die Anfrage. Bei einer Genehmigung werden die Auswirkungen auf den Projektmanagementplan in die Genehmigung aufgenommen.
• Der Projektmanager trägt die Entscheidung in das Änderungsantragsformular und in das Änderungsregister ein.
• Anschließend aktualisiert der Projektmanager den Projektmanagementplan. Diese Aktualisierungen müssen die neuen Kostenschätzungen, die überarbeitete Reihenfolge der Aktivitäten sowie die angepassten Fertigstellungstermine für die Lieferobjekte enthalten. Ebenfalls sind die neuen Ressourcenanforderungen und erweiterten Risikobewältigungsstrategien zu berücksichtigen.
• Zum Abschluss informiert der Projektmanager die Teammitglieder und andere relevante Stakeholder gemäß den Vorgaben des Kommunikationsmanagementplans über die Änderungsentscheidung. Änderungen sollten darüber hinaus ein fester Bestandteil aller Projektstatusberichte und sämtlicher Tagesordnungen von Teamsitzungen sein.

Genehmigte Änderungen werden, wie jedes andere Arbeitspaket auch, in umzusetzende Maßnahmen überführt. Bei Bedarf konsultieren Sie bitte die Lektion zur „Umsetzung genehmigter Änderungen und Korrekturmaßnahmen“, die zu den Inhalten der Projektausführung gehört.

Ein spezieller Fall tritt ein, wenn das Arbeitspaket zur Untersuchung der Auswirkungen einer Änderung so umfangreich ist, dass es die vorhandenen Risikozuschläge gefährdet. In einem solchen Fall muss der Projektmanager zunächst eine Genehmigung für die Durchführung dieser Untersuchungsarbeit einholen. Lehnt der Sponsor die Bereitstellung der Mittel für die Untersuchung ab, hat dies zur Folge, dass auch die ursprüngliche Änderungsanforderung abgelehnt wird. Diese muss dann im Änderungsregister als abgeschlossen vermerkt und entsprechend kommuniziert werden.

In einigen Projekten definiert der Projektauftrag ein spezifisches Maß an Autorität für den Projektmanager, der ihm erlaubt, eigenständig über Änderungen bis zu einem bestimmten Niveau zu entscheiden, ohne die Zustimmung eines Änderungskontrollausschusses einholen zu müssen.

Zusammenfassend lösen Abweichungen vom Projektmanagementplan Änderungen aus, die, sofern sie den Projektbasisplan beeinträchtigen, einen formellen Änderungskontrollprozess durchlaufen müssen. Dieser Prozess ist notwendig, damit die im Projektmanagementplan vorgesehene Änderungskontrollinstanz die Änderungen überprüfen und genehmigen kann.

Es ist essenziell, eine integrierte Betrachtungsweise für Änderungsanfragen zu nutzen, da alle Projektbereiche miteinander verbunden sind.

Eine formelle Änderungsanforderung sollte daher nicht nur den Zweck der Änderung, sondern auch mögliche Alternativen und die Auswirkungen auf sämtliche Komponenten der Projektbasisplans sowie die damit verbundenen Risiken berücksichtigen.

Genehmigte Änderungen werden in Arbeitspakete umgewandelt und müssen wie jedes andere Arbeitspaket umgesetzt werden.

 

 

4.8 Kontrolle der Risiken, der Kommunikationseffektivität und des Stakeholderengagements, der Beschaffungen und der materiellen Ressourcen

Dieser Abschnitt widmet sich den Kontrollaktivitäten für die verbleibenden Elemente des Projektmanagementplans. Diese Prozesse umfassen das Sammeln von Rohdaten aus den Ausführungsprozessen und deren Analyse im Gesamtkontext des Projekts. Durch die Analyse und Kontextualisierung werden die Rohdaten in aussagekräftige Informationen über die Arbeitsleistung umgewandelt. Ein Vergleich dieser Informationen mit dem Projektmanagementplan dient der Identifikation von Planabweichungen. Um diese Abweichungen zu adressieren, initiiert der Projektmanager entsprechende Änderungen sowie korrektive und präventive Maßnahmen in verschiedenen Bereichen des Projektmanagementplans.

In vorangegangenen Abschnitten haben wir bereits das Controlling des Inhalts und Umfangs, des Terminplans, der Kosten, der Qualität, der Probleme und der allgemeinen Änderungen behandelt. In diesem Abschnitt konzentrieren wir uns nun auf das Controlling der übrigen Elemente des Projektmanagementplans, einschließlich der Risiken, der Kommunikationseffektivität, des Stakeholderengagements, der Beschaffungen und der materiellen Ressourcen.

Diese Aspekte des Projektcontrollings werden wir nacheinander betrachten.

Kontrolle der Risiken.

Das Risikocontrolling beinhaltet das Generieren zuverlässiger Informationen über die gesamte Risikoexposition des Projekts sowie über einzelne Risiken. Ziel ist es, dem Projektmanager und dem Sponsor fundierte Entscheidungsgrundlagen zu bieten. Um dies zu gewährleisten, überwacht das Projektmanagementteam fortlaufend die Risikosituation. Dies umfasst die Überprüfung, ob sich identifizierte Risiken verändert haben, ob die Risikobewältigungsstrategien wie erwartet funktionieren, ob neue Risiken entstanden sind und ob bestimmte Annahmen sich zu Risiken entwickelt haben. Es ist wichtig zu bedenken, dass Risiken und Annahmen eng miteinander verbunden sind und von der subjektiven Einschätzung ihrer Wahrscheinlichkeiten und Auswirkungen abhängen. Weiterhin wird überprüft, ob die Risikomanagementprozesse eingehalten werden, ob Anpassungen an den Risikozuschlägen bezüglich Kosten und Terminen erforderlich sind und ob die Gesamtstrategie des Projekts aus Risikoperspektive noch angemessen ist.

Nach Bedarf werden Korrekturmaßnahmen ergriffen, die zu Modifikationen im Projektmanagementplan führen. Auch andere Dokumente wie die Register von Annahmen, Problemen, gesammelten Erfahrungen und Risiken müssen überprüft und gegebenenfalls aktualisiert werden. Die resultierenden Änderungen werden als Arbeitspakete umgesetzt und wie jedes andere Arbeitspaket geplant, ausgeführt sowie überwacht und gesteuert.

Kontrolle der Kommunikationseffektivität und des Stakeholderengagements.

Der Zweck des Controllings der Kommunikationseffektivität und des Stakeholderengagements besteht darin, einen optimalen Informationsfluss zu gewährleisten und die notwendige Unterstützung der Projektbeteiligten sicherzustellen. Dabei stützen wir uns auf die Hilfsmanagementpläne: den Kommunikationsmanagementplan und den Stakeholderengagementplan. Diese Pläne legen fest, wie, wann und mit welchen Stakeholdern wir kommunizieren und welche Strategien wir anwenden, um die Unterstützung der wichtigsten Stakeholder zu gewinnen und zu erhalten. Bei der Umsetzung dieser Kontrollmaßnahmen überprüfen wir regelmäßig, ob die Kommunikationseffektivität und das Stakeholderengagement den Zielvorgaben entsprechen. Zufriedenheitsumfragen zu vordefinierten Meilensteinen liefern konkrete Daten, die aufzeigen, in welchen Bereichen der Kommunikation Verbesserungen notwendig sind, in welchem Umfang und bei welchen Stakeholdern Engagementdefizite bestehen.

Ein weiteres effektives Werkzeug ist die Bewertungsmatrix für das Stakeholderengagement. Das Projektmanagementteam aktualisiert diese Matrix basierend auf eigenen Beobachtungen und vergleicht die aktuellen mit den gewünschten Einbindungsniveaus der Stakeholder. Dabei steht „A“ für den aktuellen Zustand und „S“ für den Sollzustand. Die Unterschiede zwischen dem aktuellen und dem gewünschten Zustand jedes Stakeholders bilden die Grundlage zur Definition spezifischer Maßnahmen, die notwendig sind, um das angestrebte Engagementniveau zu erreichen.

Stakeholder	Nicht informiert	Widerständig	Neutral	Positiv eingestellt	Leader
Stakeholder 1	A			S
Stakeholder 2		A	S
Stakeholder 3				AS

Die Bewertungsmatrix für das Stakeholderengagement offenbart, dass Stakeholder 1 positiv eingestellt sein sollte, derzeit jedoch nicht ausreichend über das Projekt informiert ist.

Um diesen Zustand zu verbessern, müssen wir gezielt Kommunikationsmaßnahmen einsetzen. Im Fall von Stakeholder 2, der dem Projekt derzeit widerständig gegenübersteht, besteht das Ziel darin, seine Einstellung zumindest auf eine neutrale Ebene zu bringen, falls eine positive Einstellung nicht erreichbar scheint. Hierfür ist die Entwicklung einer spezifischen Strategie zur Neutralisierung seiner Bedenken erforderlich. Stakeholder 3 befindet sich bereits in der gewünschten Position einer positiven Einstellung. Die Strategie für diesen Stakeholder besteht darin, ihn in diesem Zustand zu halten, indem wir die bereits erfolgreichen Maßnahmen fortsetzen. Das Überwachen des Engagements der Stakeholder erfordert eine regelmäßige Aktualisierung der Bewertungsmatrix, insbesondere an Meilensteinen, basierend auf unseren Beobachtungen und den Kommunikationsaktivitäten mit den Stakeholdern.

Kontrolle der materiellen Ressourcen.

Der Zweck der Kontrolle der materiellen Ressourcen besteht darin, sicherzustellen, dass diese Ressourcen zum richtigen Zeitpunkt und am richtigen Ort für das Projekt verfügbar sind und freigegeben werden, wenn sie nicht mehr benötigt werden. Unbelebte Ressourcen, manchmal auch materielle Ressourcen genannt, beziehen sich auf Ausrüstungen, Rohstoffe, Einrichtungen und Infrastruktur. Die Art der unbelebten Ressourcen, die ein Projekt benötigt, hängt vom Produkt und der Branche ab.

Ein biologisches Projekt kann ein Gerät zur Messung von Endophyten erfordern; ein Bauprojekt kann austenitischen Stahl benötigen; ein Bildungsprojekt kann ein E-Learning-Erweiterungsmodul für eine WordPress-Plattform erfordern; und ein Veranstaltungsprojekt kann Mikrofone und Lautsprecher benötigen. Wie man sieht, ist es nicht möglich, die Materialressourcen, die für alle Projekte erforderlich sind, zu verallgemeinern. Bei materialintensiven Projekten wie zum Beispiel Bauprojekten ist das Controlling der materiellen Ressourcen essenziell und sorgt dafür, dass diese rechtzeitig, am richtigen Ort und in der benötigten Menge verfügbar sind und nach ihrem Einsatz umgehend freigegeben werden, um das Projekt effizient und kostenbewusst voranzutreiben. Was für alle Projekte in Bezug auf die Kontrolle der Materialressourcen gemeinsam ist, ist, dass das Managementteam die tatsächliche Nutzung im Vergleich zur geplanten Nutzung dieser Ressourcen überwachen und bei Bedarf Korrekturmaßnahmen ergreifen muss. Kommen wir nun zum nächsten und letzten Kontrollbereich…

Kontrolle der Beschaffungen.

Der Zweck der Kontrolle der Beschaffungen besteht darin, sicherzustellen, dass beide Vertragsparteien, Verkäufer und Käufer, die vertraglichen Bedingungen einhalten. Aufgrund des rechtlichen Aspekts der Beschaffungsbeziehungen haben viele Organisationen eine eigene Einkaufsabteilung, die sich mit der Verwaltung von Verträgen mit Lieferanten befasst. Es ist eine gute Projektmanagementpraxis, die Person aus der Einkaufsabteilung, die für die Vertragsverwaltung zuständig ist, in das Projektteam einzubeziehen. Abgesehen von dieser Besonderheit werden Arbeitspakete, die von externen Lieferanten erbracht werden, wie jedes andere Arbeitspaket verwaltet, vielleicht mit etwas mehr Aufmerksamkeit auf die formellen Aspekte der Beziehung, als wenn es Kollegen aus der eigenen Organisation wären. Ein zentrales Anliegen beim Kontrollieren von Beschaffungen ist sicherzustellen, dass die Zahlungen an die erbrachte Arbeit gekoppelt sind.

Hier zeigt die Analyse des Fertigstellungswerts (EVA) ihr volles Potenzial. Tatsächlich wurde diese Technik speziell vom US-Militär entwickelt, um sicherzustellen, dass die Zahlungen an Lieferanten dem vom Projekt erzielten Wert entsprechen.

Zusammenfassung lässt sich sagen, dass die Kontrollaktivitäten von Risiken, der Effektivität der Kommunikation, der Beteiligung der Stakeholder, der Materialressourcen und der Beschaffungen gemeinsam haben, dass sie Kontrollaktivitäten sind. Das bedeutet, dass es notwendig ist, die Rohdaten aus der Ausführung zu verfolgen und zu überprüfen, sie zu kombinieren und im Gesamtkontext des Projekts zu analysieren, um die Rohdaten in aussagekräftige Informationen über die Leistung der laufenden Arbeit zu verwandeln. Dies ermöglicht die Identifizierung von Abweichungen im Vergleich zu den Plänen. Um diese Abweichungen zu korrigieren, initiiert der Projektmanager Änderungen und ergreift korrektive sowie präventive Maßnahmen in Form von Arbeitspaketen, um sie wie jedes andere Arbeitspaket umzusetzen.

 

 

 

4.9 Kontrolle der Phasenübergänge

Dieser Abschnitt bezieht sich auf die Kontrollaktivitäten an den Phasenübergängen des Projekts. Der Zweck der Aufteilung eines Projekts in Phasen besteht darin, sein Management zu erleichtern und die Durchführung von Projektprüfungen an den Übergängen zwischen den Phasen zu ermöglichen.  Diese Phasenabschlusspunkte sind auch unter anderen Bezeichnungen wie Haltepunkte, Übergabepunkte oder Übergangspunkte bekannt, um nur einige der in der beruflichen Praxis verwendeten Konventionen zu nennen. Unabhängig vom gewählten Namen finden die Projektprüfungen an den Phasenabschlusspunkten am Ende jeder Phase statt.

Ihr Zweck ist es, der Projektgovernanceinstanz zu ermöglichen, die abgeschlossene Phase zu bewerten, eine informierte Entscheidung darüber zu treffen, ob das Projekt mit der nächsten Phase fortgesetzt werden soll und, falls ja, die Planung der nächsten Phase zu genehmigen. Schließlich gibt es administrative Aktivitäten, die mit dem Abschluss jeder Phase verbunden sind. Lassen Sie uns diese Aspekte einzeln betrachten.

Planung der nächsten Phase.

Beginnen wir mit der Planung der nächsten Phase, da die Planung jeder Phase die Grundlage für die Bewertung dieser Phasen am Ende darstellt. Jede Phase sollte eine in den vorherigen Phasenabschlusspunkten ausgestellte Phasenplanung haben. Für die erste Phase geschieht dies nach der Genehmigung des Plans für die Projektmanagement. Der Abschluss der letzten Phase fällt mit dem Abschluss des gesamten Projekts zusammen. Wir werden den Projektabschluss in einer separaten Lektion behandeln. Die Phasenplanung ist eine abgekürzte Version des Plans für die Projektmanagement, die sich auf die Liefergegenstände und Aktivitäten der nächsten Phase konzentriert. Es sollte ein Phasenziel, messbare Ziele, die zu diesem Ziel führen, mit diesen Zielen abgestimmte Liefergegenstände, Identifizierung und Analyse der Stakeholder, Identifizierung, Analyse und Reaktion auf Risiken, eine detaillierte Aufgliederung der Arbeitspakete der Phase, einen Terminplan mit dem für die Phase angemessenen Detaillierungsgrad und die Kostenbasis der Phase geben. Ein weiterer Aspekt der Planung der nächsten Phase ist die Validierung der Annahmen und Einschränkungen, auf denen die vorherige Planung basierte. Annahmen und Einschränkungen sind für jeden Plan wesentlich.

 

Bewertung der abschließenden Phase.

Der Ausgangspunkt für die Bewertung einer Phase am Ende ist die Planung dieser Phase.  Der Kern der Bewertung besteht darin zu überprüfen, ob die Ziele der Phase erreicht wurden, was sich in der Lieferung des erwarteten Umfangs, in der vorgesehenen Termin und gemäß den im Phasenplan festgelegten Kosten widerspiegelt. Die Analyse des Fertigstellungswerts (EVA) ist eine praktische Methode, um diese Übereinstimmung zu demonstrieren. Da das Ende einer Phase mit der Fertigstellung der wichtigsten Liefergegenstände der Phase zusammenfallen sollte, ist es ein guter Zeitpunkt für diese Analyse, und sie sollte keine laufenden Liefergegenstände zeigen.

Andernfalls wäre das Ende der Phase nicht gut definiert, da jeder Liefergegenstand so aufgeteilt werden sollte, dass die Enden der Phasen mit der Fertigstellung der Komponenten des Liefergegenstands übereinstimmen. Die Analyse des Fertigstellungswerts wird anzeigen, ob alle Liefergegenstände der Phase abgeschlossen sind und welche Leistungsindizes für Kosten und Terminplan erreicht wurden. Wenn der Kostenentwicklungsindex (CPI) und der Terminentwicklungsindex (SPI) für alle Liefergegenstände der Phase gleich 1 sind, dann wurden die Ziele der Phase vollständig erreicht. Eine Abweichung würde einen Erfolgsgrad von unter oder über 100% anzeigen. Eine Zufriedenheitsumfrage unter den relevanten Stakeholdern sollte die Bewertung ergänzen, wobei der Schwerpunkt auf der Zufriedenheit mit der Arbeit des Projektteams liegt, da jeder Liefergegenstand seine eigenen Akzeptanzkriterien hat.

Zum Beispiel: Haben wir professionelle Antworten rechtzeitig gegeben? Waren wir leicht zugänglich? Wurden Probleme professionell gelöst? War es angenehm, mit uns zu arbeiten? Gelernte Lektionen sind eine weitere wertvolle Aktivität für den Abschluss einer Phase.  Tatsächlich sind gelernte Lektionen eine Teamübung, die häufiger als nur an Phasenabschlusspunkten durchgeführt werden sollte. Retrospektive Meetings können organisiert werden, wenn das Team einen wichtigen Meilenstein erreicht.

Der Abschluss einer Phase ist ein wichtiger Meilenstein. Aber es gibt auch Zwischenmeilensteine in jeder Phase, die für Zwischenretrospektiven genutzt werden sollten. Auf keinen Fall sollte man warten, bis das Projekt endet, um darüber nachzudenken, was besser hätte gemacht werden können. Dann ist es zu spät. Eine hervorragende Praxis, die von agilen Teams popularisiert wurde, ist die Durchführung von Retrospektiven am Ende jeder Iteration, die in der Regel zwei Wochen dauert. Vor allem ist eine Retrospektive keine Schuldzuweisung oder Suche nach Schuldigen. Die Retrospektive ist eine Gelegenheit für das Team, aus vergangenen Arbeiten zu lernen und kleine Verbesserungen vorzunehmen. Es geht nicht darum, das Produkt zu inspizieren. Dies geschieht in einer Qualitätsüberprüfungssitzung der Liefergegenstände, wie in der Lektion über die Definition, Delegation und Genehmigung der Arbeitspakete erklärt wurde. Wenn auf diese Weise Lehren gezogen wurden, müssen wir jetzt, beim Abschluss der Phase, nicht von vorne anfangen, um Verbesserungsmöglichkeiten für Dinge zu identifizieren, die vor Wochen oder sogar Monaten passiert sind, wenn es sich um ein großes Projekt mit langen Phasen handelt. Stattdessen kann das Team während einer Phasenretrospektive auf den Pool der während der Phase gelernten Zwischenlektionen zurückgreifen.

Denken Sie daran, dass gelernte Lektionen im Register der gelernten Lektionen festgehalten werden sollten. Daher bietet der Abschluss einer Phase eine gute Gelegenheit, die wichtigsten Erkenntnisse zu destillieren und zu bewahren. Die zwei Schlüsselfragen sind: Was wurde gut gemacht? Und was hätte besser gemacht werden können? Die Vorteile dieser Praxis sind offensichtlich: Verbesserung der Teamleistung und sogar eine zufriedenstellendere und glücklichere berufliche Laufbahn.

Entscheidung, ob die Organisation zur nächsten Phase übergehen möchte.

Die Entscheidung, zur nächsten Phase überzugehen, wird aus zwei Perspektiven betrachtet. Eine erste Perspektive ist die Prognose, die sich aus der Analyse des Fertigstellungswerts ergibt. Ist die Prognose negativ, kann die Projektgovernanceinstanz entscheiden, das Projekt abzubrechen oder dessen Umfang zu reduzieren, um einen teilweisen Nutzen zu erzielen, unter Berücksichtigung der ungünstigen Entwicklung. Der zweite Aspekt ist die Überprüfung der Rentabilitätsanalyse. Die Rentabilitätsanalyse diente als Grundlage für die Initiierung des Projekts. Es wurden Annahmen getroffen. Es wurden allgemeine Schätzungen für Lieferzeiten und Kosten vorgenommen, um die Vorteile abzuschätzen. Jetzt, am Ende einer Phase, mit tatsächlichen Ausführungsdaten und aktualisierten Prognosen basierend auf der Analyse des Fertigstellungswerts, ist es an der Zeit, die Rentabilitätsanalyse zu aktualisieren und der Projektgovernanceinstanz zur Bestätigung der Fortsetzung oder Nichtfortsetzung des Projekts vorzulegen. Leider werden zu viele Projekte monate- oder sogar jahrelang fortgeführt, wobei organisatorische Ressourcen verbraucht werden, um ein Ergebnis zu erzielen, das sich sehr von dem in der ursprünglichen Rentabilitätsanalyse projizierten unterscheidet. Das Projektmanagementteam kann ein solches Scheitern vermeiden, indem es sicherstellt, dass das Projekt weiterhin mit den strategischen Zielen der Organisation in Einklang steht. Dies kann durch regelmäßige Validierung des Projekts und seiner Rentabilitätsanalyse während einer Überprüfung an den Phasenabschlusspunkten erreicht werden.

Die Ergebnisse dieses Prozesses können zu einem der folgenden drei Ergebnisse führen:

• Das Projekt wird eingestellt.
• Das Projekt wird fortgesetzt wie es ist.
• Das Projekt wird fortgesetzt, aber mit Änderungen entweder am Projekt selbst oder an der zugrunde liegenden Rentabilitätsstudie.

Eine Entscheidung, ein Projekt nicht fortzusetzen, ist nicht unbedingt ein Misserfolg. Projekte können aufgrund externer Faktoren, die die Geschäftsgrundlage ungültig machen, oder einfach, weil die Organisation andere Prioritäten hat und die für das Projekt vorgesehenen Ressourcen für andere Initiativen benötigt, scheitern oder beeinträchtigt werden.  Ein Misserfolg liegt vor, wenn ein Projekt fortgeführt wird, obwohl es besser wäre, es nicht zu tun.

Administrativer Abschluss.

Das wichtigste Element des administrativen Abschlusses ist die Bestätigung, dass die Liefergegenstände der Phase formell akzeptiert und an die entsprechende Organisation übergeben wurden. Wenn der übertragene Liefergegenstand ein Endprodukt ist, ist der Empfänger der Kunde. Dies wäre der Fall, wenn das Projekt das Produkt in Inkrementen liefert. Ist der Liefergegenstand jedoch ein Bestandteil eines größeren, in Produktion befindlichen Produkts, ist der Empfänger das neue Team, für das der Liefergegenstand der abgeschlossenen Phase ein Bestandteil für die nächste Phase ist.  Beachten Sie, dass die Annahme der Liefergegenstände nicht Teil der Abschlussaktivitäten der Phase ist. Jeder Liefergegenstand sollte bereits formell angenommen worden sein, wie im Abschnitt “Definition, Delegation und Annahme von Arbeitspaketen” erklärt. Was wir beim Abschluss der Phase tun, ist die Bestätigung, dass die Annahme stattgefunden hat. Es sollte ein Dokument geben, das als Nachweis der Annahme jedes Liefergegenstands dient. Fehlt ein Annahmedokument, ist jetzt der Zeitpunkt, es zu beschaffen.

Ein weiteres wichtiges Element des administrativen Abschlusses einer Phase ist die Freisetzung von Ressourcen, die in der nächsten Phase nicht mehr benötigt werden. In diesem Kontext werden Leistungsbewertungen durchgeführt. Überprüfen Sie gegebenenfalls den Abschnitt über die Aktivitäten des Projektleiters während der “Auflösungsphase des Teams” in der Lektion über “Teamentwicklung”. Beachten Sie auch, dass Ressourcen nicht nur Personalressourcen sind. Auch Einrichtungen, Ausrüstungen, überschüssiges Material und andere Materialressourcen, die nicht mehr benötigt werden, müssen freigesetzt werden.  Wenn externe Lieferanten am Projekt beteiligt waren, überprüft der Projektleiter, ob beide Parteien ihre vertraglichen Verpflichtungen erfüllt haben. Falls erforderlich, werden Maßnahmen ergriffen, um das Fehlende zu erhalten. Offene Ansprüche müssen geregelt werden. Bei anhaltenden Unstimmigkeiten muss entweder ein größeres Problem zur Lösung auf Projektgovernance-Ebene eingeleitet oder der Fall an die Rechtsabteilung übergeben werden. In jedem Fall werden Leistungsbewertungen der Lieferanten der Phase durchgeführt.

Weitere Aktivitäten des administrativen Abschlusses umfassen:

• Archivierung der Projektinformationen.
• Sicherstellen, dass alle Projektunterlagen aktuell sind, wie z.B. Problemregister, Lektionenregister, Risiko- und Änderungsregister.

Zusammenfassend lässt sich sagen, dass der Zweck der Phasentorekontrolle darin besteht, der Projektgovernanceinstanz zu ermöglichen, die abschließende Phase zu bewerten, eine informierte Entscheidung darüber zu treffen, ob zur nächsten Phase übergegangen wird und, falls ja, die Planung dieser nächsten Phase zu genehmigen. Administrative Abschlussaktivitäten werden durchgeführt. Die während der Zwischenmeilensteine der Phase gelernten Lektionen werden am Ende jeder Phase wiederverwendet, um die wichtigsten Erkenntnisse zu destillieren. Neue Schlussfolgerungen werden aus der Retrospektive der gesamten Phase gezogen.

 

 

 

 

5.1 Abschluss der letzten Phase und des gesamten Projekts

Dieser Abschnitt erklärt die Besonderheiten des Abschlusses der letzten Phase des Projekts, die mit dem Abschluss des gesamten Projekts zusammenfällt.

Die Überprüfung der Akzeptanz und der Übergang der erbrachten Liefergegenstände, die Leistungsbewertung, Entscheidungen über die Fortsetzung des Projekts, die Freisetzung von Ressourcen und andere administrative Abschlussaktivitäten, die bereits erklärt wurden, werden an jedem Phasenabschlusspunkt durchgeführt. Am Ende der letzten Phase, die auch das Ende des Projekts ist, ist es jedoch nicht leicht zu bestimmen, welche Abschlussaktivitäten zur letzten Phase gehören und welche zum Abschluss des gesamten Projekts. Lassen Sie uns daher die Besonderheiten des Abschlusses der letzten Phase und des gesamten Projekts genauer betrachten.

Überprüfung der Akzeptanz und des Übergangs der erbrachten Liefergegenstände und die Leistungsbewertung.

Ein Bewertungskriterium für eine Phase oder das Projekt ist die Erreichung der Ziele. Und die Ziele beziehen sich auf die Lieferung des definierten Umfangs, innerhalb des festgelegten Zeitrahmens und Budgets, und gemäß jeglichen anderen definierten Erfolgskriterien.

In Bezug auf den Lieferumfang der letzten Phase entspricht diese dem Lieferumfang des gesamten Projekts. Die Akzeptanz und der Übergang des in der letzten Phase gelieferten Umfangs haben einen doppelten Charakter. Einerseits liefert es einen Phasenliefergegenstand, zum Beispiel die Schulung der Benutzer im Umgang mit der Projektlösung.

Da jedoch nichts mehr zu liefern ist, muss diese letzte Lieferung mit der Akzeptanz und dem Übergang des Gesamtliefergegenstand verbunden sein. Die funktionalen Anforderungen und Qualitätsattribute des in der letzten Phase gelieferten Umfangs müssen den Anforderungen des gesamten Projektprodukts entsprechen. Die Produktüberprüfungssitzungen am Ende der letzten Phase müssen nicht nur zeigen, dass die Schulungssitzungen zum Erlernen der Lösung erfolgreich waren. Es muss auch gezeigt werden, dass die Gesamtlösung die Produktanforderungen erfüllt. Daher bezieht sich die Überprüfung der Akzeptanz und des Übergangs der Liefergegenstände sowohl auf den Liefergegenstand der letzten Phase als auch auf den Gesamtliefergegenstand des Projekts.

Was die Leistungsbewertung von Termin und Kostenplan am Ende des Projekts angeht, lässt sich dies am besten mit der Terminplan- und Kostenbasisplan bewerten. Der Grund dafür ist nicht offensichtlich. Lassen Sie uns versuchen, dies zu verstehen.

Die Analyse des Fertigstellungswerts (EVA) ist am Ende eines Projekts nicht sehr nützlich. Ihr Hauptvorteil liegt darin, ein früher Indikator für Trends zu sein. Doch am Ende des Projekts sind der verdiente Wert und der geplante Wert immer gleich 100 %, es sei denn, das Projekt wurde vorzeitig beendet, ohne eine Lösung bereitzustellen. Aber wenn die Lösung geliefert wurde, entspricht die geleistete Arbeit 100 % der geplanten Arbeit. Daher gibt es am Ende des Projekts keine Zeitabweichung, und der Terminentwicklungsindex (SPI) ist immer gleich 1, auch wenn das Projekt verspätet abgeschlossen wurde. Gegen Ende eines Projekts verliert die Analyse des Fertigstellungswerts ihre Nützlichkeit. Ihr großer Vorteil liegt darin, frühzeitig Trends aufzuzeigen.

Bezüglich der Kosten kann die Analyse des Fertigstellungswerts jedoch hilfreich sein, da sie den verdienten Wert – der dem gesamten geplanten Budget entspricht – mit den tatsächlich angefallenen Kosten vergleicht. Zum Beispiel, wenn der gesamte Projektumfang für 100 € geplant war, aber die tatsächlichen Kosten 140 € betrugen, dann zeigt der Kostenentwicklungsindex (CPI) von 0,71 (100 geteilt durch 140) realistisch die Kostenüberschreitung an.

Aufgrund dieser Eigenart ist es am besten, am Ende des Projekts die Analyse des Fertigstellungswerts zu nutzen, um das tatsächliche Lieferdatum mit dem ursprünglichen Basisplan des Terminplans und die tatsächlichen Kosten mit dem Basisplan der Kosten zu vergleichen.

Aber was, wenn sich diese Basisplan im Laufe des Projekts geändert haben? Angenommen, die Basisplan wurden infolge von Änderungskontrollverfahren aktualisiert, um notwendige Änderungen während der Projektlaufzeit zu reflektieren. Wenn diese Änderungen von der Änderungskontrollbehörde genehmigt wurden, dann wurden auch die Auswirkungen dieser Änderungen auf den Termin- und Kostenbasisplan genehmigt.

In solchen Situationen stellt sich die Frage, ob man die Leistung mit den ursprünglichen Basisplan vergleichen sollte. Man könnte argumentieren, dass nein. Der tatsächliche Erfolg sollte mit der neuesten Version der Basisplan verglichen werden. Allerdings hören wir manchmal in den Nachrichten, dass “…das Projekt X (normalerweise ein staatlich finanziertes Projekt) mit einer Kostenüberschreitung von 400 % im Vergleich zum ursprünglichen Budget und drei Jahre später als geplant abgeschlossen wurde…”. Das ist ein Vergleich der tatsächlichen Kosten und Termine mit den ursprünglichen Basisplan, unabhängig von allem, was während des Projekts passiert und geändert wurde. Am Ende eines solchen Projekts sind nicht nur Erklärungen erforderlich. Auch politisches Geschick kann nützlich sein. Wenn Sie als Projektmanager in einem solchen Projekt überlebt haben, haben Sie wahrscheinlich die politischen Fähigkeiten, um zu beweisen, dass das Projekt erfolgreich war. Und wenn Sie der neue Projektmanager sind, der auf halbem Weg ersetzt wurde, ist es offensichtlich, wer politisch für die Kostenüberschreitung und die Verspätung verantwortlich gemacht wird. Selten sehen wir, dass die Sponsoren die Verantwortung für das Scheitern ihrer Projekte übernehmen. Es ist viel häufiger, dass der Projektmanager für das Scheitern zur Rechenschaft gezogen wird.

Die Bewertung der Stakeholder-Zufriedenheit ist sowohl für den Abschluss einer Phase als auch für den Abschluss des gesamten Projekts ein Standardelement. Für Stakeholder, die am gesamten Projekt beteiligt waren, können Sie die Zufriedenheitsumfrage für die letzte Phase und das gesamte Projekt in einer einzigen Umfrage zusammenfassen. Für Stakeholder, die nur in der letzten Phase involviert waren, wäre die Umfrage Teil des Phasenabschlusses.

Gelernte Lektionen sind ebenfalls sowohl ein Teil des Phasenabschlusses als auch des Projektabschlusses. Bezüglich der letzten Phase gibt es spezifische Lektionen, die sich auf die Art der in dieser Phase geleisteten Arbeit beziehen. Wenn Sie diese sammeln, schließen Sie tatsächlich die letzte Phase ab. Wahrscheinlich gibt es Schlussfolgerungen aus den Arbeiten der letzten Phase zu ziehen, wie zum Beispiel bei der Schulung der Nutzer im Umgang mit der Lösung während einer abschließenden Implementierungsphase. Es ist sinnvoll, diese zu sammeln und aufzulisten. Sie werden nicht dazu beitragen, die folgenden Phasen zu verbessern, da es am Ende des Projekts keine nächste Phase gibt. Aber die Organisation wird sicherlich profitieren, wenn ein ähnliches Projekt eine ähnliche Implementierungsphase durchführt.

Die aus der Gesamtperspektive des Projekts gelernten Lektionen können etwas Neues zu dem hinzufügen, was bereits bei jedem Phasenabschluss gesammelt wurde. Andernfalls besteht die Hauptaufgabe am Ende des Projekts darin, die bereits bei jedem Phasenabschluss aufgelisteten Lektionen zu sammeln. Die wichtigsten Lektionen aus der Gesamtperspektive des Projekts zu destillieren, ist wahrscheinlich sehr wertvoll.

Ein Projektabschlussbericht wird die beschriebenen Bewertungsbereiche umfassen, also den Grad der Zielerreichung des Projekts, die Erfüllung des definierten Projektumfangs, die Leistung hinsichtlich Terminplan und Kosten, die Zufriedenheit der Stakeholder und eine Zusammenfassung der gelernten Lektionen. Auch eine Liste von Nachfolgeaktivitäten ist eine gute Idee. Zum Beispiel, um optionale Anforderungen aufzulisten, die vom abschließenden Projekt nicht umgesetzt wurden, aber möglicherweise von einem nachfolgenden Projekt realisiert werden könnten. Oder andere Nachfolgeaktivitäten, die vom neuen Besitzer des Schlüsselliefergegenstands des Projekts durchgeführt werden sollen.

Die Entscheidungen über die Fortführung des Projekts.

In allen vorherigen Phasen gab es einen Prozess der Planung und Genehmigung der nächsten Phase. Am Ende der letzten Phase gibt es jedoch keine weitere Phase mehr zu planen. Daher findet dieser Aspekt der Kontrolle an den Phasenabschlusspunkten in der letzten Phase nicht statt.

Ein vergleichbarer Prozess aus der Gesamtperspektive des Projekts wäre die Planung eines Folgeprojekts. Doch ein solches Projekt sollte nicht am Ende des aktuellen Projekts geplant werden. Die Entscheidung über ein mögliches Folgeprojekt sollte einem Portfoliomanagementprozess unterliegen, der auf der Ebene der Organisationsführung gesteuert wird. Vielleicht hat die Organisationsleitung andere Prioritäten als die Durchführung eines Folgeprojekts, um bestimmte Anforderungen zu erfüllen, die während des nun endenden Projekts aufgeschoben wurden.

Wenn das abgeschlossene Projekt Teil eines Programms ist, ist es sehr wahrscheinlich, dass ein anderes Projekt des Programms das Schlüssellieferobjekt des betreffenden Projekts als notwendigen Bestandteil oder Katalysator nutzt. Aber dieser Aspekt gehört zur Disziplin des Programmmanagements.

Daher gilt dieser Aspekt des Abschlusses weder für die letzte Phase eines Projekts noch für ein gesamtes Projekt bei seinem Abschluss. Zumindest nicht aus der Perspektive des Projektmanagements. Möglicherweise ja, aus der Perspektive des Programmmanagements, wenn das abgeschlossene Projekt nicht das letzte Projekt des Programms ist.

 

 

Administrativer Abschluss.

Am Ende der letzten Phase des Projekts müssen spezifische administrative Abschlussaktivitäten für die letzte Phase durchgeführt werden. Da es auch das Ende des Projekts ist, mögen diese Aktivitäten wie Projektabschlussaktivitäten erscheinen, aber aus konzeptioneller Sicht handelt es sich um einen Phasenabschluss.

Beispielsweise stellt das Freisetzen von Ressourcen, die in der letzten Phase genutzt wurden, einen Phasenabschluss dar. Gleiches gilt für spezifische Lieferanten der Phase. Die Bewertungen werden durchgeführt, wie sie am Ende jeder anderen Phase durchgeführt würden.

Wenn Ressourcen und Lieferanten während des gesamten Projekts eingesetzt wurden, wurden sie nicht am Ende der vorherigen Phasen freigesetzt. Sie werden nun am Ende des Projekts freigegeben. Konzeptionell wäre dies Teil des Projektabschlusses. Das hindert das Projektmanagementteam jedoch nicht daran, sie am Ende jeder vorherigen Phase zu bewerten.

Wenn offene Forderungen bestehen, müssen diese sicherlich am Ende des Projekts geklärt oder an die Rechtsabteilung übergeben werden, da das Projekt nach seinem Abschluss nicht mehr existieren wird.

Was das Archivieren der Projektinformationen und die Aktualisierung aller Projektunterlagen betrifft, so werden auch diese letzten Aktivitäten des Phasenabschlusses am Ende der letzten Phase durchgeführt. Eine Gesamtperspektive des Projektabschlusses für diese Art von Aktivitäten wäre, alle diese Unterlagen zu konsolidieren und zu bereinigen und sie dann in das entsprechende organisatorische Repository zu übertragen.

Der Erfolgsgrad des Projekts.

Am Ende des Projekts gibt es zwei wichtige Fragen zu beantworten: War das Projekt erfolgreich? Und gibt es noch weitere Aufgaben zu erledigen?

Um diese Fragen zu beantworten, ist es hilfreich, das Projektauftrag erneut zu betrachten, welches die Erfolgskriterien des Projekts und die Geschäftsanforderungen enthält.

Die Frage nach dem Projekterfolg wird durch die Bewertungselemente beantwortet, die wir bereits erklärt haben.

Was die im Projektauftrag formulierten Geschäftsanforderungen betrifft, geht es um die Fähigkeiten, die die Organisation zu Beginn des Projekts erlangen möchte. Ein “Ja” auf diese Frage hängt von der Qualität der Projektumfangsdefinition ab. Achtung, wir sprechen hier von der Qualität der Definition des Umfangs, nicht von der Qualität des gelieferten Umfangs. Wir haben bereits bewertet, in welchem Maße, wann und zu welchen Kosten der definierte Umfang geliefert wurde. Aber die Frage, ob die Geschäftsanforderungen erfüllt wurden, lädt uns dazu ein, zu fragen, inwieweit dieser Umfang richtig definiert wurde, um die von der Organisation gewünschten Geschäftsfähigkeiten zu erlangen.

Wenn wir bei der Erstellung des Projektauftrags gute Arbeit geleistet haben, wird die Antwort ein “Ja” sein. Falls es jedoch eine Diskrepanz zwischen den Geschäftsanforderungen und dem definierten Schlüsselliefergegenstand gab, der angeblich diese Fähigkeiten bereitstellen sollte, dann haben wir im besten Fall einen Umfang geliefert, der den Produktanforderungen entspricht, innerhalb des Terminrahmens und des Budgets, aber der nicht alle von der Organisation in der Liste der Geschäftsanforderungen benötigten Fähigkeiten erzeugt hat. Das wäre ein schlecht definierter, aber gut gelieferter Umfang. Ein weiteres Projekt wäre nötig, um diese Lücke zu füllen. Und das abschließende Projekt würde eine weniger als perfekte Bewertung erhalten, obwohl es den definierten Umfang rechtzeitig und im Budget geliefert hat.

Ein weiterer und letzter Aspekt, der zu berücksichtigen ist, sind die Vorteile. Dies ist ein heikler Punkt, da er die Erfolgserklärung des Projekts und damit die Karriere des Projektmanagers beeinflussen kann. Während die Überprüfung der Vorteile natürlich in das Programmmanagement passt, kann es im Projektmanagement ein zweischneidiges Schwert sein.

Der Schlüssel liegt darin, wie das Projektauftrag in Bezug auf die erwarteten Vorteile strukturiert ist. Bei Projekten, die Lösungen iterativ liefern, kann es sein, dass der Kunde Vorteile wahrnimmt, bevor das Projekt abgeschlossen ist. Bei anderen, wie zum Beispiel einem Projekt, dessen Ergebnis eine Verdopplung der Transaktionsgeschwindigkeit ist, kann es möglich sein, unmittelbar nach Projektabschluss eine Zunahme der Kundenzufriedenheit zu messen, zumindest unter Verwendung einer repräsentativen Stichprobe der Kundenbasis, um den Vorteil zu messen.

Es gibt jedoch Projekte, bei denen sich die Vorteile, wie das Erreichen eines bestimmten Umsatzniveaus, die Kundenbindung oder eine Senkung der Sterblichkeitsrate, erst lange nach Projektabschluss materialisieren. In diesen häufigen Szenarien liegt die Verantwortung für die Bewertung der Vorteile eher beim Programmleiter oder Sponsor als beim Projektmanager. Dies unterstreicht die Bedeutung eines gut definierten Projektauftrags.

Abschließend zum Thema des Abschlusses der letzten Phase und des gesamten Projekts: Sie sind am Ende dieses Kurses angelangt.

Herzlichen Glückwunsch!