Haben Sie schon einmal ein extrem kurzes Projekt geleitet? In dieser Folge erfahren Sie praxisnahe Tipps für kurzfristige Projekte: Projektmanagerin Jenna Trunzo berichtet über die Fallstudie, die sie nach der Leitung eines zweiwöchigen Projekts durchgeführt hat. Erfahren Sie, was funktioniert hat – und warum – sowie, was sie ändern musste, um ein Projekt in einem so kurzen Zeitraum erfolgreich abzuschließen.
Dieser Podcast ist Teil eines Artikels, der auf The Digital Project Manager veröffentlicht wurde.
Den Artikel können Sie hier lesen.
Dieser Podcast wird Ihnen präsentiert von Clarizen, dem führenden Anbieter von Projektmanagement-Software für Unternehmen.
Erfahren Sie mehr bei Clarizen
Verwandte Links:
- DPM-Fallstudie: Ein zweiwöchiges Projekt managen
- Clarizen | Projektmanagement-Software
- So schätzen Sie Projekte ein: Der vollständige Leitfaden für Projektbudget & Kostenschätzung
- Projektmanager werden (So geht’s!)
- 7 unverzichtbare Projektmanagement-Kompetenzen
- Agil vs. Wasserfall: Was ist die richtige Methode für Ihr Projekt?
- Expertenbewertung: Die 10 besten Projektmanagement-Tools
- Treten Sie unserem Projektmanager-Slack-Team bei
Lesen Sie das Transkript:
Wir testen das Transkribieren unserer Podcasts mit einer Software. Bitte entschuldigen Sie Tippfehler – der Bot ist nicht immer 100% korrekt.
Ben Aston:
Willkommen zum DPM-Podcast, in dem wir über die Theorie hinausgehen und Expertenratschläge für die Leitung besserer Digitalprojekte geben. Danke fürs Einschalten. Ich bin Ben Aston, Gründer von The Digital Project Manager. In der digitalen Wildwest-Welt, die wir Zuhause nennen, ist es nicht wirklich überraschend, wenn uns ein Projekt mit winzigem Budget, sehr unklarem Umfang und engem Zeitplan übertragen wird. Aber was tun, wenn der Zeitrahmen nur zwei Wochen beträgt? Im heutigen Podcast besprechen wir, wie man ein Projekt effektiv plant und durchführt, auch wenn, ehrlich gesagt, nicht genug Zeit bleibt, um alles richtig zu machen. Bleiben Sie dran, wenn Sie erfahren möchten, worauf Sie verzichten können und an welcher Stelle Abkürzungen Ihr Projekt zum Scheitern bringen.
Ben Aston:
Heute ist Jenna Trunzo bei mir. Jenna ist zertifizierte ScrumMasterin, außerdem Certified Product Owner und Projektmanagerin bei Globant – zumindest glaube ich, dass man es so ausspricht. Das Unternehmen sitzt in Raleigh, North Carolina. Wir sprechen ein bisschen über ihren Werdegang zur Projektmanagerin, den sie als glücklichen Zufall bezeichnet. Wir finden gleich heraus, worin dieser Zufall bestand. Heute nutzt sie ihre Fähigkeiten, um Teams in dieser Agentur nach vorne zu bringen, die viel über Agile sprechen. Darüber möchte ich auch sprechen – aber erst mal hallo, Jenna! Schön, dass du heute da bist.
Jenna Trunzo:
Hallo Ben, vielen Dank für die Einladung und gut gemacht, du hast es richtig ausgesprochen – es heißt tatsächlich Globant.
Ben Aston:
Globant. Weißt du, was Globant bedeutet? Ist das einfach ein Name, so wie global oder Weltweit?
Jenna Trunzo:
Ich würde gern eine coole Geschichte dazu erfinden, aber ehrlich gesagt weiß ich es nicht.
Ben Aston:
Ich habe früher für eine Agentur namens FCV gearbeitet, und alle wollten immer wissen, wofür FCV eigentlich steht.
Jenna Trunzo:
Stimmt.
Ben Aston:
Tatsächlich steht es für nichts. Ursprünglich stand es für False Creek Ventures, aber das klingt erstens nicht gut und zweitens wirklich nicht wie eine Agentur.
Jenna Trunzo:
Stimmt, also hast du dir Geschichten ausgedacht?
Ben Aston:
FCV eben. Leider klingt FCV am Telefon wie alles Mögliche – unter anderem auch wie eine Geschlechtskrankheit.
Jenna Trunzo:
Nicht so toll.
Ben Aston:
Ja, da muss man aufpassen.
Jenna Trunzo:
Absolut.
Ben Aston:
Genug zum Thema Namen. Erzähl uns ein bisschen, was du genau bei Globant machst.
Jenna Trunzo:
Klar. Ich bin Projektmanagerin bei Globant. Wir machen alles – von Datenmigration bis künstliche Intelligenz. Alles projektbasiert und sehr unterschiedlich. Ich habe schon sehr kleine Projekte gemacht, aber auch aktuell bin ich bei einem ziemlich großen dabei. Die Bandbreite ist riesig. Das Unternehmen hat etwa 8.000 Mitarbeiter insgesamt und ich sitze in Raleigh mit ca. 150 Leuten im Büro.
Ben Aston:
Cool. Erzähl uns zuerst ein bisschen deine Geschichte. Du nennst das ja einen glücklichen Zufall. Worin bestand er? Denn du warst ja zuerst Grafikdesignerin, dann Marketingmanagerin, und dann Projektmanagerin. Was war der glückliche Zufall? Berichte mal.
Jenna Trunzo:
Ja. Sicherlich gibt es da draußen einige Kreative – am Anfang wurde viel ausgelagert und es gab nur wenig Jobs. Ich komme ursprünglich aus Pittsburgh, Pennsylvania, und das war meine Branche dort. Es gab einfach nicht viele Stellen. Nach meinem Umzug nach North Carolina arbeitete ich als Marketingmanagerin in einem Immobilienunternehmen und machte das etwa zehn Jahre lang. Das hat mir Spaß gemacht, aber letztlich war es eigentlich Projektmanagement, wir nannten es bloß nicht so.
Ben Aston:
Verstehe.
Jenna Trunzo:
Ich kannte ein paar Leute bei dieser Firma und erzählte ihnen, dass ich in meinem Job nicht mehr so glücklich war. Sie meinten: „Du solltest das Unternehmen echt mal anschauen, wir suchen gerade Projektmanagerinnen. Das klingt sehr nach deiner aktuellen Tätigkeit.“ Ich antwortete: „Oh, ich habe aber keine Erfahrung in der IT-Branche...“ Zuerst habe ich es aufgeschoben, aber irgendwann habe ich mich dann doch beworben – und es ist eine meiner besten Entscheidungen gewesen. Daher: glücklicher Zufall.
Ben Aston:
Super! Du hast ja gesagt, dass du vorher faktisch schon Projektmanagement betrieben hast. Was hast du dann bei Globant in einer großen Agentur entdeckt? Was musstest du anpassen oder ändern an deiner Arbeitsweise?
Jenna Trunzo:
Also auf der ganz grundlegenden Ebene habe ich vorher von zu Hause gearbeitet – remote. Hier gehe ich nun ins Büro, was mir sehr gefällt. Es gibt viele unterschiedliche Prozesse, die ich übernehmen und mit sehr verschiedenen Kundentypen und -anforderungen arbeiten musste. Der Wechsel von Immobilien in die Technologiewelt war schon eine Umstellung – mit vielen neuen Begriffen, Prozessen und Herangehensweisen. Es gab tatsächlich auch viele Gemeinsamkeiten, aber eben auch viele Unterschiede und vieles war komplett neu. Die Umstellung war aber sehr positiv.
Ben Aston:
Ja. Ich habe die Website von Globant angesehen, sie reden viel über Agile Pods. Viele sprechen heute über Agile und probieren verschiedene Implementierungsarten. Pods sind eine Variante, die zu funktionieren scheint. Wie läuft das bei euch? Wie siehst du dein Pod und wie steuerst du es?
Jenna Trunzo:
Auf hoher Ebene arbeitet Globant mit verschiedenen Arten von Pods – zum Beispiel „Build Pod“ oder „Strategy Pod“. Ich glaube, insgesamt gibt es fünf Typen. Für unser Gespräch ist aber wichtig: Ich bin in einem hybriden Pod. Das bedeutet, wir suchen in jedem Projekt die geeigneten Talente für die jeweilige Rolle und bauen so das Pod auf. Es entspricht einem Projektteam, aber wir bewerten ständig unsere Ziele und Verantwortlichkeiten selbst – und entwickeln daraus Methoden und Metriken. Reift das Pod, bilden die leistungsstärksten Mitglieder neue Pods für weitere Projekte und leiten dort an.
Ben Aston:
Okay. Wie viele Leute sind dann insgesamt in eurem Pod?
Jenna Trunzo:
Das variiert stark – zwischen 3 und 20 Mitarbeitende. Auf dem aktuellen Projekt sind wir acht.
Ben Aston:
Ah, okay. Und wie wird das Pod besetzt? Ein neues Projekt kommt rein und wird einem Pod zugewiesen, das dann klären muss, wann es liefert – oder wie funktioniert das?
Jenna Trunzo:
Das Projekt gibt vor, wann und was geliefert wird. Das Pod wird meistens für das jeweilige Projekt gebildet – außer das Team ist so effektiv, dass es direkt von Projekt zu Projekt weiterziehen kann, was aber nicht immer der Fall ist. Im Idealfall bleibt das Team zusammen, bis es reif ist und sich in neue Pods aufteilt. Grundgedanke ist: Die Übergänge erfolgen projektweise.
Ben Aston:
Die Pods entwickeln sich also laufend weiter.
Jenna Trunzo:
Genau.
Ben Aston:
Sehr gut. Du hast von einem Hybrid‑Pod gesprochen. Üblicherweise gibt es im agilen Umfeld oder speziell in Scrum keine Rolle des Projektmanagers.
Jenna Trunzo:
Richtig.
Ben Aston:
Was genau ist dann deine Funktion im Pod?
Jenna Trunzo:
Ich mache doch vieles aus dem klassischen Projektmanagement – Budget, Scope, Liefergegenstände usw. Agile wird oft sehr locker ausgelegt. Im Pod geht es aber vor allem um die Gesundheit des Teams und des Projekts – ich bin für die Aufrechterhaltung des Pods verantwortlich, für die Assessments, Reife und dergleichen.
Ben Aston:
Erzähl mal mehr zu Assessments und Reife: Gibt es da Tests?
Jenna Trunzo:
Nicht wirklich Tests – eher eine kollaborative Runde, bei der wir gemeinsam diskutieren: „Haben wir als Team die Ziele erreicht, die wir uns zu Beginn des Pods gesetzt haben?“ Wir entwickeln als Gruppe eine Art Teamverfassung und etwa alle drei bis sechs Monate prüfen wir: „Halten wir das noch ein? Müssen wir etwas anpassen?“ Ich sollte dazu sagen: Das ist für uns noch relativ neu, da Globant uns erst vor Kurzem übernommen hat. Wir stellen noch um auf deren Arbeitsweise.
Ben Aston:
Dann stehen spannende Zeiten an.
Jenna Trunzo:
Ja.
Ben Aston:
Ich frage immer gern nach Tools – Projektmanagerinnen suchen ja immer spannende neue Tools. Was ist in deinem PM‑Werkzeugkasten, das du sehr magst?
Jenna Trunzo:
Definitiv Advil – Spaß! Ich bin froh, in einem sehr kollaborativen Umfeld zu arbeiten: Meine Kolleginnen sind wirklich mein bestes „Tool“. Ständig beraten wir uns gegenseitig zu Projekten. Aber rein werkzeugtechnisch sind wir ziemlich klassisch: Viel Jira, wir nutzen Confluence, Google Drive ist unser zentrales Hub und dann alles, was die Designer sonst noch brauchen. Die drei sind aber unsere Standards.
Ben Aston:
Die Klassiker.
Jenna Trunzo:
Ja, die Klassiker eben.
Ben Aston:
Okay, sprechen wir über deinen Artikel. Für alle, die ihn noch nicht gelesen haben: Es geht um das zweiwöchige Projekt, das Jenna übernehmen musste. Wie bist du überhaupt an das Projekt gekommen? Denn für viele klingt „Du musst in zwei Wochen liefern“ nach Schock. Wie landete das Projekt bei dir – und hast du es freiwillig übernommen?
Jenna Trunzo:
Sowohl als auch. Ich war verfügbar, weil ein weiteres meiner Projekte gerade beendet war. Wir haben in der Firma eigentlich immer die Wahl, Aufgaben abzulehnen, aber ich mag Projekte mit Kreativität und Herausforderungen. Also dachte ich: In zwei Wochen kann es nicht so schlimm werden.
Ben Aston:
Was sollte schon schiefgehen?
Jenna Trunzo:
Genau. Was sollte in zwei Wochen schon schiefgehen?
Ben Aston:
Warum war der Zeitrahmen auf zwei Wochen beschränkt? Im Artikel erwähnst du geplante Tests. War das ein willkürliches Datum oder wirklich fixiert?
Jenna Trunzo:
Es war absolut fixiert. Das Unternehmen hatte Nutzertests eingeplant und musste fertig werden, um diese stattfinden zu lassen. Sie konnten aus bestimmten Gründen nicht liefern, was geplant war, und brauchten klickbare Prototypen in zwei Wochen – garantiert lieferfähig für die geplanten Tests.
Ben Aston:
Okay. Es ging also in diesen zwei Wochen darum, einen funktionalen Prototypen für die Nutzertests bereitzustellen – und es gab kein Verschieben. Was genau war der Prototyp?
Jenna Trunzo:
Die Firma wollte herausfinden, wie ihre Nutzeroberfläche für Haushaltsgeräte (Appliance) wirkt. Wir sollten die aktuelle Oberfläche einer bestimmten Appliance als Prototyp nachbauen und die Interaktion so realitätsnah wie möglich abbilden. Jeder Prototyp entsprach einem vollständigen Nutzerflow – jeder Knopfdruck leitete einen neuen Schritt ein. Wir mussten sicherstellen, dass die Prototypen genau diesen Ablauf umsetzen.
Ben Aston:
Heißt Appliance hier eine Software – oder war es wirklich ein Gerät wie ein Ofen?
Jenna Trunzo:
Richtig – ein echtes Gerät, z.B. ein Heißluftofen.
Ben Aston:
Also habt ihr im Prinzip grafische Prototypen der Anzeige entwickelt?
Jenna Trunzo:
Genau. Es ging um Buttons und die Anzeige, wie sie sich verändert, abhängig vom Verhalten. Wenn ich zum Beispiel ein bestimmtes Gericht zubereiten will, drücke ich Taste X und die Anzeige zeigt A, B, C, D, E – oder Taste Y, dann passiert etwas anderes. Die Prototypen sollten das abbilden.
Ben Aston:
Wow, UX für den Backofen!
Jenna Trunzo:
Genau.
Ben Aston:
Wie sahen die fertigen Prototypen aus? Waren das klickbare Wireframes?
Jenna Trunzo:
Richtig. Es waren klickbare Wireframes mit etwas mehr Design, wie der Kunde es wollte – mit den echten Schriften, Abständen und visuellen Details wie im echten Gerät. Im Kern aber Wireframes zum Durchklicken.
Ben Aston:
War das in Envision gemacht?
Jenna Trunzo:
Ich glaube ja, das wurde in Envision gebaut.
Ben Aston:
Ihr musstet also nicht bei null anfangen, weil die Geräte-Oberfläche schon da war?
Jenna Trunzo:
Genau, die UI gab es schon.
Ben Aston:
Es ging also darum, verschiedene Nutzerflows in den zwei Wochen anzulegen, damit ihr testen konntet, ob das Bedienkonzept verstanden wird?
Jenna Trunzo:
Ja. Eine der Herausforderungen war, dass wir zu Beginn falsche Design-Spezifikationen vom Kundenteam bekamen – bei nur zwei Wochen Zeit ist das fatal. Wir bauten erst am falschen Prototyp weiter, bis wir das bemerkten.
Ben Aston:
Wann habt ihr den Fehler entdeckt?
Jenna Trunzo:
Ich beschreibe das auch im Artikel: Bei so kurzen Projekten sind tägliche Standups und Demos entscheidend. Wir haben das deshalb gemacht – tägliche Check-ins, oft als Demos. So fiel sehr früh auf, dass wir falsche Infos hatten. Nur dank dieser engen Zusammenarbeit konnten wir das noch rechtzeitig korrigieren.
Ben Aston:
Das Budget und der Zeitplan waren fix – wie sah es mit der Flexibilität im Umfang aus? Habt ihr alles gebaut, was an Flows und Screens geplant war?
Jenna Trunzo:
Kaum Flexibilität, wir sollten sechs Flows und sechs Prototypen bauen. Würde einer fehlen, wäre auch das Nutzererlebnis beim Testen beeinträchtigt – jeder Flow war voneinander abhängig. Der Umfang war also auch fixiert.
Ben Aston:
Also fester Umfang, fester Zeitrahmen.
Jenna Trunzo:
Genau.
Ben Aston:
Wie habt ihr geplant? Ihr musstet sechs Flows in zehn Tagen umsetzen, dabei fiel einer durch die falschen Spezifikationen raus. Wie seid ihr vorgegangen?
Jenna Trunzo:
Soweit das planbar ist, war viel Abstimmung und Kollaboration nötig. Bei so engen Prozessen muss man sich als PM von klassischen Abläufen lösen – es geht um Effizienz aus reiner Notwendigkeit. Zuerst sahen wir uns die Assets und das Ziel an und rechneten danach: Im Schnitt schaffen wir einen Flow in zwei Tagen. Manche waren etwas schneller oder langsamer, aber so teilte sich die Arbeit auf.
Ben Aston:
Wusstet ihr, dass die ersten länger dauern und dann schneller gehen?
Jenna Trunzo:
Ja, wenn die Grundlagen stehen, geht der Rest zügiger. Nach der ersten gefestigten Demo und dem Kundenfeedback konnten wir alles anpassen und das Team wusste, wie wir vorgehen. Wir kannten unsere Geschwindigkeit und die verfügbare Zeit – es blieb ein Risiko, aber das ist eben das Wesen von so kurzen Projekten.
Ben Aston:
Die Entwickler haben das klickbar gemacht – gab es sonst Entwicklung?
Jenna Trunzo:
Die Entwickler haben die Wireframes komplett klickbar erstellt, aber es gab keinen vollen Build.
Ben Aston:
Nach dem ersten Tag habt ihr den Spezifikationsfehler bemerkt – wie habt ihr euren Plan angepasst?
Jenna Trunzo:
Wir hatten ein bisschen Budgetpuffer und konnten einen dritten Entwickler kurzzeitig hinzuziehen. Das ging ohne große Mehrkosten und wir blieben im Zeitplan.
Ben Aston:
Hat euer Plan funktioniert?
Jenna Trunzo:
Ja.
Ben Aston:
Reichte der Plan aus?
Jenna Trunzo:
Der Plan war für die knappen Bedingungen ausreichend und am Ende lief alles korrekt und das Verhältnis mit dem Kunden war sehr gut. Rückblickend hätte ich vielleicht vom Tech Lead genauer wissen wollen, welche Flows aufwändiger sind, aber unser Team Lead hatte das gut im Griff und ich konnte ihm vertrauen. Vertrauen ins Team ist sehr wichtig.
Ben Aston:
Gab es Aspekte, die nicht funktionierten bzw. wo der Plan Probleme machte?
Jenna Trunzo:
Erstaunlich wenig – viele Dinge hätten schiefgehen können, sind aber nicht passiert. Ich würde zukünftig aber den Kunden zu Projektstart stärker in die Pflicht nehmen: Wir dachten, wir hätten alle Infos, aber beim nächsten Mal würde ich alles doppelt und dreifach prüfen lassen. Das hätte uns einen Tag gespart.
Ben Aston:
Was hast du fürs nächste Mal gelernt? Würdest du etwas anders machen?
Jenna Trunzo:
Wir haben vieles gut gemacht, aber man muss auf jeden Fall Kompromisse eingehen. Ich überlege, ob es noch mehr Dinge gab, die ich ändern würde…
Ben Aston:
Gab es Abkürzungen, die ihr versucht habt – und dann doch nachholen musstet, wie etwa kein richtiges Briefing?
Jenna Trunzo:
Wir haben zum Beispiel nicht richtig offiziell gestartet, also keine Rollen klar verteilt. Vielleicht war das nicht zwingend nötig, aber etwas mehr Struktur hätte geholfen – nicht ein offizielles Kickoff, aber wenigstens etwas zur Rollenklarheit.
Ben Aston:
Gerade bei solchen Zeitdruckprojekten zählt jede Minute.
Jenna Trunzo:
Eben.
Ben Aston:
Gerade am ersten Tag braucht das Team Klarheit was Ziele und nächste Schritte angeht, aber eben ohne zu sehr ins Detail zu gehen. Da die richtige Balance zu finden, ist eine Kunst.
Jenna Trunzo:
Und wer was macht.
Ben Aston:
Genau, wer.
Jenna Trunzo:
Ja, exakt.
Ben Aston:
Das kann den Unterschied machen im Projektverlauf – und man sollte nie davon ausgehen, dass das Team alles einfach versteht, nur weil es nicht super kompliziert klingt.
Jenna Trunzo:
Ganz genau. Gerade beim Kunden sollte man vorsichtig sein – sie haben oft nicht dieselbe Vorstellung oder den gleichen Hintergrund. Sie meinen zu wissen, was wir bauen – und beim Review merken sie: Gar nichts verstanden. Ein bisschen mehr Zeit zu Beginn für klare Absprachen hätte uns geholfen.
Ben Aston:
Cool. Jenna, vielen Dank fürs Dabeisein – es war ein spannendes Gespräch!
Jenna Trunzo:
Vielen Dank, hat mir Spaß gemacht.
Ben Aston:
Und an unsere Zuhörer: Hattet ihr schon mal ein Projekt, das in einem verrückten Zeitrahmen umgesetzt werden musste? Wie lief es ab? Erzählt uns eure Erfahrungen – welche Abkürzungen habt ihr genommen und welche gingen schief? Besucht TheDigitalProjectManager.com und kommt in unser Slack-Team! Dort warten viele spannende Diskussionen rund ums digitale Projektmanagement. Wenn euch die Folge gefallen hat, abonniert uns gern und gebt uns eine ehrliche Bewertung – wir lesen alle Rückmeldungen und passen den Podcast entsprechend an. Bis zum nächsten Mal – danke fürs Zuhören!
