Sample Exam (2): Practitioner 6. Edition von Andreas Ellenberger

video locked

Über den Vortrag

Der Vortrag „Sample Exam (2): Practitioner 6. Edition“ von Andreas Ellenberger ist Bestandteil des Kurses „PRINCE2® – Practitioner 6. Edition inkl. Prüfung“.


Quiz zum Vortrag

  1. Ja, denn der Auftraggeber sollte sicherstellen, dass sich die Investition rechnet („value for money“).
  2. Ja, weil das Projekt in mindestens zwei Managementphasen unterteilt werden sollte.
  3. Nein, weil der Leiter der Finanzabteilung die Arbeitspakete in einer Phase freigeben sollte.
  4. Nein, weil der Projektmanager befugt sein sollte, das Tagesgeschäft des Projekts zu managen.
  1. „Steuern nach dem Ausnahmeprinzip“, weil das Ausmaß an Steuerung durch den Projektmanager an die verfügbaren Toleranzen angepasst sein muss.
  2. „Steuern nach dem Ausnahmeprinzip“, weil Maßnahmen ergriffen werden müssen, damit die Produktionskosten die Verkaufszahlen des Albums nicht überschreiten.
  3. „Steuern über Managementphasen“, da die Kostentoleranz für jedes Arbeitspaket in einer Phase festgelegt werden sollte.
  4. „Steuern über Managementphasen“, da den Teammanagern die Befugnis erteilt werden sollte, bevor mit der Arbeit begonnen wird.
  1. Ja, weil durch die Definition dessen, was geliefert werden soll, Diskussionen während der Übergabe vermieden werden.
  2. Ja, weil das Cover ein Spezialistenprodukt ist und die Teammitglieder für seine Lieferung verantwortlich sind.
  3. Nein, da die Grafikdesignerin als externe Partei keinen Zugriff auf die Produktbeschreibung erhalten sollte.
  4. Nein, weil die Produktbeschreibung des Covers ein Managementprodukt und kein Spezialistenprodukt ist.
  1. Das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“, da die Rechtfertigung für Projekte während des Projektlebenszyklus regelmäßig überprüft werden sollte.
  2. Das Grundprinzip der „definierten Rollen und Verantwortlichkeiten“, weil an bereichsübergreifenden Projekten Personen unterschiedlicher Abteilungen beteiligt sind.
  3. Das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“, weil durch die Verknüpfung von Projekten mit Unternehmenszielen sichergestellt wird, dass der Nutzen auf die Strategie abgestimmt ist.
  4. Das Grundprinzip der „definierten Rollen und Verantwortlichkeiten“, weil eine Struktur des Projektmanagement-Teams eine effektive Kommunikation zwischen den Teammitgliedern ermöglicht.
  1. Ja, da während eines Projekts aus Erfahrungen gelernt und dieses neue Wissen angewendet werden sollte.
  2. Ja, weil eine objektive Prüfung Teil einer Qualitätinspektion sein sollte.
  3. Nein, da am Anfang eines Projekts aus Erfahrungen gelernt werden sollte.
  4. Nein, weil Erfahrungen erst am Ende eines Projekts weitergegeben werden.
  1. Ja, denn die Bereichsleiterin sollte in der Lage sein, sowohl die Interessen des Unternehmens als auch des Lieferanten zu vertreten.
  2. Ja, weil die Bereichsleiterin dafür verantwortlich ist, die erwarteten Verkaufszahlen des Albums zu erreichen.
  3. Nein, weil nur ein Lieferantenvertreter die Lieferanteninteressen im Lenkungsausschuss vertreten sollte.
  4. Nein, weil die Rolle des Auftraggebers nicht geteilt werden kann und diese Person daher nicht auch noch als Lieferantenvertreter fungieren kann.
  1. Ja, da der Projektmanager aus Erfahrungen lernt, die er in früheren Projekten gemacht hat
  2. Ja, weil der Projektmanager die geschäftliche Rechtfertigung durch Kostensenkungen optimiert.
  3. Nein, da die Projektmanagement-Ansätze seines vorherigen Arbeitgebers wahrscheinlich nicht die Anforderungen des aktuellen Projekts erfüllen.
  4. Nein, weil es bei diesem Projekt um Spezialistenprodukte und nicht um Projektmanagement-Ansätze gehen sollte.
  1. Das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“, da die Befugnisse der Änderungsinstanz beschränkt werden.
  2. Das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“, da so Gelder in sinnvolle Ziele investiert werden können.
  3. Das Grundprinzip „Produktorientierung“, da so sichergestellt wird, dass bei der Arbeit an dem Album das Budget eingehalten wird.
  4. Das Grundprinzip „Produktorientierung“, da sichergestellt werden sollte, dass das Album die Erwartungen erfüllt.
  1. Grund
  2. Optionen
  3. Erwarteter Nutzen
  4. Erwartete negative Nebeneffekte
  5. Zeitrahmen
  1. Grund
  2. Optionen
  3. Erwarteter Nutzen
  4. Erwartete negative Nebeneffekte
  5. Hauptrisiken
  1. Grund
  2. Optionen
  3. Erwarteter Nutzen
  4. Erwartete negative Nebeneffekte
  5. Hauptrisiken
  1. Ja, denn die Bereichsleiterin sollte kontrollieren, ob der Albumumsatz hoch genug ist.
  2. Ja, weil die Unternehmenssicherung die Risiken und ihre Auswirkungen auf den Business Case prüft.
  3. Nein, weil letztendlich der Auftraggeber für den Erfolg des Projekts verantwortlich ist.
  4. Nein, weil der Marketingmanager für etwaige Umsatzrisiken verantwortlich sein sollte.
  1. Ja, weil die Bereichsleiterin die Finanzierung des Projekts gewährleistet und während der Dauer des Projekts für den Business Case verantwortlich ist.
  2. Ja, weil die Bereichsleiterin für die Bewertung der Ergebnisse des Projekts im Vergleich zum erwarteten Nutzen im Business Case verantwortlich ist.
  3. Nein, weil der Projektmanager für die Erstellung des Projektabschlussberichts zur Bewertung der Projektleistung und -ergebnisse verantwortlich ist.
  4. Nein, weil der Projektmanager anhand externer Ereignisse und des Projektfortschritts überprüft, ob das Projekt gerechtfertigt war.
  1. Geschäftsführer
  2. Bereichsleiterin
  3. Vertragsmanager
  4. Marketingleiter
  5. Sänger
  1. Geschäftsführer
  2. Bereichsleiterin
  3. Vertragsmanager
  4. Marketingleiter
  5. Agent des Sängers
  1. Geschäftsführer
  2. Bereichsleiterin
  3. Vertragsmanager
  4. Marketingleiter
  5. Agent des Sängers
  1. Die Projekt- und Programmmanagement-Rollen sollten aufeinander abgestimmt werden, um eine klare Zuordnung der Befugnisse von oben nach unten sicherzustellen.
  2. Die Projekt- und Programmmanagement-Rollen sollten integriert werden, um die fortlaufende geschäftliche Rechtfertigung für das Projekt sicherzustellen.
  3. Es sollten weitere Projektrollen definiert werden, um sicherzustellen, dass die Rollen und Verantwortlichkeiten des Programms den Teamrollen korrekt zugeordnet sind.
  4. Es sollten weitere Projektrollen definiert werden, um sicherzustellen, dass die Unternehmensrolle die allgemeine Kundensicht auf Lieferebene vertritt.
  1. Es wird gut angewendet, da Stakeholder außerhalb der Kundenorganisation einen erheblichen Einfluss auf den Erfolg des Projekts ausüben können.
  2. Es wird gut angewendet, weil der Marketingmanager über den Fortschritt der Phase informiert sein sollte und Berichte von den Zielgruppen erhält.
  3. Es wird schlecht angewendet, weil Stakeholder die Gruppen oder Einzelpersonen sind, die von den Projekt-Outputs betroffen sind, z. B. Lieferkanäle.
  4. Es wird schlecht angewendet, weil die Zielgruppen im Kommunikationsmanagement-Ansatz als Stakeholder einbezogen werden sollten und nicht der Marketingmanager.
  1. Auftraggeber
  2. Benutzervertreter
  3. Projektmanager
  4. Teammanager
  5. Projektsicherung
  1. Auftraggeber
  2. Benutzervertreter
  3. Projektmanager
  4. Teammanager
  5. Projektsicherung
  1. Auftraggeber
  2. Benutzervertreter
  3. Projektmanager
  4. Teammanager
  5. Projektsicherung
  1. Ja, denn der Projektmanager sollte sicherstellen, dass die Qualitätssteuerung für den Plan für die Einführungsveranstaltung die festgelegten Qualitätskriterien erfüllt.
  2. Ja, denn der Projektmanager sollte sicherstellen, dass die Produktbeschreibungen bei der Planung der nächsten Phase aktualisiert werden.
  3. Nein, denn der Benutzervertreter sollte die Kundenqualitätserwartungen und Projektabnahmekriterien für das Projekt bestätigen.
  4. Nein, denn der Benutzervertreter sollte Ressourcen für das Prüfen und Abnehmen des Plans für die Einführungsveranstaltung gemäß den festgelegten Qualitätskriterien bereitstellen.
  1. Ja, denn der Kunde sollte sein Recht auf Überprüfungen sowie die Erwartungen an die Qualität eines Produkts definieren.
  2. Ja, denn der Lieferantenvertreter sollte die Qualitätsprüfmethoden genehmigen, die verwendet werden, um die Qualität der aufgenommenen Songs zu prüfen.
  3. Nein, denn der Teammanager sollte sicherstellen, dass die aufgenommenen Titel die Qualitätskriterien erfüllen, die in der Produktbeschreibung festgelegt sind.
  4. Nein, denn es sollte zwischen dem Kunden und dem Lieferanten Einigkeit über das erforderliche Qualitätsniveau bestehen.
  1. Planvoraussetzungen
  2. Externe Abhängigkeiten
  3. Einbezogene Erfahrungen
  4. Überwachung und Steuerung
  5. Budgets
  1. Planvoraussetzungen
  2. Externe Abhängigkeiten
  3. Einbezogene Erfahrungen
  4. Überwachung und Steuerung
  5. Budgets
  1. Planvoraussetzungen
  2. Externe Abhängigkeiten
  3. Einbezogene Erfahrungen
  4. Überwachung und Steuerung
  5. Budgets
  1. Ja, weil der Lenkungsausschuss den Projektplan und die Rechtfertigung des Projekts als Grundlage für Entscheidungen über zukünftige Änderungen nutzt.
  2. Ja, weil der Lenkungsausschuss den Projektplan und die Rechtfertigung des Projekts als Grundlage für die Entscheidung über diese Änderung genutzt hat.
  3. Nein, weil der Projektplan als Baseline für die Überwachung des Projektfortschritts durch den Lenkungsausschuss genutzt wird.
  4. Nein, weil die Verwendung des Änderungsbudgets für die Änderung keine Auswirkungen auf das Projektkostenbudget hat.
  1. Eine Hierarchie von Produkten für das 'Album fertig zur Veröffentlichung' erstellen, da Informationen über die wichtigsten Produkte und ihre Bestandteile benötigt werden.
  2. Eine Hierarchie von Produkten für das 'Album fertig zur Veröffentlichung' erstellen, da die Abhängigkeiten zwischen den Bestandteilen erkennbar sein müssen.
  3. Die Produktabhängigkeiten zwischen dem „aufgenommenen Album“ und dem „Cover-Design“ ermitteln, weil diese als Grundlage für Entscheidungen über Maßnahmen und Ressourcen dienen.
  4. Die Produktabhängigkeiten zwischen dem „aufgenommenen Album“ und dem „Cover-Design“ ermitteln, weil dies notwendig ist, um ihre genauere Beschaffenheit zu herauszuarbeiten.
  1. Risiken identifizieren
  2. Risiken bewerten
  3. Gegenmaßnahme planen
  4. Maßnahme umsetzen
  5. Maßnahme aus dem Risikobudget finanzieren
  1. Risiken identifizieren
  2. Risiken bewerten
  3. Gegenmaßnahme planen
  4. Maßnahme umsetzen
  5. Risiko kommunizieren
  1. Risiken identifizieren
  2. Risiken bewerten
  3. Gegenmaßnahme planen
  4. Maßnahme umsetzen
  5. Maßnahme aus dem Risikobudget finanzieren
  1. Es wird schlecht identifiziert, weil die Auswirkungen des Risikos nicht klar sind und daher keine geeigneten Risikomaßnahmen ergriffen werden können.
  2. Es wird gut identifiziert, weil die Auswirkungen des Risikos auf das Projekt und seine Durchführbarkeit klar sind.
  3. Es wird schlecht identifiziert, weil die Risikoquelle nicht klar ist und daher keine geeigneten Risikomaßnahmen ergriffen werden können.
  4. Es wird gut identifiziert, weil Risiken während eines Projekts laufend ermittelt und im Risikoregister festgehalten werden sollten.
  1. Erfassen von Issues
  2. Bewerten von Issues
  3. Vorschlagen von Korrekturmaßnahmen
  4. Entscheidung über Korrekturmaßnahmen
  5. Implementieren von Korrekturmaßnahmen
  1. Erfassen von Issues
  2. Bewerten von Issues
  3. Vorschlagen von Korrekturmaßnahmen
  4. Entscheidung über Korrekturmaßnahmen
  5. Implementieren von Korrekturmaßnahmen
  1. Erfassen von Issues
  2. Bewerten von Issues
  3. Vorschlagen von Korrekturmaßnahmen
  4. Entscheidung über Korrekturmaßnahmen
  5. Implementieren von Korrekturmaßnahmen
  1. Als Spezifikationsabweichung, weil ein Vorschlag zur Änderung der Vergleichswerte (Baseline) eingegangen ist.
  2. Als Änderungsantrag, weil die Aufnahme eine höhere Qualität hat.
  3. Als Spezifikationsabweichung, weil die Aufnahme der Lieder nicht den angegebenen Kriterien entspricht.
  4. Als Änderungsantrag, weil die Produktbeschreibung aktualisiert werden muss.
  1. Ja, weil die Produktbeschreibung aktualisiert werden sollte, um die geänderten Qualitätskriterien wiederzugeben.
  2. Ja, weil eine Produktbeschreibung aktualisiert werden sollte, um den Status eines gelieferten Produkts zeigen.
  3. Nein, weil Produktbeschreibungen Baseline-Dokumente sind, die nicht geändert werden sollten.
  4. Nein, weil die Projektunterstützung Produktbeschreibungen nach einer Konzession aktualisieren sollte.
  1. Teammanager
  2. Benutzervertreter
  3. Projektsicherung
  4. Auftraggeber
  5. Projektunterstützung
  1. Teammanager
  2. Benutzervertreter
  3. Projektsicherung
  4. Auftraggeber
  5. Projektunterstützung
  1. Teammanager
  2. Benutzervertreter
  3. Projektsicherung
  4. Auftraggeber
  5. Projektunterstützung
  1. Wöchentliche Teamstatusberichte anfordern, um Ausnahmen auf Arbeitspaketebene zu vermeiden.
  2. Wöchentliche Teamstatusberichte anfordern, um die Kontrolle über dieses Arbeitspaket zu erhöhen.
  3. Die Toleranzen für das Arbeitspaket erhöhen, damit mehr Abweichungen zulässig sind und weniger Issues vorgebracht werden.
  4. Die Toleranzen für das Arbeitspaket erhöhen, sodass diese den Toleranzen der Phase entsprechen und die Berichte einheitlich sind.
  1. Ja, weil Chancen, die geschäftliche Rechtfertigung zu verbessern, vom Lenkungsausschuss in Betracht gezogen werden sollten.
  2. Ja, weil sich die Phase in einer Ausnahmesituation befinden würde und ein Ausnahmeplan erforderlich wäre.
  3. Nein, weil der Projektmanager die Empfehlung ablehnen sollte, da das Arbeitspaket innerhalb der Qualitätstoleranz abgeschlossen wurde.
  4. Nein, weil der Projektmanager Korrekturmaßnahmen ergreifen sollte, um die Qualität der aufgenommenen Titel zu verbessern.
  1. Auftraggeber und Projektmanager ernennen
  2. Vorhandene Erfahrungen erfassen
  3. Projektmanagement-Team entwerfen und ernennen
  4. Business Case-Entwurf erstellen
  5. Projektlösungsansatz auswählen und Projektbeschreibung zusammenstellen
  1. Auftraggeber und Projektmanager ernennen
  2. Vorhandene Erfahrungen erfassen
  3. Projektmanagement-Team entwerfen und ernennen
  4. Business Case-Entwurf erstellen
  5. Initiierungsphase planen
  1. Auftraggeber und Projektmanager ernennen
  2. Vorhandene Erfahrungen erfassen
  3. Projektmanagement-Team entwerfen und ernennen
  4. Business Case-Entwurf erstellen
  5. Projektlösungsansatz auswählen und Projektbeschreibung zusammenstellen
  1. Ja, weil das Risiko, dass ein anderes Unternehmen ein ähnliches Album produzieren könnte, im Projektlösungsansatz dokumentiert werden sollte.
  2. Ja, weil die Anforderung, das Projekt vertraulich zu behandeln, zur Entscheidung für den Projektlösungsansatz relevant ist.
  3. Nein, weil Erfahrungen im Hinblick auf die Kommunikation für die Entwicklung des Kommunikationsmanagement-Ansatzes relevant sind.
  4. Nein, weil Erfahrungen aus ähnlichen Projekten in der Erfahrungsliste erfasst werden sollten.
  1. Auftraggeber
  2. Benutzervertreter
  3. Lieferantenvertreter
  4. Projektsicherung
  5. Projektmanager
  1. Auftraggeber
  2. Benutzervertreter
  3. Lieferantenvertreter
  4. Projektsicherung
  5. Projektmanager
  1. Auftraggeber
  2. Benutzervertreter
  3. Lieferantenvertreter
  4. Projektsicherung
  5. Projektmanager
  1. Sie wird gut ausgeführt, weil die Mitglieder des Lenkungsausschusses persönlich die Projektleitdokumentation genehmigen sollten.
  2. Sie wird gut ausgeführt, da die Projektleitdokumentation vom Lenkungsausschuss in beliebiger Art und Weise freigegeben werden kann, solange die Entscheidung nachvollziehbar ist.
  3. Sie wird schlecht ausgeführt, da dank der Steuerung nach dem Ausnahmeprinzip persönliche Treffen nicht nötig sind.
  4. Sie wird schlecht ausgeführt, da der Lenkungsausschuss den Plan für die nächste Phase sowie die Projektleitdokumentation freigeben sollte.
  1. Anpassungsanforderungen festlegen
  2. Risikomanagement-Ansatz erstellen
  3. Änderungssteuerungsansatz erstellen
  4. Qualitätsmanagement-Ansatz erstellen
  5. Kommunikationsmanagement-Ansatz erstellen
  1. Anpassungsanforderungen festlegen
  2. Risikomanagement-Ansatz erstellen
  3. Änderungssteuerungsansatz erstellen
  4. Kommunikationsmanagement-Ansatz erstellen
  5. Projektplan erstellen
  1. Anpassungsanforderungen festlegen
  2. Risikomanagement-Ansatz erstellen
  3. Änderungssteuerungsansatz erstellen
  4. Qualitätsmanagement-Ansatz erstellen
  5. Projektplan erstellen
  1. Weil der Projektmanager den Risikomanagement-Ansatz während des Prozesses „Initiieren eines Projekts“ erstellen sollte.
  2. Weil im Risikomanagement-Ansatz definiert sein sollte, wie das Risikoregister gemanagt und verwaltet wird.
  3. Weil in einem einfachen Projekt der Risikomanagement-Ansatz mit der Risikomanagementstrategie des Programms kombiniert sein sollte.
  4. Weil das Programmbüro üblicherweise dabei hilft sicherzustellen, dass das Projekt den Programmstandards entspricht.
  1. Business Case
  2. Qualität
  3. Risiko
  4. Pläne
  5. Änderungen
  1. Business Case
  2. Qualität
  3. Risiko
  4. Änderungen
  5. Organisation
  1. Business Case
  2. Qualität
  3. Risiko
  4. Pläne
  5. Änderungen
  1. Ja, weil das Arbeitspaket des Tonstudios die Arbeiten für das „aufgenommene Album“ und das "aufgenommene Video" festlegen sollte.
  2. Ja, weil die Produktbeschreibung für das "aufgenommene Video" für die Rechtfertigung des Änderungsantrags nötig ist.
  3. Nein, weil der Projektmanager Produktbeschreibungen zusammen mit dem Phasenplan erstellen sollte.
  4. Nein, weil der Projektmanager den Phasenplan aktualisieren sollte, wenn er Korrekturmaßnahmen zur Durchführung der Änderung ergreift.
  1. Weil der Teamplan zeigen wird, ob das „Cover-Design“ innerhalb der Timebox des agilen Ansatzes fertiggestellt werden kann.
  2. Weil der Projektmanager einen Teamplan erstellen sollte, wenn er als Teammanager fungiert.
  3. Weil ein Teamplan für ein externes Arbeitspaket erforderlich ist.
  4. Weil ein Teamplan bei einem agilen Ansatz erforderlich ist.
  1. Projektsicherung
  2. Projektmanager
  3. Teammanager
  4. Auftraggeber
  1. Ja, weil die Teamstatusberichte auf die Anforderungen des Programmmanagers zugeschnitten sein sollten.
  2. Ja, weil Teamstatusberichte mit der Häufigkeit erstellt werden sollten, die im Arbeitspaket festgelegt ist.
  3. Nein, weil der Teammanager den Projektmanager informieren sollte, sobald das „Cover-Design“ fertig ist.
  4. Nein, weil es eine Schnittstelle zwischen den Prozessen „Managen der Produktlieferung“ und „Steuern einer Phase“ gibt.
  1. Phasenabschlussbericht erstellen
  2. Business Case anpassen
  3. Nutzenmanagement-Ansatz aktualisieren
  4. Projektplan anpassen
  1. Nächste Managementphase planen
  2. Vorzeitigen Abschluss vorbereiten
  3. Ausnahmeplan erstellen
  4. Projektplan erstellen
  1. Ja, da PRINCE2 flexibel ist, um unnötige Verzögerungen bei der Umsetzung von Entscheidungen zu vermeiden.
  2. Ja, weil der Austausch eines Lieferanten eine wichtige Entscheidung ist, die als Ausnahme behandelt werden sollte.
  3. Nein, weil nur ein Lieferantenvertreter die Interessen des Lieferanten im Lenkungsausschuss vertreten sollte.
  4. Nein, weil Rollenänderungen an Phasenübergängen stattfinden sollten, außer es gibt eine Ausnahme.
  1. Planmäßigen Abschluss vorbereiten
  2. Produkte übergeben
  3. Projekt bewerten
  4. Projektabschluss empfehlen
  1. Sich vergewissern, dass die Projektabnahme des 'Cover-Designs' durch das Marketingteam der Plattenfirma erfolgt ist.
  2. Herausfinden, wie viele Fehler gefunden wurden, nachdem das 'Cover-Design' die Qualitätsinspektion durchlaufen hat.
  3. Sich vergewissern, dass das Marketingteam über die nötigen Ressourcen verfügt, um das 'Album fertig zur Veröffentlichung' zu bewerben.
  4. Von der Projektunterstützung eine Produktstatusauskunft für das 'Album fertig zur Veröffentlichung' anfordern.
  1. Ja, da das Projekt erst abgeschlossen werden kann, wenn die Auswirkungen durch die Verkaufszahlen ermittelt wurden.
  2. Ja, weil durch diese Folgeaktion das Risiko im Risikoregister abgeschlossen werden kann.
  3. Nein, weil eine Folgeaktion einer einzelnen Person und nicht einer Abteilung empfohlen werden sollte.
  4. Nein, da der Nutzenmanagement-Ansatz Aktivitäten nach dem Projekt beinhalten sollte.

Dozent des Vortrages Sample Exam (2): Practitioner 6. Edition

 Andreas Ellenberger

Andreas Ellenberger

Andreas Ellenberger ist Berater, Coach und Trainer für nachhaltige Veränderungen. Er hilft Unternehmen bei der Etablierung von Projektmanagementstrukturen, die Mitarbeiter und Führungskräfte aus Überzeugung nutzen, um die Zukunft des Unternehmens zu gestalten. Denn erfolgreiche Projekte entstehen immer dann, wenn langfristige Ziele und die angemessene Einbindung der Projektbeteiligten im Vordergrund stehen. Dies beinhaltet auch die Offenheit zu Veränderung aufgrund von aktuellen Erfahrungen und Spielräume für jeden einzelnen, sich kreativ und innovativ einzubringen.

Nach seinem abgeschlossenen Studium der Betriebswirtschaftslehre hat er in 15 Jahren Praxiserfahrung in verschiedenen Rollen im Projektmanagement gesammelt. Als Berater, Projektleiter und im Projektmanagement-Office erlebte er Erfolgs- und Misserfolgsfaktoren für Projekte. Als Leiter einer IT-Abteilung im Großunternehmen und Leiter des Trainingsbereichs eines Beratungs- und Trainingsunternehmens sammelte er Führungserfahrung, die er ergänzt um seine Methodenkenntnis im Coaching und Training weitergibt.

Als akkreditierter Trainer für PRINCE2® und weitere international anerkannte Methoden im Projekt- und Portfoliomanagement gibt er seit Jahren sein Methodenwissen mit viel Bezug zur praktischen Umsetzung weiter. In seinen Präsenztrainings geht er konkret auf die Situation der Teilnehmer ein und erarbeitet gemeinsam Lösungsansätze für die eigene Praxis auf Basis der Theorie, um Nachhaltigkeit zu erreichen. Da ihm dies am Herzen liegt, steht er für Telefoncoachings und Prüfungen einzelner Unterlagen bzgl. der Anwendung gern zur Verfügung.


Kundenrezensionen

(1)
5,0 von 5 Sternen
5 Sterne
5
4 Sterne
0
3 Sterne
0
2 Sterne
0
1  Stern
0