IT Project Manager Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich starte mit einem klaren Scope, einer realistischen Planung und einem Risikoregister, das ich kontinuierlich pflege. Den Fortschritt verfolge ich über transparente Kennzahlen wie Burndown oder Earned Value und reagiere früh auf Abweichungen, statt sie zu verschleppen. Bei Scope-Änderungen nutze ich einen klaren Change-Prozess, um Auswirkungen auf Zeit und Budget sichtbar zu machen. In meinem letzten Projekt habe ich so trotz zweier größerer Änderungen den Liefertermin gehalten.

Musterantwort

Ich identifiziere zunächst alle Stakeholder und ordne sie nach Einfluss und Interesse, um meine Kommunikation gezielt auszurichten. Bei Konflikten mache ich Zielkonflikte explizit, etwa zwischen Zeit und Umfang, und führe eine faktenbasierte Priorisierung mit dem Auftraggeber herbei. Ich kommuniziere früh, ehrlich und regelmäßig, damit niemand von schlechten Nachrichten überrascht wird. So habe ich einmal zwei Abteilungen mit gegensätzlichen Anforderungen auf einen gemeinsamen MVP geeinigt.

Musterantwort

Ich verschaffe mir zuerst ein ungeschöntes Lagebild zu Fortschritt, Risiken und Ursachen, statt vorschnell zu reagieren. Dann entwickle ich Optionen, etwa Scope-Reduktion, zusätzliche Ressourcen oder Terminanpassung, mit klaren Konsequenzen für die Entscheider. Ich kommuniziere die Lage transparent ans Management und treffe gemeinsam eine Entscheidung. Wichtig ist mir, das Team nicht in Schuldzuweisungen, sondern in Lösungen zu führen.

Musterantwort

Ich richte die Methode an der Projektnatur aus: Bei unklaren, sich wandelnden Anforderungen wähle ich ein agiles, iteratives Vorgehen, bei stabilen, regulatorisch fixierten Anforderungen eher ein klassisches Phasenmodell. Oft kombiniere ich beides hybrid, etwa eine agile Umsetzung innerhalb fester Meilensteine. Entscheidend sind Unsicherheit, Stakeholder-Erwartungen und Compliance. So vermeide ich, eine Methode dogmatisch über das Projekt zu stülpen.

Musterantwort

Mich reizt, dass Sie komplexe, abteilungsübergreifende IT-Programme verantworten, bei denen gutes Stakeholder-Management entscheidend ist. Ihre Ausschreibung erwähnt eine große Systemmigration, ein Umfeld, in dem ich meine Erfahrung mit Risiko- und Change-Management einbringen kann. Ich liefere gern Projekte, die einen sichtbaren geschäftlichen Unterschied machen. Außerdem passt Ihr hybrider Methodenansatz gut zu meiner Arbeitsweise.

Das magische Dreieck verbindet Umfang, Zeit und Kosten, oft ergänzt um Qualität in der Mitte. Ändert sich eine Größe, wirkt sich das auf mindestens eine andere aus, etwa mehr Umfang bei gleichem Budget verlängert die Zeit. Aufgabe des Projektmanagers ist es, diese Größen bewusst auszubalancieren und Zielkonflikte transparent zu machen.

Der kritische Pfad ist die längste Kette voneinander abhängiger Aufgaben und bestimmt die kürzestmögliche Projektdauer. Verzögert sich eine Aufgabe auf diesem Pfad, verschiebt sich das Projektende direkt. Aufgaben außerhalb haben Puffer, weshalb der Projektmanager den kritischen Pfad besonders eng überwacht.

Ich identifiziere Risiken systematisch, bewerte sie nach Eintrittswahrscheinlichkeit und Auswirkung und priorisiere sie in einem Risikoregister. Für die wichtigsten Risiken definiere ich Vermeidungs-, Minderungs- oder Notfallmaßnahmen und einen Verantwortlichen. Das Register überprüfe ich regelmäßig, da sich Risiken im Projektverlauf verändern.

Earned Value Management misst den Projektfortschritt, indem es geplanten Wert, tatsächliche Kosten und den erbrachten Wert vergleicht. Kennzahlen wie der Cost Performance Index und der Schedule Performance Index zeigen, ob das Projekt im Budget und im Zeitplan liegt. So lassen sich Abweichungen früh erkennen und Prognosen zum Projektende erstellen.

Ein Meilenstein ist ein bedeutsamer Zeitpunkt im Projekt ohne eigene Dauer, etwa der Abschluss einer Phase oder eine Freigabe. Ein Liefergegenstand ist ein konkretes, überprüfbares Ergebnis, etwa eine fertige Spezifikation oder ein abgenommenes Modul. Meilensteine markieren Fortschritt, Liefergegenstände belegen ihn inhaltlich.

Ein Integrationsprojekt lag durch unklare Anforderungen vier Wochen im Verzug (Situation). Ich übernahm die Leitung und sollte die Lieferung sichern (Task). Ich habe den Scope mit den Stakeholdern auf einen tragfähigen MVP fokussiert, Abhängigkeiten neu geplant und tägliche kurze Steuerungsrunden eingeführt (Action). Das Projekt lieferte den Kernumfang nur eine Woche nach dem ursprünglichen Termin und stabilisierte das Vertrauen der Stakeholder (Result).

Ein gewünschtes Feature hätte den Liefertermin ernsthaft gefährdet (Situation). Ich musste entscheiden, es zu verschieben, obwohl ein einflussreicher Stakeholder es forderte (Task). Ich habe die Auswirkungen mit Daten belegt, Alternativen aufgezeigt und die Verschiebung in einen Folgerelease transparent begründet (Action). Der Termin wurde gehalten, und der Stakeholder akzeptierte die nachvollziehbare Priorisierung (Result).

Ein Entwickler verfehlte wiederholt Zusagen und gefährdete den Plan (Situation). Ich sollte die Leistung verbessern, ohne das Teamklima zu beschädigen (Task). Ich habe in einem offenen Gespräch die Ursachen erkundet, eine Überlastung durch Parallelaufgaben erkannt und mit der Linienführung eine Entlastung organisiert (Action). Die Zusagen wurden danach wieder eingehalten und das Vertrauen im Team blieb intakt (Result).

Mitten im Projekt forderte der Auftraggeber zusätzliche regulatorische Anforderungen (Situation). Ich sollte diese integrieren, ohne das Projekt unkontrolliert wachsen zu lassen (Task). Ich habe einen formalen Change Request mit Auswirkungen auf Zeit, Kosten und Risiko erstellt und ihn im Steuerungsgremium entscheiden lassen (Action). Der Umfang wurde bewusst und budgetiert erweitert, und das Projekt blieb planbar (Result).