PRINCE2 Agile® Foundation

Wichtig, aber wahrscheinlich informell. Es wird der Phasenstatus zusammengefasst und über mögliche Issues und Risiken berichtet. Enthält Informationen über Releases und Sprints und ermöglicht Vorteile. Könnte in Form eines Informationradiator und/oder eines Burn-Charts erfolgen

Bericht, in dem der Projektmanager den Lenkungsausschuss in festgelegten, regelmäßigen Abständen über die in einer Managementphase erzielten Fortschritte (Phasenstatus) unterrichtet - inklusive möglicher Issues und Risiken.

• Teamstatusbericht
• Projektstatusbericht
• Projektbeschreibung
• Projektleitdokumentation
• Projektproduktbeschreibung
• Arbeitspaket

1. Projekt-Mandat (Project Mandate) 
2. Nutzenmanagement-Ansatz (Benefits Management Approach) 
3. Business-Case (Business Case) 
4. Risikohandbuch (Risk Register) 
5. Stakeholder-Engagement-Ansatz (Stakeholder Engagement Approach) 
6. Kommunikationsmanagement-Ansatz (Communication Management Approach) 
7. Qualitätsmanagement-Ansatz (Quality Management Approach) 
8. Protokoll der Qualitätsprüfungen (Quality Register) 
9. Arbeitspaketbeschreibung (Work Package Description) 
10. Produktbeschreibung (Product Description - detaillierter als Projektproduktbeschreibung
11. ) 
12. Produkt-Fluss-Diagramm (Product Flow Diagram) 
13. Voraussetzungen für die Nutzung des Projektergebnisses (Configuration Item Record) 
14. Qualitätsprüfungsprotokoll (Quality Check Record) 
15. Eintrag im Risikohandbuch (Risk Response Record) 
16. Qualitätsanzeige (Quality Indicator)
17. Issue-Log 
18. Lessons-Logbuch (Lessons Log)
19. Überwachungsnotizen (Checkpoint Report)
20. Projektplan (Project Plan) 
21. Arbeitspaket-Eintragungen (Work Package Records) 
22. Erfassung der Projektleistung (Project Product Description) 
23. Fortschrittsberichte (Highlight Report) 
24. Risikobericht (Risk Report) 
25. Qualitätsbericht (Quality Review Record) 
26. Projektabschlussbericht (Project Product Description) 
27. Produktstatusaccount (Issue Report)

Zusammenfassend 
Projektproduktbeschreibung:
Fokus auf Endprodukt

Projektbeschreibung:
Definiert Rahmen des Projekts 

Produktbeschreibung: 
Beschreibt spezifische Details der Produkte

Geneuer
===

1. Projektproduktbeschreibung: 
 Fokus auf Endprodukt. Definiert
 - Charakteristiken
 - Referenz für Funktionen und Qualitätskriterien des Endprodukts
- Zweck des Projektprodukts
- Erarbeitung: Gemeinsam mit größerem Projektmanagement-Team (Workshop?) 

 2. Projektbeschreibung: 
 Legt den Rahmen gesamtes Projekt fest. Umfasst:
 - Zweck des Projekts
 - Ziele
 - Liefergegenstände
 - Kundenerwartungen
 - wichtige Annahmen und Abhängigkeiten. 
 Bildet die Grundlage für die gesamte Projektplanung und -durchführung. 

 3. Produktbeschreibung: 
 Detaillierte Informationen zu den Produkten. Beschreibt:
 - spezifische Eigenschaften
 - Funktionen
 - Qualitätskriterien
 - Anforderungen an einzelne Produkte

1. Business Case
2. Teamstatusbericht
3. Projektstatusbericht
4. Projektbeschreibung
5. Projektleitdokumentation
6. Projektproduktbeschreibung
7. Arbeitspakete

1 Pünktlich liefern und Fristen einhalten (verringert die Wahrscheinlichkeit von Kostenüberschreitungen bei festen Ressourcen, frühzeitige Realisierung von Nutzen, Ruf bei Kunde, Planung Abhängigkeiten)

2 Das Qualitätsniveau sichern (durch Schulungen, ausreichend Zeit zum Testen, unvollständige Dokumentation gefährdet Qualität, fördert die Motivation der Benutzer-Community)

3 Änderungen willkommen heißen (vermeidet frühzeitig unnötige Details, erfordert einen formellen Prozess zur Änderungssteuerung, legt  Projekt-Baseline auf der richtigen Ebene fest, ermöglicht ein genaueres Endprodukt, User Stories mit ähnlichem Aufwand können ersetzt werden, Kunde ermutigen sich mit Ideen zu beteiligen)

4 Für stabile Teams sorgen
Team bleibt über längeren Zeitraum hinweg unverändert und bleibt konstant. Unterstützt Selbstorganisation am ehesten durch...

• ...Vertrauen und Zusammenarbeit
• ...Effizienz
• ...Kontinuität

5 Akzeptieren, dass der Kunde nicht alles benötigt (Features sicherster Bereich für einen Kompromiss)

Rolle oft auf das gesamte Team verteilt, um eine effektive Zusammenarbeit und Entscheidungsfindung zu fördern

Aufgaben könnten sein:

**Personalmanagement:** Führung, Entwicklung, Unterstützung, Leistungsbewertung, Coaching und Mentoring der Teammitglieder

**Ressourcenmanagement:** (z. B. Zeit, Budget, Personal) um Ziele zu erreichen. Lieferung innerhalb Zeit-, Kosten- und Qualitätstoleranzen.

**Kommunikation:** Effektive Kommunikation im Team, Vermittler Team und Stakeholder 

**Planung und Organisation:** Klare Definition Arbeitsbelastung, Ziele, Fristen. Struktur und Organisation Team sicherstellen.

**Angemessene Erstellung** der Produkte sicherstellen

**Rechenschaftspflichtig für das managen von Risiken auf Lieferebene 

• Keine Interessensvertretung derjenigen, die mit den Projektprodukten arbeiten
• Keine technische Rechenschaftspflicht Gesamtprojekt

Laut HB während des Prozesses "Managen der Produktlieferung" stellt sicher, dass

• Produkte vom Team erstellt und geliefert werden:

• Freigegebene Arbeitspakete vom Projektmanager annehmen und prüfen (abnahme Arbeitspakete)

• Sicherstellen, dass im Arbeitspaket identifizierte Schnittstellen gepflegt werden

• Für die Erledigung der anstehenden Arbeitspaketen einen Teamplan erstellen (kann zeitgleich erfolgen, wenn der Projektmanager den Phasenplan für die Managementphase erstellt)

• Sicherstellen, dass die Produkte gemäß der im Arbeitspaket vorgegebenen Verfahren entwickelt werden

• Mithilfe der in der Produktbeschreibung genannten Qualitätsprüfmethoden, welche auch die P2-Qualitätsprüfungstechnik umfassen können, nachweisen, dass jedes einzelne Produkt die Qualitätskriterien erfüllt

• Die Abnahme fertiggestellter Produkte bei den in der Produktbeschreibung dafür benannten verantwortlichen Stellen einholen

• Die Produkte wie im Arbeitspaket beschrieben an den Projektmanager übergeben

Unkontrollierte Zunahme des Projektumfangs.

Beispiele:

- **Agile Maturity Assessments:**
Diese Assessments bewerten die Reife und den Entwicklungsstand agiler Praktiken in einer Organisation. Sie helfen dabei, die Agilität und Wirksamkeit agiler Prozesse zu bewerten und Verbesserungsbereiche zu identifizieren.

- **Agile Self-Assessments:**
Diese werden von Teams oder Einzelpersonen durchgeführt und dienen dazu, die Umsetzung agiler Praktiken zu bewerten, Schwächen zu identifizieren und Verbesserungsmöglichkeiten zu finden.

- **Agile Health-Checks:**
Diese überprüfen regelmäßig die Gesundheit und Leistungsfähigkeit von agilen Praktiken in Teams oder Organisationen. Sie dienen dazu, Mängel zu erkennen und Anpassungen vorzunehmen, um die Agilität zu verbessern.

- **Agile Team Assessments:**
Diese Assessments konzentrieren sich auf die Leistung und Effektivität spezifischer agiler Teams, um Hindernisse zu identifizieren und Maßnahmen zur Verbesserung der Teamarbeit und Produktivität abzuleiten.

- **Agile Process Assessments:**
Diese bewerten die Effektivität der agilen Prozesse in Bezug auf die Zielerreichung, die Flexibilität und die Fähigkeit, sich an sich ändernde Anforderungen anzupassen. Jedes dieser Assessments und Tools dient dazu, die Agilität in verschiedenen Kontexten zu bewerten und bietet Einblicke in Bereiche, in denen Verbesserungen vorgenommen werden können.

Wird zum Teil dem Lieferteam oder dem Benutzervertreter zugeordnet. Beraterrolle.

Mögliche Verantwortlichkeiten der Rolle:

• prüft bei Bedarf die Projektprodukte, sofern erforderlich

• trägt bestimmte Informationen bei, die möglicherweise für das Projekt relevant sind.

• Anforderungen für den eigenen Interessenbereich festlegen

• Fokus auf Bereiche setzen, die evtl. direkt oder indirekt von dem Projekt betroffen sein können

• Mit den Customer SMEs ein repräsentativeres Bild der Kundenperspektive liefern

• Vertritt die die Entwickler des Produkts
• Rechenschaftspflicht für die Funktionalität des Projekts.
• Kommuniziert Leitlinien in Bereichen wie technische Compliance
• Bietet bei Bedarf Unterstützung für Releases in die betriebliche Nutzung

Informiert AM EHESTEN über Bereiche die Projekte technisch beeinflussen können und gehört zum Teil auch zum Lieferteam.

Ist aber eine spezifische Rolle im Projektmanagement, die die Interessen des Lieferanten oder der Lieferantenorganisation vertritt und die Kommunikation zwischen dem Kunden und dem Lieferanten koordiniert.

Genauer
===
Während der Supplier SME ein Experte auf Seiten des Lieferanten ist, der über spezifisches Fachwissen verfügt, fokussiert sich der Lieferantenvertreter mehr auf die Koordination, Verhandlungen und das Management der Beziehung zwischen dem Kunden und dem Lieferanten.

Daher sind der Supplier SME und der Lieferantenvertreter nicht gleichzusetzen, sondern sie haben unterschiedliche Rollen und Verantwortlichkeiten im Kontext der Lieferantenbeziehung und des Projektmanagements.

ausdrücklich verantwortlich für

• Nachweis der Nutzensrealisierung
• Spezifikation der Anforderungen

Dem Lieferteam zugewiesen. breitere technische Sichtweise, Erstellen der Spezialistenprodukte des Projekts, bei Bedarf technische Beratung.

Übernimmt die anfängliche technische Sicherung. Bringt die erforderliche technischen Kenntnisse (Herstellung, erste Qualitätskontrolle) des Projektprodukts ein.

Sollte(n) mit den Supplier SMEs und anderen Kundenvertretern gemeinsam Produkte weiterentwickeln und Projektstandards sicherstellen, um einen höchstmöglichen Wert für den Kunden zu liefern.

Verantwortlichkeiten der Rolle:

• Spezialistenprodukte des Projekts fertigen

• Die breitere technische Perspektive der entstehenden Produkte im Blick behalten

• Anfängliche technische Sicherungen 

• Mit Kunde Anforderungen weiter ausarbeiten

• Alternativen für Anforderungen erläutern

• Organisations- und Projektstandards sicherstellen

Konsolidiert und kommuniziert die Ansichten des Kunden.

Sollte(n) mit den Supplier SMEs und anderen Kundenvertretern gemeinsam Produkte weiterentwickeln und Projektstandards sicherstellen, um einen höchstmöglichen Wert für den Kunden zu liefern.

Kennt Prozessdetails, Priorisiert Anforderngen auf Detailebene, sichert Übereinstimmung mit Vereinbarungen durch Product Owner, zB 2 Tage pro Woche. (Die  Rolle könnte auch durch die Rolle PO dargestellt werden?)

Um Unsicherheiten aus technischer Sicht zu verringern:

Befristete Arbeit (ein Spike) um eine bestimmte Situation besser zu verstehen. Ein Spike kann in Form eines Prototyps vorliegen oder aus einer Art Forschung bestehen. häufig genutzt um Unsicherheiten aus technischer oder Kundenperspektive zu verringern. Experimente sind ähnlicher Natur.

Konzept, mit dem die Effektivität eines sich selbst organisierenden Teams entwickelt wird. Dies wird erreicht, indem gemeinsam eine Reihe von Teamrichtlinien oder Regeln entwickelt werden, um eine gewisse Struktur in die Arbeitsweise und das Verhalten des Teams zu bringen. Die Teamrichtlinien bzw. Regeln werden nicht vom Projektmanager genehmigt. 

Grundlage für die Steuerung des Projektmanagements während einer Managementphase

PRINCE2 gibt es typischerweise mehrere Phasenpläne, die für verschiedene Abschnitte des Projekts

Erstellung in Prozess "Managen eines Phasenübergangs" pro Managementphase.

Beschreibungen der Produkte innerhalb des Planumfangs der Phase.

Aktivitäten für den Projektabschluss werden bei der Erstellung des Phasenplans der letzten Managementphase geplant.

1. Business Case
2. Organisation
3. Qualität
4. Pläne
5. Risiken
6. Änderungen
7. Fortschritt

Rechenschaftspflichtig für Risikomanagement auf Projektebene

Könnte durch das tägliche Stand-up ersetzt werden, darf aber das Stand-up nicht in "Reporting to..." ändern. Könnte in Form eines Informationradiator und/oder eines Burn-Charts erfolgen.

Eine wichtige Schnittstelle. Bringt PRINCE2® und agiles Arbeiten zusammen.

Gemeinsam definiert.

Eine klare, sichere Grenze der Kontrolle.

Auch Raum, um Teams zur Selbstorganisation zu befähigen und eine umfassende Kommunikation zu ermöglichen.

Kann ein oder mehrere Releases oder Sprints umfassen.

Die 'Tailoring'-Praxis in PRINCE2 bezieht sich darauf, dass das PRINCE2-Framework an die spezifischen Anforderungen eines Projekts angepasst werden kann. Es geht darum, die PRINCE2-Methode entsprechend der Größe, Komplexität und Art des Projekts anzupassen, um effektiver und effizienter zu sein. Ein Beispiel für Tailoring könnte sein, dass bestimmte Prozesse oder Dokumentationen, die für dein Projekt nicht relevant oder notwendig sind, angepasst oder weggelassen werden können. So kann das PRINCE2-Framework maßgeschneidert werden, um den Anforderungen des Projekts gerecht zu werden und gleichzeitig eine solide Basis für das Projektmanagement zu bieten.

Ein stabiles Team ist ein Team, das über einen längeren Zeitraum hinweg unverändert bleibt. Das bedeutet, dass die Teammitglieder konstant bleiben und keine häufigen Wechsel oder Rotationen stattfinden. Ein stabiles Team hat einige Vorteile:

1. Vertrauen und Zusammenarbeit: Da sich die Teammitglieder gut kennen und schon längere Zeit miteinander gearbeitet haben, entwickeln sie ein starkes Vertrauen zueinander. Dadurch können sie effektiv zusammenarbeiten und sich aufeinander verlassen.

2. Effizienz: Ein stabiles Team profitiert von der eingespielten Zusammenarbeit. Die Teammitglieder kennen die Stärken und Schwächen der anderen und können so effizienter arbeiten. Es ist nicht notwendig, neue Teammitglieder kontinuierlich einzuarbeiten.

3. Kontinuität: Ein stabiles Team kann über einen längeren Zeitraum hinweg kontinuierlich an Projekten arbeiten. kann es eine langfristige Sichtweise entwickeln, um Ziele zu erreichen und stetige Verbesserungen vorzunehmen. Allerdings gibt es auch einige Herausforderungen bei der Aufrechterhaltung eines stabilen Teams, wie z.B. die Motivation der Teammitglieder langfristig aufrechtzuerhalten oder die Vermeidung einer zu starken Abhängigkeit von einzelnen Teammitgliedern.

Dieses Dokument gibt einen Überblick über das Projekt, einschließlich der Ziele, des Umfangs und der Stakeholder. Es hilft dabei, ein gemeinsames Verständnis für das Projekt zu schaffen und dient als Ausgangspunkt für die Planung.

Defintion des Endprodukts des Projekts.

Das Element "Aufbau" beschreibt beschreibt die Hauptprodukte/Produktgruppen und damit den Umfang des Projekts. Die Hauptprodukte können als Epics bezeichnet werden. Evtl. n grobe UserStorys auf mittlerer Ebene.
Agile Fehlschätzungen des Aufwands darf hier noch bei 50-100% liegen.

In der Produktbeschreibung wird jedes zu liefernde Produkt beschrieben, einschließlich seiner Merkmale, Funktionen und Qualitätskriterien. Dies dient als Referenz für die Entwicklung und Überprüfung der Produkte im Laufe des Projekts.

Aufgenommene Anforderungen sind Epics hoher Ebene (bis zu 10? L5S6), grob formulierte UserStorys, oder Steine mittlerer Ebene .

Grober Überblick über die Hauptprodukte des Projekts mit Lieferterminen, Kosten, Ressourcenbedarf und Abhängigkeiten. 

• Erstellung Projektplan durch Team
• Erste Version ist Teil der Projektleitdokumentation.
• Aktualisierung während des Projekts mit aktuellen Ist-Daten, um sicherzustellen, dass das Projekt auf Kurs bleibt.
• Format i.d.R. Gantt-Diagramm oder Produkt-Backlog

Wichtigstes Dokument für den Lenkungsaussschuss, zur Überprüfung von Soll und Ist (ursprüngliche Erwartungen und aktueller Projektstatus)

Teilmenge des Product Backlog.

Im agilen Kontext enthält der Sprint Backlog eine Liste der Features, die in einem Sprint entwickelt werden sollen. Es dient als Leitfaden für das Entwicklungsteam während des Sprints. 

Das Produktinkrement ist das Ergebnis eines Sprints und stellt eine potenziell shippbare Version des Produkts dar. Es wird nach jedem Sprint erstellt und kann dem Kunden präsentiert werden.

Der Fortschrittsbericht gibt einen Überblick über den aktuellen Stand des Projekts, einschließlich des erzielten Fortschritts, der verbleibenden Arbeiten und eventueller Risiken oder Probleme. Er ermöglicht es dem Projektmanager und den Stakeholdern, den Projektfortschritt zu überwachen.

1. Einen Prozess des kontinuierlichen Lernens etablieren: Hierbei geht es darum, Erfahrungen aus vergangenen Projekten zu dokumentieren und zu analysieren, um daraus zu lernen und das Wissen in zukünftigen Projekten anzuwenden.

2. Lernen von Erfahrung anderer: Es ist wichtig, dass nicht nur die eigenen Projekterfahrungen genutzt werden, sondern auch auf das Wissen und die Erfahrungen anderer in der Organisation oder der Branche zurückgegriffen wird. Dies kann zum Beispiel durch das Studium von Lessons-Learned-Berichten oder den Austausch mit anderen Projektteams erfolgen.

3. Empirische Entscheidungsfindung: Projekte basieren oft auf Unsicherheit und Komplexität. Das 'Learn from Experience'-Prinzip legt nahe, dass Entscheidungen auf Basis von Fakten und Erfahrungen getroffen werden sollten, anstatt nur auf Vermutungen oder Intuition.

4. Vermeiden von Wiederholungsfehlern: Durch das Lernen aus Erfahrungen können wiederholte Fehler in zukünftigen Projekten vermieden werden. Es ist wichtig, dass diese Erfahrungen dokumentiert und in den Projektmanagementprozessen berücksichtigt werden. Die 'Learn from Experience'-Prinzipien in PRINCE2 helfen dabei, die Qualität von Projekten zu verbessern und sicherzustellen, dass wertvolles Wissen und Erfahrungen genutzt werden, um zukünftige Projekte erfolgreicher zu gestalten.

• Viele bewegliche Teile
• Hohe Komplexität
• Unklarheiten
• Risiken

Weil:

• Temporär
• Team wird gebildet
• Schwierig
• Ein Maß an Unsicherheit

• Geringes Risiko
• Geringe Komplexität
• Prozesse sind vorhanden

Weil:

• Fortlaufend
• Stabiles Team bereits etabliertes Team
• Routine
• Ein Maß an Sicherheit

Beschreibt, wie Prince2 ( "PRojects IN Controlled Environments 2") so konfiguriert und angepasst werden kann, dass es möglichst effektiv mit

• agilen Werten
• Konzepten
• Frameworks und Techniken

kombiniert werden kann.

In der Initiierungsphase ist Grundlagen für das gesamte Projekt und einen erfolgreichen Start. z.B. Bewertung der Auswirkung regelmäßiger Releases auf das Qualitätsmanagement.

Definiere:

• Ziele des Projekts
• Umfang 
• Rahmenbedingungen

Typischen Aufgaben in dieser Phase:

1. Projektidee definieren: In dieser Phase wird die Idee für das Projekt entwickelt und die grundlegenden Anforderungen festgelegt.
    
2. Projektauftrag erstellen: Der Projektauftrag beinhaltet eine Beschreibung des Projekts, die Ziele, den Umfang, das Budget und die Ressourcen.
    
3. Stakeholder identifizieren: Es werden die wichtigen Personen oder Gruppen identifiziert, die vom Projekt betroffen sind oder Einfluss auf das Projekt haben könnten.
    
4. Projektteam zusammenstellen: Das Projektteam wird zusammengestellt, indem die richtigen Personen mit den passenden Fähigkeiten ausgewählt werden.
    
5. Risikoanalyse durchführen: Eine Risikoanalyse wird durchgeführt, um potenzielle Risiken und Probleme im Projekt zu identifizieren und entsprechende Maßnahmen zu ergreifen.
    
6. Projektplan erstellen: Ein vorläufiger Projektplan wird erstellt, der die zu erreichenden Meilensteine und die geplanten Aktivitäten enthält.
    
7. Projektauftrag genehmigen: Nach Abschluss der Initiierungsphase wird der Projektauftrag von den relevanten Stakeholdern genehmigt, um das Projekt offiziell zu starten.

• Product Backlog
• Coach und Moderator
• Fördert die Zusammenarbeit mit den Stakeholdern
• Hilft den Entwicklungsprozess zu optimieren
• Team bei der Erfüllung der Sprint-Ziele unterstützen - Leading Servant: beseitigt Hindernisse, optimiert Leistung
• Sorgt für Einhaltung der Scrum-Prinzipien
• i.d.R. keine Vollzeitrolle
• kann sogar Developer aus dem Team sein
• Hat Wissen über den Geschäftsbereich
• technische Sachkenntnis ausreichend
• Person kann sich auch von Sprint zu Sprint ändern
• Ziel erfolgreiches Team und unternehmensweite Unterstützung von Scrum

Der Customer SME könnte auch er sein.

Aufgaben

• Priorisiert Product Backlog (nur er)
• Verfeinerung von Einträgen höherer Prio kurz vor Ende des Sprints
• Sicher stellen das genug Arbeit im Team vorhanden ist
• Sicher stellen das pBacklog transparent, sichtbar und verstanden ist
• Stellt angemessene Akzeptanzkriterien sicher
• Verantwortlich für Produktziel und Product Backlog
• Muss am Sprint Planning beteiligt sein
• Bedürfnisse der Kunden und des Unternehmens im Blick behalten
• Entscheidung über Kosten Risiken Rahmenbedinungen
• Ziel Investitionsertrag und Wert

Fokus auf unterschiedliche Ziele: 
Unterschiedliche Ziele können zu Interessenskonflikten führen.

Objektivität:
Die Rollen des Scrum Masters und des Product Owners erfordern eine gewisse Objektivität. Es ist wichtig, dass beide Rollen unabhängig voneinander agieren können, um den Projekterfolg optimal zu unterstützen.

Priorisierung:
Wäre eine Person sowohl Scrum Master als auch Product Owner, könnten Konflikte bei der Priorisierung auftreten.

Der Unterschied zwischen Projektlenkung und Projektmanagement liegt in den Aufgaben und Verantwortlichkeiten. Kurz zusammengefasst: Das Projektmanagement widmet sich den operativen Aspekten des Projekts, während die Projektlenkung die strategische Ausrichtung und Entscheidungsfindung umfasst. Beide Bereiche sind für den Erfolg eines Projekts von großer Bedeutung und arbeiten eng zusammen.

Der Projektmanager (Ausführung durch  Projektleiter oder Projektmanager) setzt sich für einen erfolgreichen Projektabschluss ein (operativ). Er ist für diese Prozesse verantwortlich:

• Planung, Organisation
• Durchführung
• Überwachung

mittels

• Definition von Zielen
• Erstellung eines Projektzeitplans
• Ressourcenverwaltung
• Risikobewertung
• Kommunikation mit Stakeholdern.

Projektlenkung (Ausführung durch  Projektlenkungsausschuss oder Projektsteuerungsgremium), bezieht sich auf die strategische Ausrichtung und Entscheidungsfindung auf höherer Ebene. Es umfasst die

• Festlegung von Zielrichtungen
• Treffen von strategischen Entscheidungen
• Überwachen des Projektfortschritts
• Gewährleistung einer optimalen Zusammenarbeit aller beteiligten Personen und Teams.
• Die Projektlenkung stellt sicher, dass das Projekt auf dem richtigen Kurs bleibt und alle Beteiligten motiviert und engagiert sind.