Projektlinien ausmalen (mit Maik Stettner von EA Games)

Lesen Sie das Transkript:

Wir probieren aus, unsere Podcasts mit Hilfe eines Software-Programms zu transkribieren. Bitte entschuldigen Sie etwaige Tippfehler, der Bot ist nicht immer zu 100 % korrekt.

Ben Aston

Willkommen beim DPM-Podcast, wo wir über die Theorie hinausgehen und Expertenrat für besseres digitales Projektmanagement geben. Danke, dass Sie dabei sind. Ich bin Ben Aston, der Gründer von The Digital Project Manager. Seien wir mal ehrlich: Sind Sie bereit, Ihre Projekte im Budget abzuliefern? Und im Zeitplan? Sind Sie bereit, auch den versprochenen Leistungsumfang zu liefern? Sind Sie nicht sicher? Wie wissen Sie das und wie machen Sie das? Genau darum geht es in der heutigen Podcast-Folge: Projektkontrollen.

Sie sind im Grunde lediglich die Linien, die wir um unsere Projekte ziehen, um die Parameter des Projekts festzulegen. Um zu wissen, wo wir „ausmalen“ sollen. Und zu erkennen, wenn wir mit unserem Projekt außerhalb dieser Linien geraten.

Diese Folge wird gesponsert von Resource Guru, dem Ressourcenplanungs-Tool, das von Teams in Unternehmen wie Apple, Ogilvy, Deloitte und Publicis eingesetzt wird. DPM-Hörer erhalten 20 % Rabatt auf die gesamte Laufzeit ihres Kontos mit dem Gutscheincode DPM2018.

Erfahren Sie mehr bei Resource Guru

Heute spreche ich mit Maik Stettner. Maik ist frisch ernannter Development Director bei EA Games, zuvor bei FCV, wo er das Team leitete. Er ist zudem einer unserer Resident-Experten für digitales Projektmanagement an der Digital Project Manager School. Und wenn man ein Team von Projektmanagern führt, wird man für Projektkontrollen sehr leidenschaftlich. Und Maik hat darin viel Erfahrung. Sie möchten wirklich, dass Ihr Team im Rahmen des Budgets liefert. Sie möchten, dass Ihr Team Zeitpläne und Meilensteine einhält – denn sonst fangen die Dinge an auseinanderzufallen und Sie müssen eingreifen. Heute besprechen wir, wie wir unsere Projekte besser steuern und welche Kontrollen wir implementieren können. Erstens, damit wir wissen, dass wir auf Kurs sind. Und zweitens, um Optionen zu haben, wenn wir vom Kurs abkommen.

Ich hoffe, das klingt interessant. Maik, hallo und herzlich willkommen in der Sendung.

Maik Stettner:

Hallo Ben. Danke für die Einladung.

Ben Aston:

Schön, dass du wieder da bist. Maik, erzähl uns ein bisschen ... Du wechselst gerade die Rolle, vom Teamleiter für Projektmanager bei FCV zum Development Director bei EA Games. Weißt du schon, was das genau bedeutet?

Maik Stettner:

Das werde ich sehr bald herausfinden. Der Fokus liegt weiterhin auf Projektmanagement. Also: Nach dem Wechsel von einer Agentur zu Electronic Arts tauche ich nun wieder in die Games-Branche ein. Ich habe auch früher schon in unterschiedlichen Branchen gearbeitet, also ist das für mich nicht ganz neu. Ich freue mich auf die Rückkehr. Aus Sicht des Projektmanagements ist das ziemlich komplex, also herausfordernd und dynamisch, und wahrscheinlich werde ich Projektkontrollen auch dort weiterverwenden.

Ben Aston:

Super. Und hast du ... Wenn du an den Wechsel in eine neue Rolle und neue Tools und Arbeitsweisen denkst – gibt es irgendetwas, das du kürzlich entdeckt oder genutzt hast, von dem du sagst: „Das will ich definitiv in die neue Position mitnehmen“? Neue Tools oder Ansätze, die du genutzt hast?

Maik Stettner:

Ich habe in jeder meiner Positionen stets neue Herangehensweisen und Blickwinkel auf Problemlösungen gelernt. Insbesondere in der Software- oder digitalen Projektsteuerung begegnet man oft ähnlichen Herausforderungen, aber es gibt alternative Lösungsansätze. Das können Tools sein, wie Issue-Tracking-Tools, die immer besser werden, oder Tools, die die nötigen Analysen liefern, um spontane Entscheidungen treffen zu können. Ich kann kein wirklich neues Tool nennen – abgesehen von den üblichen Verdächtigen. Aber interessant ist für mich, dass die meisten Probleme sich ähneln – egal, ob man eine App, Desktop-Software, Website oder ein Spiel baut. Die Herausforderungen und Probleme sind vergleichbar, ebenso wie die Lösungswege.

Ben Aston:

Ja, ich finde es interessant, seitdem ich als Freelancer tätig bin, dass selbst wenn ... Man meint, man kennt die Arbeitsweise, z. B. fürs Ressourcenmanagement nutzt man ein Tool wie Resource Guru, oder es gibt andere Tools wie Harvest mit Forecast. Man denkt, man weiß wie alles laufen sollte. Aber dann verwendet man ein neues Tool oder nutzt ein Tool so, wie eine neue Agentur es nutzt – und merkt, es ist ein völlig anderes Terrain. Dasselbe Tool kann ganz unterschiedlich eingesetzt werden, das macht’s manchmal knifflig.

Aber was du sagst in Bezug auf Daten und Analysen ist so wichtig. Und das führt zum Artikel, denn was du zum Thema Projektkontrolle geschrieben hast. Wenn wir ein Team von Projektmanager:innen leiten oder selbst Projekte führen, wollen wir uns nicht nur auf unser Bauchgefühl verlassen, sondern auch auf Daten. Daten sind entscheidend, oder?

Maik Stettner:

Ja, absolut. Gerade als Teamleiter für Projektmanager habe ich nicht immer die volle Übersicht über die Details auf Projektebene. Deshalb verlasse ich mich oft auf Datenpunkte, um z. B. zu sehen, wie das Budget aussieht, wie hoch die Burn Rate ist usw. Das ermöglicht mir, gemeinsam mit Projektmanagern oder dem Team die richtigen Entscheidungen zu treffen.

Ben Aston:

Genau, diese Daten sind also unsere Projektkontrollen, richtig? Wenn wir an Programmmanagement denken, an das Managen eines PM-Teams, das sind die Daten, auf die wir schauen. Und das sind die Artefakte, die die PMs unseres Teams erstellen. Erzähl uns mehr: Wie definierst du Projektkontrollen? Womit verbindest du diesen Begriff?

Maik Stettner:

Das ist ein etwas einschüchternder Begriff. Für mich beschreibt „Projektkontrolle“ jedoch alle Werkzeuge, die nötig sind, um die richtigen Informationen zu erhalten, sodass man fundierte Entscheidungen treffen kann. Das umfasst alle Datenpunkte, die man sammeln kann, z. B. zu Kosten, Zeit, Umfang usw. Natürlich hängt das eng mit Kundeninteraktionen und allen dynamischen Entscheidungen im Projekt zusammen – z. B. reicht das Team? Braucht man Verstärkung? Liegen wir im Zeitplan, im Budget? Es ist ein Rahmenwerk für das Projektmanagement und um informierte Entscheidungen treffen zu können.

Ben Aston:

Welche Dokumente sind am nützlichsten dafür? Es gibt ja eine Vielzahl an Dokumentation. Wenn wir auf das Wesentliche reduzieren, was findest du als PM besonders hilfreich – und ebenso als Programmmanager oder Director, der Teams steuert?

Maik Stettner:

Das wichtigste Standardwerkzeug, das ich jedem empfehle, ist der ehrliche Statusbericht. Ein Bericht, der alle relevanten Kennzahlen des laufenden Projekts enthält: die gesamten Projektkosten, verbleibendes Budget, Burn Rate, Erreichtes der letzten Wochen/Monate, wichtige Aufgaben, Risiken, Blocker, Entscheidungen. In den Teams, mit denen ich gearbeitet habe, haben wir Statusberichte wöchentlich erstellt und diese immer auch für den Kunden bereitgestellt. So konnte der Kunde stets fundierte Entscheidungen treffen – maximale Transparenz. Das ist ein sehr essenzielles und ebenso einfaches Tool für den PM ...

Auch zur Selbstkontrolle eignet es sich, etwa zu Wochenbeginn zu erfassen: Wie stehen die Kennzahlen? Wie läuft das Budget? Wo stehen wir zeitlich? Und alle Eckdaten zusammenzufassen. Im Anschluss bespricht man den Bericht mit dem Kunden, z. B. in regelmäßigen, oft kurz gehaltenen Meetings. Sie dienen als regelmäßige Check-ins und fördern die Beziehung zum Kunden. Das muss nicht virtuell erfolgen – auch persönliche Treffen sind für die Beziehung förderlich. So schafft man Vertrauen und Transparenz, wodurch Chancen und auch Probleme oder Blocker in diesen Terminen besprochen werden.

Ben Aston:

Also, du entwickelst die Dokumentation und versuchst dann, regelmäßige Check-ins mit dem Kunden abzuhalten. In diesen Statusmeetings präsentierst du die Statusberichte. Aber was teilst du sonst noch? Es ist ein Unterschied, ob wir intern das Projekt steuern oder die Daten mit dem Kunden teilen. Abgesehen vom Statusbericht: Was sind noch deine essenziellen Werkzeuge für die Steuerung mit dem Kunden?

Maik Stettner:

Ein wichtiges Werkzeug zur Kontrolle des Projekts ist ... beispielsweise ein Change Request oder generell der Änderungsprozess samt Änderungsformularen. Immer, wenn sich der festgelegte Umfang ändert, zusätzlicher Aufwand nötig wird, oder das Projektteam umsteuern muss, sollte dies dokumentiert werden. Oft sind Change Requests wie ein Tabuthema, weil man fürchtet, der Kunde reagiert verärgert. Aber so etwas ist völlig normal.

Change Requests müssen nicht zwingend Auswirkungen haben – manchmal werden sie nur dokumentiert, auch wenn kein Budget- oder Terminproblem vorliegt. Es ist trotzdem ratsam, alles zu dokumentieren und den Kunden an den Änderungsprozess zu gewöhnen, denn falls eine Entscheidung irgendwann Budgetauswirkungen hat, sollte man sauber dokumentieren und alle auf das entsprechende Änderungsformular unterzeichnen lassen.

Ben Aston:

Ein weiteres Dokument, das du erwähnt hast, also ein weiteres Kontrollinstrument, ist das RAID-Log. Ebenfalls ein wichtiger Aspekt der Projektkontrolle. Aber wenn du nur ein einziges Dokument für die Projektkontrolle wählen müsstest, welches würdest du nehmen?

Maik Stettner:

Nummer eins ist ein solider Statusbericht. Ein RAID-Log geht noch mehr ins Detail und ist je nach Projektkomplexität nicht immer nötig. Aber ein Statusbericht sollte Elemente davon beinhalten. Wenn Risiken oder Blocker da sind, sollte man im Statusbericht Platz dafür haben, damit alle informiert bleiben. Doch regelmäßige Meetings mit dem Kunden und das Teilen der wichtigsten Kennzahlen sind für mich das wichtigste.

Ben Aston:

Es ist also eine Gratwanderung, oder? Wie viel Kontrolle schaffen wir eigentlich durch Dokumentation? Das erinnert an den Agile-vs.-Wasserfall-Ansatz. Wir wollen uns nicht an Dokumentation aufhängen, weil das das Projekt beschränken kann. Aber wie findet man die Balance, damit man nicht die ganze Zeit mit Monitoring und Berichten verbringt, sondern gerade genug steuert, um den Client einzubinden? Wie findest du diese Balance?

Maik Stettner:

Ich gehe bei neuen Projekten meist recht eigennützig vor, indem ich eine Statusübersicht erstelle, die für mich einfach zu erzeugen ist. Um das mit bestehenden Software-Tools – wie der Ressourcenplanung oder Zeiterfassung – auszuwerten. Damit kann ich auf Anhieb die Basis-Kennzahlen ziehen. Oft reicht das schon als Start; manche Kunden erwarten mehr Details. Aber aus PM-Sicht ist das schon ein sehr guter Anfang, um intern wie extern den Überblick zu behalten. Das dauert regelmäßig auch nicht lang.

Man will sich nicht zu viel Arbeit machen, da sonst das Risiko besteht, dass das Reporting untergeht, wenn es hektisch wird oder das Projekt volle Aufmerksamkeit fordert.

Ben Aston:

Das ist ein sehr guter Hinweis: Gerade ausreichend Kontrolle ist wichtig – und wichtiger noch ist der Rhythmus, in dem wir kontrollieren. Es bringt wenig, perfekte Statusberichte und Vorlagen zu erstellen und dann Stunden dafür aufzuwenden. Wenn das Reporting zu aufwendig ist, produziert man vielleicht keine Berichte mehr und verliert den Überblick.

Maik Stettner:

Genau. Und man muss bedenken: Kontrolle geht in beide Richtungen. Als PM müssen Sie Bescheid wissen, damit Sie steuern können. Der Kunde will informiert sein, aber auch das Team verdient Klarheit. Eine Entscheidung ist z. B., wie viel Details das Team bekommt. Ich habe mein Team nie mit nüchternen Reports überladen, aber andere Wege gefunden, Budgets- oder Zeitrestriktionen klar zu machen. Der Punkt ist: Es muss genug Information da sein, dass jeder am selben Projekt arbeitet.

Ben Aston:

Ja, das ist wichtig: Die Kontrollen sind nicht nur für Kunden, sondern auch für unsere Teams, damit diese die Zwänge kennen – z. B. wenn das Budget knapp wird und wir effizienter arbeiten müssen. Diese Daten helfen sowohl für Kund:innen als auch für das Team: „Leute, wir müssen umschwenken; vielleicht schaffen wir nicht alles wie gehofft. Also, gehen wir’s gemeinsam an.“

Und diese Daten, die du ansprichst, sind nicht nur PM-Aufgabe. Der Statusbericht zeigt: Wir liegen heiß am Limit. Wir haben zu viel Zeit in UX investiert, wieder zu viel in Design. Für QA bleibt kein Budget, wenn wir nicht abschließen. Man hat ein solides Tool.

In deinem Artikel hast du den Prozess für Projektkontrollen beschrieben: Evaluieren, Planen, Reagieren, Verbinden. Kannst du kurz durch den Prozess führen?

Maik Stettner:

Gerne. Als PM muss man immer wissen, wo es steht, um fundierte Entscheidungen zu treffen. Die Schritte basieren darauf. Zuerst: Evaluieren. Also den Stand im Projektplan klären. Erreichen wir das gewünschte Ergebnis? Sind die Ziele erreichbar? Das umfasst KPIs, aber man muss als PM auch unter die Haube schauen, Fragen stellen und das Team richtig verstehen. Die Skills von UX, Design, Entwicklung, Test selbst überblicken, um entscheiden zu können, wo Abstriche geht – oder eben nicht. Das weiß man nur, wenn man ins Detail geht und mit allen spricht.

Das führt zum zweiten Schritt: Planen. Oft muss man Aufgaben neu verteilen, Zeitrahmen und Umfang ändern sich. Man plant die nächsten Schritte mit den Infos, über die man verfügt. Als PM hat man den Draht zum Kunden und Einblicke ins Team und baut daraus einen Plan zum Ziel.

Anschließend: Reagieren. Die Änderungen implementieren und den Kunden informieren. Prozesse anpassen, Änderungen dokumentieren, etwa in Jira, Termine aktualisieren. Alles sauber umsetzen.

Der letzte Schritt: Verbinden. Die PMs sind der Kitt fürs Team. Jeder sollte möglichst den eigenen Überblick bekommen. Also Wissen an das Team weitergeben, alle einbinden – inklusive des Kunden – und die Änderungen gemeinsam umsetzen.

Ben Aston:

Ich höre da zwei Aspekte: Zum einen sind Daten für die Projektsteuerung unentbehrlich. Diese Kennzahlen geben sofort einen Überblick, um Ressourcen und Projekte zu priorisieren. Aber Kontrollen sind nicht nur für Daten- oder Informationssammlung da, sondern auch um das Gespräch anzustoßen, das Team einzubeziehen und gemeinsam Wege zu finden, Projekte agiler und flexibler zu liefern – statt nur am Statusbericht zu kleben. Das sehe ich so wie du: Es muss immer ein Dialog bleiben.

Aber für Leute, die noch nie Statusberichte für Kunden oder Projekte gemacht haben – und du hast das Vorgehen gerade beschrieben: Was ist für dich der erste Schritt zur Kontrolle eines Projekts? Was sollte ein PM ganz zu Beginn beachten, auch wenn er noch keine Berichte oder Kontroll-Dokumente erstellt hat? Was empfiehlst du als Einstieg?

Maik Stettner:

Für mich ist wichtig, sich ein klares Bild davon zu machen, was nötig ist, um das Projekt zu liefern. Sowohl aus Kundensicht – das kann auch reine Logistik sein –, aber: Was erwartet der Kunde, gibt es bestimmte Treiber, Fristen, z. B. Kampagnenstarts oder Vorstandspräsentationen? Und dann intern: Das passende Team zusammenstellen und wissen, wie es funktionieren wird, zumindest auf hoher Ebene. Erfahrung als Projektleiter hilft dabei, Meilensteine und grobe Eckdaten im Prozess festzulegen.

Ein Statusbericht hilft dann vor allem, den eigenen Überblick zu bewahren und keine Meilensteine zu verpassen – das ist entscheidend. Es ist die Mischung aus KPIs, Soft Skills und dem kühlen Kopf und Gesamtüberblick, auch wenn es kompliziert wird. So gelingt es, gute Entscheidungen zu treffen und für sich selbst passende Tools zur Unterstützung zu finden.

Ben Aston:

Gut gesagt. Daten nützen uns nichts, wenn wir keinen Referenzpunkt haben. Statusberichte bringen wenig ohne Projektplan als Vergleichsmaßstab. Das habe ich auch im Gespräch mit anderen PMs gemerkt: Oft fehlen Zeiterfassungen oder die Rückverfolgbarkeit der Projektzeiten. Zeitprotokollierung kann zwar mühsam sein, aber wenn man keine hat, bringt die Einführung schon mehr Steuerbarkeit – vor allem, wenn man einen Plan hat, um die Zeiten zu vergleichen. Das ist ein guter Tipp. Danke, Maik. Schön, dass du da warst.

Maik Stettner:

Danke, Ben.

Ben Aston:

Als einer unserer DPM-Experten wird Maik auch im neuen Kurs zu sehen sein, der im September startet. Er heißt „Mastering Digital Project Management“ – ein siebentägiger Crash-Kurs für digitales Projektmanagement. Dort lernen Sie, komplexe digitale Projekte effektiv zu steuern. Der Kurs umfasst Videolektionen, Aufgaben, Gruppendiskussionen, optionale Coachings. Gehen Sie zu thedpmschool.com und melden Sie sich an. Es gibt noch Plätze. Kursstart ist der 10. September. Wenn Sie sich an der Diskussion um Projektkontrollen beteiligen möchten – wie kontrollieren Sie Ihre Projekte effektiver? Welche Dokumentation nutzen Sie? Dann werfen Sie einen Blick in den Ressourcenbereich auf thedigitalprojectmanager.com und treten Sie unserem Slack-Team bei, wo spannende Diskussionen laufen. Kommentieren Sie den Beitrag, sprechen Sie auf Slack mit und lassen Sie uns gemeinsam herausfinden, wie wir unsere Projekte besser steuern können.

Bis zum nächsten Mal – danke fürs Zuhören.