Was Sie bei Ihren Projekten weglassen können (mit Patrice Embry)

Lesen Sie das Transkript:

Wir probieren gerade aus, unsere Podcasts mit einem Softwareprogramm zu transkribieren. Bitte entschuldigen Sie etwaige Tippfehler – der Bot ist nicht zu 100 % korrekt.

Ben Aston:

Danke, dass Sie eingeschaltet haben. Ich bin Ben Aston und dies ist der Podcast „Digital Project Manager“.
Wir hören immer wieder, was wir alles tun sollten, und ich gehöre auch zu denen, die das sagen. Es herrscht ein großer Druck, sich selbst zu verbessern, die Dinge richtig zu machen – und noch größer ist der Druck, dabei gesehen zu werden. Aber sollten wir tatsächlich immer all diese Dinge tun? Hören Sie weiter zu, um zu erfahren, wie Sie sich jede Menge Zeit sparen können, indem Sie manche Aufgaben aus Ihrer PM-Routine streichen oder reduzieren, die nicht für jedes Projekt erforderlich sind.
Wir sprechen darüber, wie Sie sich wieder Zeit fürs Leben verschaffen und weniger Zeit im Büro oder am Schreibtisch verbringen, indem Sie sechs Aufgaben identifizieren, die Sie sich sparen können. Dieser Podcast dreht sich im Wesentlichen darum, vermeintliche Zwänge und Musts abzuwerfen und die Arbeitsweise zu optimieren.
Heute begrüße ich Patrice Embry, die – und das muss ich anerkennend erwähnen – wahrscheinlich das aktivste Mitglied in unserem Slack-Team ist. Falls Sie noch nicht dabei sind, könnten Sie jetzt schon mit Patrice sprechen. Im Community-Bereich des Digital Project Manager können Sie sich anmelden. Patrice ist fast immer da und immer im Gespräch – also eine gute Ansprechpartnerin.
Kurz vorgestellt: Patrice ist freiberufliche digitale Projektmanagerin. Sie ist zertifizierte Scrum Masterin und arbeitet seit vielen Jahren in verschiedensten Agenturen und Unternehmen. Hören Sie auch in unsere anderen Podcasts rein, um mehr über ihre Erfahrungen zu erfahren. Sie hat alles Mögliche gemacht – sie ist also definitiv eine gute Kontaktperson.
Herzlich willkommen, Patrice.

Patrice Embry:

Hallo. Danke, dass ich dabei sein darf.

Ben Aston:

Sehr gerne. Patrice, kannst du uns erzählen, ob du seit unserem letzten Gespräch an interessanten Projekten arbeitest?

Patrice Embry:

Ich habe gerade eine App abgeschlossen, die Menschen hilft, kurze, schnell zu erledigende Jobs zu finden. So ähnlich wie Care.com, aber noch schneller, für Leute, die wirklich dringend kurzfristige Jobs erledigen lassen wollen. Eine spannende App. Sie ist derzeit noch in der Beta, also noch nicht komplett veröffentlicht, aber das Projekt war besonders, weil ich mit Leuten aus aller Welt zusammengearbeitet habe.
Ich habe zum Beispiel noch nie zuvor mit jemandem aus Nigeria gearbeitet – das war mein erstes Mal, dass ich auf Igbo „Hallo“ sagte. Das hat echt Spaß gemacht.

Ben Aston:

Das klingt nach einem Scam-Projekt. Also nicht diese App, aber das ist so ein klassisches Nigerian-Scam-Klischee. War das Entwicklerteam auch dort?

Patrice Embry:

Wie bitte?

Ben Aston:

War das Entwicklerteam in Nigeria?

Patrice Embry:

Ja.

Ben Aston:

Oh, wirklich?

Patrice Embry:

Ja. Der Frontend-Entwickler war in Nigeria, der Backend-Entwickler in Mexiko und unser technischer Leiter war in Schweden. Dann war da noch ich bei Philadelphia und der Kunde saß in Boston. Wir waren weltweit verteilt.

Ben Aston:

Das sind viele Zeitzonen, mit denen man rechnen muss.

Patrice Embry:

Ja, das stimmt.

Ben Aston:

Das war sicher nicht einfach. Wie hast du das hinbekommen?

Patrice Embry:

Ich habe eine Uhrzeit gefunden, mit der alle irgendwie leben konnten – 8:00 Uhr morgens Eastern Time. Für unsere europäischen Freunde war das schon spät, für unseren nigerianischen Kollegen ziemlich spät und Mexiko musste etwas früher aufstehen, aber wir haben es hinbekommen.

Ben Aston:

Cool. Ist das eine Start-up-App oder ...?

Patrice Embry:

Ja. Es war eigentlich eine Dienstleistung, die von einer Frau entwickelt wurde, die das zunächst nur für ein paar Leute gemacht hat. Dann wollten immer mehr Leute das nutzen, sodass sie irgendwann sagte: „Ich kann das nicht mehr alleine koordinieren. Ich mache dazu eine App.“ Sie steht wirklich ganz am Anfang. Ich will noch nicht zu viel verraten, aber wenn sie startet, erzähle ich allen davon. Ich denke, es wird ein echt cooler Service.

Ben Aston:

Klingt nach einem spannenden Projekt. Was waren die größten Herausforderungen? Gab es Schwierigkeiten?

Patrice Embry:

Es war teilweise schwierig, da der Kunde nicht sehr technikaffin war. Sie hatte das normale Wissen, wusste aber nicht viel über Apps. In der Technikbranche hat man oft mehr Hintergrundwissen. Wir mussten vieles erklären.
Manchmal wird einem erst während eines Projekts klar, was nie bedacht wurde. Das Testing war ziemlich intensiv, weil wir ständig auf neue Wege gestoßen sind, die vorher niemandem aufgefallen waren. Darum ist sie jetzt in der Beta. Es war zwar anstrengend, aber es hat Spaß gemacht. Das Team war toll.

Ben Aston:

Welche Tools hast du genutzt, um alle in den unterschiedlichen Zeitzonen zusammenzubringen? Und wie hast du die Anforderungen vom Briefing bis zur Umsetzung gemanagt?

Patrice Embry:

Es war wirklich ein lockeres Projekt. Es gab nicht viel Extra-Budget – was gut zu unserem heutigen Thema passt. Ich hatte nicht viele Stunden zur Verfügung und musste deshalb sehr gezielt auswählen, was ich mache und was ich nicht mache, denn ich wollte mein Budget nicht für meine Stunden verbrauchen, sondern so viel Zeit wie möglich für die Entwicklung übrig lassen.
Wir haben Slack genutzt, weil es kostenlos ist, Chelo und viele Google-Dokumente – ebenfalls kostenlos. Es ging darum, all das zusammenzubringen, ohne kostenpflichtige Features zu nutzen, da wir so schlank wie möglich arbeiten mussten.

Ben Aston:

Wie bist du zu diesem Projekt gekommen? War das über Kontakte?

Patrice Embry:

Ja. Du hast ja schon gesagt, dass ich ständig auf Slack bin – und nicht nur auf deinem Slack. Als Freelancer muss man immer offen für neue Kontakte sein. Ich spreche mit vielen Leuten über viele Themen.
Ich weiß ehrlich gesagt nicht mehr, wie ich zu dem Projekt gekommen bin – wahrscheinlich eine lange Kette aus Empfehlungen. Aber das ist typisch für mein Networking: Die Projekte entstehen auf manchmal sehr merkwürdigen Wegen.

Ben Aston:

Hast du das Projektteam zusammengestellt?

Patrice Embry:

Nein.

Ben Aston:

War das deine Aufgabe?

Patrice Embry:

Nein, ich wurde in ein Team gesteckt und wir haben dann gemeinsam unsere Aufgaben verteilt. Ich musste keine Ressourcen zusammensuchen und war mit dem Team sehr zufrieden. Ich hoffe, wir arbeiten in Zukunft wieder zusammen, denn jeder hat viel eingebracht.

Ben Aston:

Bei solchen Projekten ist es interessant, wenn der Kunde weniger Ahnung hat – meist bedeutet das auch mehr Flexibilität und Vertrauen. Oft ist das sehr angenehm. Der Nachteil ist das berühmte „Drück mal STRG+F5“ ...

Patrice Embry:

Davon gab es einiges. Aber es ist auch gut, weil man beim Entwickeln für eine breite Masse merkt, dass nicht jeder technikaffin ist. Zurück zu den Grundlagen zu gehen war auch für die App-Entwicklung richtig. Wir mussten alles klar kennzeichnen, auch das Scrollen. Es war für das Projekt wirklich hilfreich.

Ben Aston:

Gut. Kommen wir zu dem, worüber wir schon gesprochen haben: Wie wir Projekte tatsächlich managen und was es in der Theorie und in der Praxis bedeutet – gerade mit Methoden wie PMP, PMBOK und allen Prozessen, Register und Statusberichten usw. Oft werden wir von Administrativem erschlagen.
Machen wir Dinge, weil sie richtig sind – oder investieren wir Zeit in Falsches? Wir haben gerade über „Start, Stop, Continue“ gesprochen. Was sollten wir starten, was können wir stoppen/ reduzieren, was weitermachen?
Was würdest du sagen, sind absolute Must-haves zu Projektstart, wie im genannten Beispiel?

Patrice Embry:

Für mich sind das immer Zeitplan und Anforderungen. Budget kommt hinterher. Zeitplan ist unverzichtbar, ebenso wie Anforderungen – sonst weiß niemand, was er machen soll. Das sind für mich die Dinge, die absolut sein müssen. Die nicht verhandelbaren Grundlagen.

Ben Aston:

Und Anforderungen – meinst du damit ein Statement of Work oder wie erfasst du die Anforderungen?

Patrice Embry:

Gute Frage. Sie müssen nicht in einem Dokument stehen, aber das Projektziel und die Erwartungen müssen geklärt sein. Statements of Work nehmen vieles als selbstverständlich an, aber nicht alles steht da drin – es gibt eine weitere Ebene von Dingen, die geklärt werden müssen. Diese müssen definiert sein, sonst weiß niemand, was zu tun ist.

Ben Aston:

Absolut. Für mich sind es Schätzungen, Zeitplan, Statement of Work. Ohne diese Dokumente kann ich kein Projekt steuern. Man muss wissen, wie der Stand ist.

Patrice Embry:

Woher weiß man sonst, ob es fertig ist? Oder warum etwas nicht aufhört? Genau.

Ben Aston:

Meistens sind diese Unterlagen, wenn man ein Projekt übernimmt, schon etwas veraltet. Wie hältst du diese Dinge aktuell, damit alle auf demselben Stand sind?

Patrice Embry:

Ich erinnere alle Beteiligten jede Woche (oder bei jedem Meeting) an den Zeitplan: Wo stehen wir, was ist das nächste Ziel, was der Endpunkt? Ist eine Frist kritisch, hören die Leute am meisten von mir.
Die Anforderungen aktualisiere ich so oft es geht, am liebsten in Tools wie Trello oder Jira, wo die Entwicklung nachvollziehbar ist. Sonst eben per Dokumentation. Das ist ein kontinuierlicher Prozess.

Ben Aston:

Genauso mache ich das auch. Ich schreibe beim Scope-Change einen Change Request, damit ich eine Unterschrift habe und der Verlauf festgehalten ist. Das ist besonders bei mehreren Ansprechpartnern und Kompetenzüberschneidungen wichtig.

Patrice Embry:

Genau.

Ben Aston:

Sprechen wir über Überflüssiges: Wenn Statement of Work, Anforderungen, Zeitplan und Schätzung Pflicht sind, was braucht man vielleicht nicht unbedingt so detailliert? Du nennst etwa detaillierte Budget- und Projektaufschlüsselungen ...

Patrice Embry:

Ja. Mein Background war zunächst sehr detailverliebt: Alles nach Schema F. In großen Agenturen wird das verlangt. Aber bei kleineren Agenturen oder als Freelancer kann man das nicht immer leisten. Damals habe ich Budgets in Excel mit Pivot-Tabellen, bedingten Formatierungen und Referenzen gepflegt, Prozent fertig etc. Das hat dann wöchentlich jede Rolle abgebildet.
Das war zwar sinnvoll, weil ich jederzeit Auskunft geben konnte, wenn der Kunde oder Chef das verlangt hat, aber es kostet viele Stunden. Ist das für den Kunden oder Vertragspartner nicht relevant, kann ich mir das sparen. Es kostet Zeit und Geld und manchmal ist es aus reiner Pflicht. Daher: Nur so detailliert wie nötig – je nachdem, was wirklich gebraucht wird.

Ben Aston:

Kalkulierst du deinen PM-Aufwand als prozentualen Anteil an der Gesamtzeit oder pro Job?

Patrice Embry:

Früher habe ich alles prozentual aufgeteilt, insbesondere in großen Agenturen. Aber mit meiner vielfältigen Erfahrung habe ich fest gestellt: Es reicht nicht, pauschal zu prozentualisieren, gerade als Freelancer. Schätzungen mache ich mittlerweile sehr aufgabenbezogen und rechne ggf. den Anteil pro Task, nicht mehr pauschal über alles.
Früher habe ich 20 % für Account Management und nochmal 20 % für Projektmanagement verrechnet, das war insgesamt 40%. Aber oft war das Gesamtbudget sowieso falsch kalkuliert und dann hilft das beste Prozentrechnen nichts.

Ben Aston:

20 + 20, das ist wirklich viel. Also ist es nicht zu viel, sondern einfach zu wenig Stunden, richtig?

Patrice Embry:

Genau – meist nicht, weil die Prozentsätze falsch waren, sondern weil das Gesamtbudget nicht stimmt. Da muss man ganz genau hinschauen.

Ben Aston:

Absolut, das ist auch meine Erfahrung. Wichtig ist, seine Detailtiefe am Kundenbedarf festzumachen. Und auch: Wie risikoavers ist der Kunde eigentlich? Je nach Wunsch und Zahlungsbereitschaft kann man tiefer oder oberflächlicher berichten – aber alles kostet Geld.
Tools nehmen einem vieles ab, aber für die meisten Projekte ist es immer noch händische Arbeit in Tabellen, Zeiterfassung, Nachrechnen ...
Wenn du also weniger detailliert arbeitest: Wie hältst du dennoch Überblick?

Patrice Embry:

Früher habe ich alle Budgets nach Rollen, nach Aufgaben etc. jede Woche aktualisiert. Das wäre das Erste, was ich streiche, wenn Zeit/Budget knapp sind. Also: Anfangs planen, aber nicht mehr jede Woche alle Werte nachziehen. Das spart enorm Zeit.
Dann: Alle Analysen, die über das Wesentliche hinausgehen – ebenfalls weglassen. Nur noch prüfen: Sind wir im Budget? Haben wir noch genug Stunden? Stimmt der Fertigstellungsgrad mit dem Budgetverbrauch überein? Ja? Super. Dann weiter machen.
Weniger in Tabellenkalkulationen verlieren, mehr aufs Wesentliche konzentrieren.

Ben Aston:

Gerade bei großen Projekten mit vielen Ressourcen ist das Monitoring besonders wichtig – der Burn Rate ist dann einfach viel höher. Bei kleinen Teams ist das Risiko natürlich geringer.

Patrice Embry:

Genau. Ich würde trotzdem einmal wöchentlich prüfen, aber nicht mehr alles analysieren. Es kommt manchmal auch vor, dass jemand einfach sagt: „Mir ist das Budget egal, hau rein.“ Klingt entspannt, aber ist manchmal auch verunsichernd.
Auch dann mache ich mir intern ein Budget, um zumindest eine Übersicht zu behalten – Verantwortung gehört dazu.

Ben Aston:

Und das berühmte „Das Budget ist mir egal“ stimmt meistens nicht. Es gibt Unterschiede zwischen 10.000 Überzug und 100.000 oder 500.000 ...

Patrice Embry:

Genau. Irgendwann sieht man gar nicht mehr, wie weit es drüber ist – dann läuft es völlig aus dem Ruder. Das ist stressig.

Ben Aston:

Wenn ein Team sagt: „Wir sind seit drei Monaten über Budget“ ...

Patrice Embry:

Wen interessiert's dann noch ...

Ben Aston:

Und dann arbeiten alle mehr und mehr, ohne Sinn und Kontrolle. Der Überblick fehlt, man könnte ja Negativzahlen eintragen ...
Kommen wir zu Statusberichten – wie umfassend sollten sie sein? Meine Status-Reports an Kunden enthalten Budgetdaten, Wochenübersicht und Ausblick. Man kann noch viel mehr reinpacken. Wie handhabst du das?

Patrice Embry:

Oft sind Statusberichte ein Versuch, den eigenen Wert sichtbar zu machen. Je umfangreicher, desto mehr sieht es nach Arbeit aus. Das kostet viel Zeit und ist manchmal nicht erforderlich.
Mein letzter Kunde, die App-Gründerin, war nicht sehr technikaffin. Sie wollte nur wissen: Läuft alles, schaffen wir den Termin, und braucht ihr etwas von mir? Sie war meistens nicht mal beim Call dabei. Also, warum sollte ich dann lange Statusberichte schreiben?
Vieles habe ich dann gestrichen: Was wurde letzte Woche gemacht, was ist als Nächstes geplant ... sie wollte nur das Wesentliche.
Kurz: Die Berichte an den Kunden anpassen. Nur aufführen, was wirklich nötig ist oder explizit gewünscht wird.

Ben Aston:

Sehr guter Hinweis: Oft übernehmen wir einfach das Statusbericht-Template vom letzten Projekt und fügen was dazu, was alter Kunde wollte – das kann ausufern. Vieles interessiert den Kunden nicht. Einfach auf das Minimum reduzieren und nach und nach erweitern, falls der Kunde mehr wünscht. Und wenn ein Statusbericht Stunden dauert, läuft schon was falsch.

Patrice Embry:

Ich sage auch selbst: Wenn der Kunde mehr Infos verlangt, erkläre ich, dass jede Zusatzstunde pro Woche aufs Gesamtprojekt schlägt. Meist reicht es, das einmal zu zeigen, damit sie den Mehraufwand erkennen – oft wollen sie es dann doch nicht mehr wissen.

Ben Aston:

Richtig. Wenn man die Konsequenz klar macht: „Wollen Sie eine Stunde pro Woche mehr? Das summiert sich auf 25 Wochen = 5.000 Euro ...“ – dann wird klar, ob es wirklich notwendig ist.

Patrice Embry:

Ganz genau.

Ben Aston:

Okay, dann lassen wir das also. Aber ein wichtiger Punkt: Bei risikoreichen Projekten oder problematischen Kunden sollte man zumindest Risiken im Report halten, um im Ernstfall einen Nachweis zu haben.

Patrice Embry:

Absolut.

Ben Aston:

Das kann man machen.

Patrice Embry:

Als Faustregel gilt: Man muss sehr sicher sein, etwas zu entfernen – und flexibel genug, es schnell wieder hinzuzufügen. Die Erfahrung, das Selbstvertrauen zählen viel.

Ben Aston:

Absolut, nehmen wir das als Warnung. Nächstes Thema: Scrum-Zeremonien. Scrum besteht ja aus diesen Meetings – das vermittelt jedes Training. In der Realität ist das aber ein echter Zeitfresser, wenn man jede Zeremonie einzeln plant und abhält ... Deine Empfehlung: Muss man nicht immer, manchmal kann/sollte man Meetings zusammenlegen ...?

Patrice Embry:

Scrum-Puristen sind kritisch, wenn man davon abweicht. Aber die meisten zertifizierten Scrum Master sind sich einig: Man sollte nie mehr tun als nötig. Wenn Grooming, Planning, Review etc. auf verschiedenen Tagen und Zeiten stattfinden, kann das bei kleinem Budget zu viel werden.
Deshalb: Bei wenig Zeit oder Budget kann man Sessions zusammenlegen – etwa Grooming, Planning und Review am Stück. Das bringt oft sogar mehr Schwung und hilft, direkt nach dem Review ins Planning zu gehen. Kurz: Die Zeitnutzung am Projekt orientieren, nicht dogmatisch alles abarbeiten.

Ben Aston:

Das finde ich hilfreich, auch retrospektiv: Kontinuierliche Verbesserungen sind wichtig, aber Umfragen und Statistiken machen Retros nicht besser. Manchmal reicht es, kurz festzuhalten, dass alles okay war – ohne stundenlange Nachbereitung.

Patrice Embry:

Genau, Daumen hoch, weiter so.

Ben Aston:

Eben. Man muss nicht unbedingt noch einen Bericht schreiben ...

Patrice Embry:

Ja.

Ben Aston:

Man sollte pragmatisch sein: „Lasst uns das Projekt einfach erledigen.“

Patrice Embry:

Genau. Statusberichte dienen oft dem Kunden als Existenzbeweis. Retros können solche für interne Stakeholder sein. Daher immer prüfen: Lohnt sich der Aufwand? Und wieviel Zeit habe ich wirklich?

Ben Aston:

Sehr gutes Beispiel. Abschließend noch zu Kick-Off-Meetings. Du schlägst im Artikel vor: „Vielleicht reicht auch mal eine Kick-Off-E-Mail.“ Wie funktioniert das?

Patrice Embry:

Ja.

Ben Aston:

Wir sehen uns in einer Woche?

Patrice Embry:

Lustig, aber ja – das habe ich tatsächlich gemacht. Besonders in Pharma-Agenturen mit immer gleichen Standards und Teams hat sich das angeboten – vor allem bei Printprojekten: Es gibt immer die gleichen Akteure, Rollen und Abläufe. Diese kennen ihre Aufgaben bereits.
In einer Kick-Off-Mail erläutere ich, was im aktuellen Projekt anders ist, bringe den Zeitplan und die ersten Aufgaben. Das reicht, wenn die Teams es schon kennen. Die Kolleg:innen waren meist froh, keine Zeit ins Meeting investieren zu müssen. In solchen wiederholbaren Projekten funktioniert das gut. Ich habe das oft gemacht, sehr erfolgreich sogar.

Ben Aston:

Stimmt, das kann so funktionieren – wenn die Rahmenbedingungen bekannt sind. Aber meistens gibt es bei mir neue Teammitglieder oder neue Anforderungen. Dennoch: Man sollte sich immer fragen: Mache ich das Meeting, weil ich es immer so mache oder weil es wirklich nötig ist? Manchmal reicht eine knappe Briefing-E-Mail. Es gibt häufig Vorlagen, bei denen immer das gleiche eingetragen wird ... Briefingprozesse kann man optimieren.
Nochmal: Nicht jeder Textbaustein muss jedes Mal gebraucht werden.

Patrice Embry:

Genau.

Ben Aston:

Kurz und klar: „Leute, das wollen wir tun, das brauche ich von euch, hier die Tasks – alles klar?“ Nicht alles muss nach Schema F laufen. Take-Away aus unserer Diskussion heute: Jedes Projekt ist unterschiedlich. Nur weil beim letzten Mal etwas aufwändig war, muss es diesmal nicht ebenso aufwändig sein. Anpassen, flexibel bleiben!

Patrice Embry:

Absolut.

Ben Aston:

Super, danke Patrice, dass du dabei warst! Wenn ihr euch an der Diskussion beteiligen wollt, kommentiert Patricias Beitrag oder besucht den Community-Bereich auf thedigitalprojectmanager.com. Bis zum nächsten Mal, danke fürs Zuhören.