Rette dein Projekt mit einem Projektstart-Dokument (mit Maik Stettner von FCV Interactive)
Manchmal geraten Projekte aus dem Ruder, einfach weil wir zu schnell loslegen. Ben Aston spricht mit Maik Stettner darüber, wie wir ein Projekteinleitungsdokument oder ein Projektbriefing nutzen können, um zu Beginn des Projekts alle auf denselben Stand zu bringen und Projekt-Kickoffs effektiver zu gestalten.
Dieser Podcast ist Teil eines Artikels, der auf The Digital Project Manager veröffentlicht wurde.
Den Artikel können Sie hier lesen.
Lies das Transkript:
Wir probieren aus, unsere Podcasts mithilfe eines Softwareprogramms zu transkribieren. Bitte entschuldige eventuelle Tippfehler, da der Bot nicht immer 100% korrekt ist.
Ben Aston:
Danke fürs Einschalten. Ich bin Ben Aston und dies ist der Podcast von The Digital Project Manager. Dieser Podcast wird präsentiert von Clarizen, dem führenden Anbieter von Software für Unternehmens-, Projekt- und Portfoliomanagement. Besuche clarizen.com, um mehr zu erfahren.
Wenn es eine Sache gibt, die du bei einem Projekt garantieren kannst, dann dass es niemals genau nach Plan läuft. Aber warum gehen Projekte eigentlich schief? Manchmal liegt es einfach daran, dass wir zu schnell starten und dabei nur auf den Abgabetermin schielen, der immer näher rückt. So kommt es, dass wir das Projekt hektisch starten und uns später wundern, warum etwas schiefgeht.
Auch wenn wir normalerweise alle Projekthintergründe, Strategien, Details, Anforderungen und Erfolgskriterien im Kopf haben, machen wir oft den Fehler zu denken, dass auch alle anderen im Team das wissen. Die Realität ist aber: Wenn es nicht dokumentiert ist, wissen es unsere Teammitglieder meist eben nicht.
Heute sprechen wir über ein Tool, das es uns ermöglicht, alle Beteiligten zu Beginn des Projekts auf denselben Stand zu bringen. Es geht um das Projektstart-Dokument, bei uns auch gerne Projektbrief genannt. Wir geben dir heute exklusive Einblicke darin, wie du einen PID erstellst und so deine Projekte effektiver machst.
Heute ist Maik Stettner bei mir zu Gast. Einer meiner Freunde und Kollegen. Maik ist einer unserer DPM-Experten bei The Digital Project Manager. Willkommen, Maik.
Maik Stettner:
Hallo. Wie geht’s dir?
Ben Aston:
Gut, danke. Schön, dass du dabei bist. Maik, erzähle doch mal ein bisschen von dir und deiner Geschichte, denn wir arbeiten ja jetzt schon – wie lange eigentlich – fünf Jahre zusammen?
Maik Stettner:
Ja, mittlerweile sind es zwischen vier und fünf Jahren.
Ben Aston:
Stimmt. Als ich Maik eingestellt habe, dachte ich kurz: „Ob er das wohl kann?“ Du kommst ja aus einem etwas anderen Bereich, nicht aus der klassischen Agenturwelt. Erzähl doch mal, wie bist du Projektmanager in einer Digitalagentur geworden?
Maik Stettner:
Also, insgesamt habe ich ungefähr 10 Jahre Erfahrung in unterschiedlichen Bereichen. Angefangen habe ich ursprünglich im Bereich Gaming und Publishing, wo ich Veröffentlichungen von Spielen in Europa und Nordamerika gemanagt habe, und bin dann in andere Branchen wie medizinische Datenbanken gewechselt, aber meist immer nah an Softwareentwicklung und Bereichen, die mit Projektmanagement, verschiedenen Teams und so weiter zu tun haben. In meiner Karriere habe ich auch Agenturerfahrung gesammelt, insbesondere bei App-Entwicklung und ersten Webentwicklung-Projekten. Als wir dann das erste Mal über eine Zusammenarbeit sprachen, habe ich letztlich ganz auf Webentwicklung und Agenturumfeld gewechselt.
Ben Aston:
Ja.
Maik Stettner:
Und ich arbeite nun seit etwa vier Jahren bei meinem aktuellen Arbeitgeber, FCV. Hier leite ich das Projektmanagement-Team und bin für die übergreifende Auslieferung der Projekte und die Zufriedenheit der Kunden verantwortlich.
Ben Aston:
Super. Für diejenigen, die jetzt zuhören und sich fragen … Sie sind vielleicht auch in einer ähnlichen Situation. Oft hören wir von Leuten, die sagen: „Okay, ich bin Projektmanager, habe Erfahrung in der Softwareentwicklung, aber überlege, in eine Agentur zu wechseln und Digital Project Manager zu werden.“ Wie war der Übergang für dich? Vom Software-Umfeld zu einer Agentur, zum digitalen Projektmanagement – was waren aus deiner Sicht die wichtigsten Unterschiede im Umgang mit Menschen und Projekten?
Maik Stettner:
Zuallererst gibt es viele Parallelen. Probleme, die du in anderen Software-Entwicklungsbereichen oder projektbezogenen Feldern findest, treten auch in Agenturen auf. Du hast verschiedene Teams, Projekte geraten aus den unterschiedlichsten Gründen ins Stocken und du kannst ähnliche Taktiken nutzen, um diese Themen zu erkennen.
Für mich bestand einer der Hauptunterschiede zu Beginn darin, wirklich sehr auf Zeit und Material und kleinere Arbeitspakete statt auf große Lieferungen zu fokussieren. Vor allem in meinem Arbeitsbereich wünschen sich Kunden höhere Transparenz und mehr Kontrolle über kleinere Arbeitspakete. Das geht mit detaillierterem Reporting und einem höheren Maß an Transparenz einher, und es ist erforderlich, dem Kunden genau zu erklären, wie Vertrauen entsteht. Das ist aufwendiger und war eine Umstellung gegenüber Produktunternehmen, wo man meist auf einen internen Launch hinarbeitet.
Unabhängig davon ist es sehr interessant zu sehen, dass es gar nicht so darauf ankommt, ob man an einer Datenbank, einem Spiel oder einer Website arbeitet – die Herausforderungen sind oft ähnlich und Erfahrungen lassen sich übertragen. Wer gute Kommunikation und die üblichen Best Practices mitbringt, wird meist auch erfolgreich sein – ganz gleich, was gebaut wird.
Ben Aston:
Das ist spannend. Du hast gesagt, es gibt viele Parallelen und doch Unterschiede. Kannst du beschreiben, wie dein Job jetzt – du leitest nicht nur Projekte, sondern auch Teams – und bezüglich Projektportfolio-Management, also beim gleichzeitigen Managen vieler Projekte mit konkurrierenden Ressourcen? Was sind typische Herausforderungen als Leiter des PMO?
Maik Stettner:
Meine Rolle ist mittlerweile ganzheitlich. Ich achte darauf, dass alles läuft, und mein Hauptfokus liegt auf Ressourcenmanagement – sprich, die richtigen Leute zur richtigen Zeit für die richtige Aufgabe zu finden.
Ben Aston:
Verstehe.
Maik Stettner:
Man muss oft Kompromisse finden, wenn Aufgaben länger dauern, während das nächste Projekt schon wartet, und dann Anpassungen so moderieren, dass Kunden offen mit mir sprechen können. Das Risiko in einer Führungsrolle ist, dass man oft nur für Eskalationen zuständig ist – also dann zum Einsatz kommt, wenn etwas schiefläuft.
Ben Aston:
Ja.
Maik Stettner:
Aber ich spiele auch aktiv in Projekten mit, um Vertrauen aufzubauen und sicherzustellen, dass organisatorisch alles funktioniert – egal ob beim Ressourcenmanagement, aus operativer Sicht oder bei standortübergreifender Zusammenarbeit, denn wir haben mehrere Büros. Wichtig ist, dass z. B. Kollegen in Toronto und Victoria gut zusammenarbeiten. Das ist der Großteil meiner Arbeit – aber ich übernehme trotzdem noch Projektmanagement, denn das ist meine Leidenschaft.
Ben Aston:
Erzähle mal zum Thema Ressourcenmanagement: Wie gehst du vor, wenn zwei Projektmanager im Team jeweils ihre Ressourcen für unterschiedliche Projekte am selben Abgabetag brauchen? Wie priorisierst du? Wie entscheidest du, welches Projekt die Ressourcen zuerst bekommt?
Maik Stettner:
Zunächst prüfe ich die Priorität: Gibt es harte Deadlines oder Versprechen gegenüber dem Kunden? Gibt es Spielraum bei den Timings? Ist das Projekt bereits vertraglich abgesichert? Geht es darum, dem Kunden einen Gefallen zu tun – auch das machen wir gern, sofern wir Zeit haben. Aber wenn ein anderes Projekt in drei Tagen live geht, können wir niemanden abziehen.
Im Idealfall kommt gar nicht erst zu Engpässen, denn der Projektmanager sollte Puffer einkalkulieren. Ich erwarte auch von meinem Team, dass sie für ihre Ressourcen kämpfen und das Problem an den Ressourcenmanager weitergeben, damit gemeinsam eine Lösung gefunden wird.
Ben Aston:
Vielleicht ist das ein kanadisches Ressourcenproblem.
Maik Stettner:
Definitiv ein kanadisches Patt.
Ben Aston:
Kanadier sind zu nett und wir als Europäer können das sagen ...
Maik Stettner:
Stimmt, ich nehme sie in Europa auch anders wahr.
Ben Aston:
Welche Tools nutzt ihr, speziell zur Ressourcen- oder Projektverwaltung? Gibt es Neues, bei dem du denkst, das hättet ihr viel eher nutzen sollen?
Maik Stettner:
Für Ressourcenmanagement oder allgemein?
Ben Aston:
Beides – Ressourcenplanung und Projektmanagementtools.
Maik Stettner:
Wir nutzen einen Standard-Werkzeugkasten für das Zeitmanagement; MS Project ist für Kunden oft zu komplex. Mittlerweile setzen wir auf Cloud-Lösungen – etwa mit Office 365. Insgesamt passt unser Prozess nicht „out of the box“ – vieles läuft noch per Hand. Mein Ziel wäre, ein eigenes Tool für unsere Anforderungen zu nutzen oder zu entwickeln.
Ben Aston:
Was fehlt den existierenden Tools noch?
Maik Stettner:
Eigentlich ist das Problem nicht besonders komplex – ein Tool, das Zeiterfassung, Ressourcenplanung wie z. B. Resource Guru, und finanzielle Komponenten (z. B. Stundensatzabrechnung) miteinander verbindet, wäre ideal. Der Prozess ist einfach, aber Systeme kommen nicht immer mit den Realitäten wie Projektwahrscheinlichkeiten oder Verschiebungen zurecht, sodass viel manuelle Arbeit entsteht. Die perfekte Lösung habe ich noch nicht gefunden.
Ben Aston:
Lass uns zum Artikel über Projektstart-Dokumente kommen. Wieso gehen Projekte oft schief? Weil wir sie nicht richtig starten. Wir machen Annahmen oder sagen dem Team: „Die Dokumente sind auf dem Server, lies sie dir durch.“ Doch wenn das Projekt dann fehlschlägt, verstehen wir nicht warum – dabei fehlt oft das Verständnis für das Projektziel.
Lass uns daher darüber sprechen, wie wir bessere Projektbriefe bzw. Projektstart-Dokumente schreiben. Beschreibe deinen Ablauf zum Projekt-Kickoff. Wo passt das Projektstart-Dokument oder der Brief hinein? Wann wird es erstellt?
Maik Stettner:
Angenommen, du hast einen neuen Kunden. Der übergeordnete Vertrag ist unterschrieben – meist ein Rahmenvertrag (Master Service Agreement). Als nächstes müssen die Details konkretisiert werden.
Typischerweise denkt man an ein Leistungsbeschreibung/Statement of Work. Das Problem ist, dass zu Projektbeginn alles noch sehr grob ist. Ein Projektstart-Dokument oder Kick-off Meetings helfen, den Kunden zu verstehen und weitere Faktoren zu beleuchten, die ggf. noch nicht genannt wurden.
Sobald das erste Statement of Work grob steht, macht unser Agenturteam ein internes Kickoff-Meeting, dann ein externes Kickoff mit dem Kunden, in dem erklärt wird, was das Team tun wird, wer beteiligt ist und wie zusammengearbeitet wird.
Das Projektstart-Dokument – oder der Projektbrief – ist für mich der nächste Schritt. Schon früh ist klar, dass es sich um ein dynamisches Dokument handelt, weil vieles noch unscharf ist, aber es ist ein gutes Werkzeug, um geschäftlichen Kontext zu geben und grundlegende Projektparameter sowohl für Kund:innen als auch intern zu klären.
Ben Aston:
Das heißt, das Projektstart-Dokument baut auf der Leistungsbeschreibung und dem Rahmenvertrag auf, ergänzt aber konkrete Aspekte. Was sollte deiner Meinung nach inhaltlich drinstehen – wie gibst du Kontext ohne zu überfrachten?
Maik Stettner:
Es geht vor allem darum, warum das Projekt durchgeführt wird und welche Herausforderungen zu lösen sind. Gibt es treibende Faktoren wie Verkaufssteigerung oder Branding? Wie sieht Erfolg aus, auch wenn wir noch auf einem hohen Abstraktionsniveau sind?
Das kann so einfach sein wie „bessere Verkaufsgespräche“ oder bei einer Self-Service-Website die Konzentration auf Content-Management. Hauptsache, das Team weiß, worauf es hinarbeitet. Auch wenn Details noch fehlen, hilft das beim Framing.
Wenn z. B. das Ziel Branding ist, aber jemand fragt: „Warum steigen die Umsätze nicht?“, kann man darauf verweisen, was zu Projektbeginn festgelegt wurde. Es ist nützlich, eine Gesprächsbasis und Einigkeit über die Ziele zu dokumentieren.
Ben Aston:
Es ist wichtig, diese Ziele zu klären und zu dokumentieren. Was sind die wichtigsten Parameter, die für das Team wichtig und einschränkend sind?
Maik Stettner:
Man will die Expert:innen nicht einschränken – gibt man aber völlige Freiheit, arbeiten sie womöglich am Thema vorbei. Daher unbedingt Rahmen setzen: Budget, Zeitplan, Zeitrahmen. Diese Dinge sollten kein Geheimnis sein. Es ist wertvoll, dies offen anzusprechen, damit das Team versteht: Das ist die Vereinbarung mit dem Kunden. Auch wenn Anpassungen nötig werden, sollte das Team wissen, dass man hinter ihnen steht und für Puffer und Risiken eintritt.
Das Team muss am Ende überzeugt und motiviert sein, zusammen mit dem Kunden ein erfolgreiches Projektergebnis zu schaffen.
Ben Aston:
Zum Abschluss – du empfiehlst auch eine Projektstruktur oder ein Ressourcenplan grob zu skizzieren. Wie gehst du vor, wenn das Projekt noch diffus ist?
Maik Stettner:
Meist ist das zu Beginn ein „educated guess“. Die Grundlage ist die existierende Leistungsbeschreibung oder Team-Schätzungen. Es bleiben viele Unbekannte – etwa die Zahl der Revisionen oder die Erreichbarkeit des Kunden. Was immer man plant, es wird sich verändern.
Aber selbst eine grobe Planung hilft schon, Ressourcen zu sichern und dem Team Orientierung zu geben. Im Prozess werden die Pläne ohnehin detaillierter. Frühzeitig über Teamrollen nachzudenken – etwa ob z. B. ein:e Designer:in nötig ist – gibt den nötigen Input, um später die richtigen Fragen zu stellen. Es ist definitiv besser, irgendeinen Plan zu haben als gar keinen!
Ben Aston:
Da stimme ich dir zu – „irgendein“ Plan ist besser als keiner, weil man darauf aufbauen und anpassen kann. Gibt es noch andere Formen für Projektbriefe? Wie verändert sich die Rolle des Projektstart-Dokuments im Projektslebenszyklus?
Maik Stettner:
Die von mir vorgeschlagene Vorlage ist ein Beispiel. Es gibt sicher ein Mindestmaß an Informationen; weitere Aspekte wie Risikomanagement oder ein RACI-Chart können in anderen Dokumenten weitergeführt werden.
Es muss nicht überformalisiert sein. Wichtig ist, dass sich alle einig sind – egal, ob auf SharePoint, BaseCamp oder per E-Mail dokumentiert und später darauf aufbauend angepasst wird. Das Dokument sollte schriftlich, von allen anerkannt und für alle bindend sein – Unterschriften braucht es nicht zwingend, aber Zustimmung ist Pflicht, denn darauf baut das Team seine Arbeit auf.
Ben Aston:
Falls du dich jetzt fragst, wie du am besten beginnst: Maik hat eine sehr gute Vorlage erstellt, die du für deinen Projektbrief oder das Projektstart-Dokument nutzen kannst. Im Artikel findest du den Download. Vielen Dank, Maik, dass du heute dabei warst!
Maik Stettner:
Danke, dass ich mitmachen durfte.
Ben Aston:
Sehr gerne. Maik ist übrigens auch im neuen Kurs „Mastering Digital Project Management“, der im September startet, als Experte vertreten. Wenn du PM-Training suchst: Es ist ein siebentägiger Kompaktkurs mit Videolektionen, wöchentlichen Aufgaben, Gruppendiskussionen und auf Wunsch Coachingsessions. Anmelden kannst du dich unter digitalprojectmanagerschool.com.
Wenn du dich in die Diskussion zu Projektstart-Dokumenten oder Projektbriefen einbringen möchtest, besuche den Ressourcenbereich auf digitalprojectmanager.com oder tritt unserem Slack-Team bei, wo viele spannende Gespräche laufen. Kommentiere den Artikel und teile ihn gerne! Bis zum nächsten Mal – danke fürs Zuhören.