Management eines Portal-Webprojekts (mit Rebecca Germond von FCV Interactive)

Das Transkript lesen:

Wir testen derzeit eine Software zur Transkription unserer Podcasts. Bitte entschuldigen Sie etwaige Tippfehler, da der Bot nicht zu 100 % korrekt ist.

Ben Aston:

Willkommen beim DPM-Podcast, wo wir über die Theorie hinausgehen, um fachkundige PM-Ratschläge für ein besseres Management digitaler Projekte zu geben. Danke fürs Einschalten. Ich bin Ben Aston, Gründer von The Digital Project Manager.

Die Bedürfnisse der Kunden werden immer anspruchsvoller und die Rolle der Digitalagenturen wandelt sich ebenfalls. Da sich der Prozess des Website-Designs und -Baus immer stärker als Standarddienstleistung etabliert hat, wächst der Bedarf an Agenturen, die mehr sind als nur Website-Partner, sondern auch strategische und technische Partner, um nicht nur Websites, Kampagnen und Landingpages zu entwickeln. Im heutigen Podcast werden wir uns intensiv mit Portalprojekten beschäftigen – was sie sind, wie man sie realisiert und wichtige Erkenntnisse, wenn Sie sich auf eines dieser Projekte einlassen möchten. Hören Sie weiter, wenn Sie alle Hintergründe zur Entwicklung von Digitalagenturen und zu produktorientierten Ansätzen in der Kundenberatung erfahren möchten.

Heute habe ich Rebecca Germond zu Gast. Rebecca ist Director of Client Services bei FCV. Sie hat eine fundierte Basis im Projektmanagement und in der Medienkommunikation. Rebecca ist tatsächlich jemand, den ich vor ein paar Jahren eingestellt habe. Ich erinnere mich an dein Vorstellungsgespräch, als ich dich ins Zimmer geholt habe, und ich war direkt überzeugt. Ich weiß nicht mehr genau, was ich dich gefragt habe, aber ich wusste sofort: Dich will ich einstellen. Erinnerst du dich an das Vorstellungsgespräch?

Rebecca Germond:

Ich erinnere mich daran. Ich hatte das Gefühl, ich wurde ganz schön ausgequetscht. Nein, Spaß beiseite, ich kann mich wirklich sehr gut erinnern, auch an die Aussicht aus dem Bürofenster – das war ausschlaggebend für meine Entscheidung, zu FCV zu kommen. Und natürlich unser Gespräch.

Ben Aston:

Es war also nicht ich, sondern der Ausblick.

Rebecca Germond:

Ja.

Ben Aston:

Rebecca, für diejenigen, die sich fragen, was du eigentlich jeden Tag machst – was bedeutet Director of Client Services? Ist das Projektmanagement? Ist das Account Management? Was heißt das für dich aktuell?

Rebecca Germond:

Es ist ein bisschen von beidem, plus das Management des eigentlichen PM-Teams, was ziemlich cool ist. Die Position ist für mich neu im letzten Jahr. Ich bin nicht mehr so tief in den Projekten wie früher, behalte aber trotzdem ein paar, die ich nicht loslassen will. Vor allem arbeite ich direkt mit den PMs, unterstütze sie, damit sie liefern können, und gebe ihnen die nötige Rückendeckung. Außerdem manage ich die meisten unserer Kunden und habe dadurch auch eine recht enge Beziehung mit ihnen. Eigentlich habe ich mal im Account Management angefangen, bevor ich Producer beziehungsweise Projektmanagerin wurde – also ein kleiner Rückschritt zu meinen Wurzeln, was auch ganz cool ist.

Ben Aston:

Schön. Für alle, die sich für diese Rolle des Teamleiters Projektmanagement interessieren: Wie sieht der Alltag aus? Wie steuerst du das Team? Schließlich kannst du nicht in jedem Detail aller Projekte gleichzeitig stecken. Was machst du konkret beim Check-in?

Rebecca Germond:

Das ist eine gute Frage. Größtenteils überprüfe ich Arbeitsergebnisse oder Deliverables, die die PMs verschicken möchten. Zum Beispiel gebe ich Feedback zu einem SoW oder einem Zeitplan. Bei Eskalationen bin ich involviert oder helfe den PMs, auf schwierige Situationen zu reagieren. Ich treffe mich wöchentlich einzeln mit jedem, bin aber auch laufend über Slack in Kontakt, sodass sich alle täglich unterstützt fühlen. Gelegentlich begleite ich auch wichtige Kundentermine. Das ist letztlich ein bisschen von allem.

Außerdem bin ich bei FCV stark in die Geschäftsentwicklung eingebunden. Im Tagesgeschäft befasse ich mich damit, was wir den Kunden tatsächlich fakturieren und ob wir unser Change Management im Griff haben. Es gibt da viele kleine Dinge, die täglich mit dem PM-Team zu tun haben.

Ben Aston:

Erzähl uns ein bisschen deine Geschichte. Dein Werdegang begann im Account Management. Ich weiß, dass du in deiner Karriere im Arbeitsministerium angefangen hast. Wie bist du vom Arbeitsministerium zur Digitalagentur, ins Account und Projektmanagement gekommen? Wie sah dein Weg aus?

Rebecca Germond:

Ganz klar: Während meines Studiums hatte meine Tante eine Zeitarbeitsfirma, die mir Jobs vermittelte, bis ich die richtige Stelle gefunden hatte. Ich wollte unbedingt in einer Agentur arbeiten, habe dann aber eine Stelle im Arbeitsministerium bekommen – eigentlich eine administrative Stelle im öffentlichen Dienst, was aber sehr interessant war. Ich habe viel über die Abläufe der Regierung gelernt, was mir später in meiner Karriere geholfen hat, weil viele Projekte, die ich in meiner ersten Agentur und auch jetzt bei FCV betreue, einen Bezug zur öffentlichen Hand haben. Es war also hilfreich.

Einmal wurde ich über meine Tante bei einer Agentur in Toronto eingesetzt, Manifest Communications. Eigentlich sollte ich dort nur für zwei Wochen als Urlaubsvertretung am Empfang arbeiten, aber dann fragten sie, ob ich als Praktikantin bleiben möchte, was genau mein Ziel war. Nach drei Monaten wurde ich fest angestellt und arbeitete dort vier Jahre lang. Zu Beginn war ich im Account Management tätig, also mehr im Kundenkontakt, weniger im digitalen Projektmanagement. Wir bewegten uns aber immer mehr in diese Richtung. Nach einem Jahr wurde ich Producer, etwa 60 % digital, aber ich durfte auch Radio-, Broadcast- und Printprojekte machen, was ziemlich cool war.

Ben Aston:

Schön. Wir sind noch im ersten Quartal des Jahres. Was sind deine persönlichen Ziele für dieses Jahr, sei es Karriere oder persönliche Entwicklung? Heute sprechen wir ja über Portale und deren Weiterentwicklung, aber hast du für dich Ziele gesteckt?

Rebecca Germond:

Ehrlich gesagt – ich möchte dieses Jahr gar keine speziellen Karriereziel haben. Klingt vielleicht komisch, aber ich bin in meinem letzten Jahr meiner 20er, also möchte ich einfach ein bisschen mehr im Hier und Jetzt leben wie ein typischer Millennial. Ich habe einiges an Reisezielen vor mir. Was den Beruf betrifft, hat mir das Portalprojekt sehr viel Spaß gemacht. Wir haben daraus ein richtiges Produkt entwickelt und machen laufend Releases, sodass stetige Verbesserungen stattfinden. Das gefällt mir richtig gut und ich würde gerne mehr in diese Richtung machen.

Ben Aston:

Sehr gut. Wir haben darüber gesprochen, was du machst, aber was sind aktuell deine größten Herausforderungen oder Kopfschmerzen im Alltag, sei es bei bestimmten Projekten oder auf täglicher Ebene?

Rebecca Germond:

Im Alltag geht es für mich oft darum, ein Projektteam zu „hüten“, wenn du weißt, was ich meine. Projektmanager müssen mit vielen Egos oder verschiedenen Persönlichkeitstypen umgehen. Jetzt, wo ich weniger einzelne Projekte betreue, hat plötzlich jeder im Unternehmen unterschiedliche Bedürfnisse und Prioritäten. Das unter einen Hut zu bringen und trotzdem sicherzustellen, dass die PMs alles bekommen, was sie brauchen – das ist gar nicht so einfach. Außerdem kommen immer wieder Dinge hinzu, die man gar nicht für so wichtig hält, wie administrative Aufgaben. Mein eigener To-Do-Listen-Marathon ist im Moment wirklich eine Herausforderung.

Ben Aston:

Wie behältst du den Überblick? Was ist mit deiner To-Do-Liste? Hast du ein System?

Rebecca Germond:

Das meiste mache ich in Evernote, aber wir haben vor Kurzem eine Slack-Integration namens Workast eingeführt. Damit kann man seine To-Do-Liste direkt in einem Slack-Channel verwalten und Aufgaben dort zuweisen. Du kannst dir in Slack auch einfach eine Notiz an dich selbst schreiben – deine To-Do-Liste ist dann immer präsent und du bekommst Erinnerung, wenn etwas fällig ist. Wir sind noch am Anfang, aber bisher gefällt es mir ganz gut.

Ben Aston:

Das nennt sich Workast?

Rebecca Germond:

Workast, W-O-R-K-A-S-T.

Ben Aston:

Workast, okay. Lustiger Name.

Rebecca Germond:

Definitiv. Bisher läuft es gut. Das Problem ist nur, man kommt meist erst vor 9:00 Uhr morgens oder nach 17:00 Uhr zu seiner To-Do-Liste. So fühlt es sich an, weil 70 % meines Tages entweder aus Meetings oder E-Mails und Slack bestehen – das macht es schwer, produktiv zu sein.

Ben Aston:

Was ist sonst noch in deinem PM-Toolkit? Deine To-Do-Liste hilft dir beim Priorisieren der wichtigsten Sachen. Aber welche Tools nutzt du noch für das Projektmanagement?

Rebecca Germond:

Ich habe so einige Tools. In den letzten Jahren haben wir viel ausprobiert und gewechselt, aber jetzt bin ich recht zufrieden. Wie gesagt, ich nutze Evernote. Wir verwenden mittlerweile sehr konsequent Jira – alle, auch unser UX- und Design-Team und unsere Kunden, sind auf Jira, wodurch alles an einem Ort ist und wir Tickets gut verfolgen können. Slack nutze ich ziemlich intensiv.

Microsoft Teams testen wir als Ersatz für Skype for Business, allerdings hauptsächlich als Konferenzleitung für Meetings mit Kunden. Das klappt bislang gut. Für die Projektplanung nutze ich Merlin. Früher haben wir MS Project genutzt, aber da haben wir vielleicht nur 15% der Funktionen gebraucht; deshalb haben wir MS Project-Lizenzen nur noch für Kunden, die sie wollen. Spotify gehört definitiv zu meinem Toolkit – das brauche ich einfach. Und natürlich Outlook, auch wenn E-Mails mir eher ein Dorn im Auge sind.

Ben Aston:

Abgesehen von Workast, gibt es noch andere Tools, die bei dir zuletzt neue Maßstäbe gesetzt haben oder das PM grundlegend verändert haben?

Rebecca Germond:

Nicht wirklich. Am meisten hat uns wahrscheinlich die Jira-Integration in unseren Slack-Channel weitergebracht. Wenn zum Beispiel ein Ticket aktualisiert oder der Status geändert wird oder ein Kunde kommentiert – Jira schickt ja ohnehin 40 E-Mails pro Minute – werden nur die wichtigsten Infos an unseren Slack-Channel weitergeleitet. Das macht es wirklich einfach, weil keiner Jira-E-Mails liest. MS Teams finde ich auch ziemlich cool, vor allem weil viele Kunden inzwischen Videokonferenzen statt Telefon wollen.

Ben Aston:

Sehr schön. Lass uns über deinen Beitrag, deine Fallstudie sprechen – die erste, die du jemals veröffentlicht hast. Glückwunsch, Rebecca.

Rebecca Germond:

Danke.

Ben Aston:

Sprechen wir über Portale. Ist ein Portal einfach nur eine Website, oder doch etwas anderes? Und wenn ja, warum ist es anders?

Rebecca Germond:

Für mich sind Portale relativ komplex, weil sie in der Regel auf verschiedene Benutzergruppen zugeschnitten sind, die alle eigene Anforderungen, Features oder Journeys haben. Bei diesem Portal gab es zum Beispiel drei verschiedene Benutzerrollen, die sich gegenseitig beeinflusst haben – das haben wir anfangs unterschätzt. Allgemein werden Portale aufgrund dieser vielen verschiedenen Anforderungen ziemlich komplex, anders als normale Websites, auf denen man einfach die Startseite anschaut.

Ben Aston:

Was wir also meinen, ist eine Umgebung mit viel mehr Interaktivität, in der funktionsbasierte Rollen aktiviert oder deaktiviert werden, je nachdem, was man im Portal tut.

Rebecca Germond:

Genau. Speziell bei unserem Portal bekommt man ohne Login quasi nichts zu sehen. Es gibt Hürden und onboarding ist nicht so einfach wie bei normalen Websites. Da gilt es viel mehr zu beachten, was man sonst auf einer Standardseite nicht hätte.

Ben Aston:

Klingt spannend. Bitte gib uns einen kurzen Überblick über die wichtigsten Funktionen des Portals.

Rebecca Germond:

Gerne. Unser Kunde ist ein Elektronikhändler mit B2B-Kunden, die in großen Mengen bestellen. Vor dem Portal lief die Bestellung telefonisch über einen Account Manager – alles sehr manuell, was bei allen für Frust sorgte. Die Kunden wollten keine Anrufe mehr machen. Gewünscht war ein Portal, in dem sie sich einloggen, einen individualisierten Produktkatalog sehen und nur daraus einkaufen können. Darüber hinaus gibt es ein komplexes Rabattsystem, damit die Kunden exklusive Mengenrabatte bekommen, die sie sonst nicht (wie bei Endkundenwebsites) erhalten würden. Das ist ein Aspekt.

Außerdem gibt es einen Checkout-Prozess und ein Dashboard, in dem die Kunden ihre meistbestellten Produkte sowie offene und kürzlich getätigte Bestellungen (innerhalb der letzten 30 Tage) einsehen können. Es gibt nützliche Werkzeuge, mit denen sie im Portal den Überblick behalten.

Außerdem existieren verschiedene Benutzerrollen. Die meisten Kunden können Bestellungen aufgeben, doch bei bestimmten Organisationen muss ein Kunden-Admin die Bestellung erst genehmigen, bevor sie ausgelöst wird. Wenn dabei das Budget überschritten würde, müssen sie ablehnen. Es gibt also viele Details, die es zu berücksichtigen gilt.

Ben Aston:

Das heißt, ein großer Kunde – sagen wir Telus – möchte 2.000 Monitore bestellen: Man loggt sich ein, bestellt, durchläuft die Freigabe, dann kann man die Bestellung nachverfolgen?

Rebecca Germond:

Ja, genau.

Ben Aston:

Das ist E-Commerce im großen Stil.

Rebecca Germond:

Genau.

Ben Aston:

Du hast im Beitrag erwähnt, dass ihr auch spannende Technologien verwendet habt. Kannst du uns einen kurzen Abriss zur technischen Umsetzung und Architektur geben?

Rebecca Germond:

Gerne. Unsere Entwickler können das besser beschreiben, aber ich kann einen groben Überblick geben.

Ben Aston:

Aus Sicht des Projektmanagements also.

Rebecca Germond:

Genau. Wir nutzen .NET Core für die Microservices und React für das Frontend. Das heißt, die Microservices stellen Endpunkte bereit, die beliebig genutzt werden können. Zum Beispiel lassen sich mit einem Endpunkt Bestellmengen abrufen, die wir entweder direkt auf dem Dashboard anzeigen oder unterschiedlich verarbeiten können. React ist für unsere Frontend-Entwickler sehr attraktiv. Mit React haben wir eine Komponentenbibliothek aufgebaut, sodass wiederkehrende Elemente nicht immer neu entwickelt werden müssen. Außerdem sorgt das für einheitliches Design, das zur Marke des Kunden passt und nicht zu sehr von der Endkundenseite abweicht.

Ben Aston:

Es gibt also kein CMS? Wie läuft die Pflege von Produkten?

Rebecca Germond:

Nein, das Schöne ist: Alle Produktdaten werden über eine vom Kunden bereitgestellte API importiert, so wie beim Endkunden-Webshop. Preis-, Produkt- und Spezifikationsdaten sind dadurch stets aktuell – ein Skript läuft täglich, um alles up to date zu halten. Das Hinzufügen neuer Produkte geschieht also komplett automatisiert.

Ben Aston:

Das ist richtig cool. Wie habt ihr das Projekt geplant – was war euer Ansatz für die Entwicklung?

Rebecca Germond:

Wir sind mit einer MVP-Strategie gestartet. Das funktioniert mal besser, mal schlechter, denn je länger das Projekt dauerte, desto größer wurde das MVP. Am Anfang hat uns dieser Ansatz aber enorm geholfen. Wir hatten einen sehr klaren Backlog und starteten direkt mit Entwicklungssprints – eine ausgedehnte Anforderungsdefinition haben wir uns gespart. Wir haben jeweils im Sprint Planning die Features besprochen und entschieden, welche das jeweilige Sprint-Ziel werden.

Ben Aston:

Gab es Budget und Deadline fürs MVP? Wie habt ihr abgegrenzt, was ins Budget passt?

Rebecca Germond:

Ja, das war tatsächlich eine Herausforderung. Im Agenturumfeld ist echtes Agile schwierig, weil Kunden einen Festpreis erwarten, aber ein agiles Modell auf Kosten pro Sprint basiert – nach einem Sprint ist eine Funktion manchmal noch gar nicht fertig. Daher mussten wir preislich – la carte – nach Funktion vorgehen, damit der Kunde nach Priorität entscheiden konnte. Manche Features waren voneinander abhängig. Als wir genau wussten, was Teil des MVP ist, konnten wir das Budget festlegen. Wir hatten einen Zeitrahmen von fünf Monaten plus einen Monat UAT. Es gab ca. sechs bis sieben Sprints einschließlich Setup-Phase.

Ben Aston:

Du hast erwähnt, dass ihr einige Pflichtfunktionen massiv unterschätzt habt. Woran lag das?

Rebecca Germond:

Am meisten unterschätzt haben wir das Katalog-Building und die Rabatte darauf. „Einfach Rabatt auf ein Produkt geben“ war dann doch sehr komplex, weil es viele Kategorien und Merkmale im Produktsortiment gibt. Die Logik plus Rabatt wurde richtig kompliziert. Manche Produkte, wie Apple, sollten ausgenommen werden. Also musste ausgeschlossen werden, diese zu rabattieren. Am Ende wurde es unübersichtlich.

Das Ganze war ein Festpreis-Projekt. Zeitverluste haben wir teilweise durch Change Requests wieder aufgeholt – entweder durch ganz neue Anforderungen oder reine Änderungen an la carte Features. Die Change-Management-Prozesse mussten wir also sehr konsequent betreuen. Bei eigenen Schätzfehlern ist es aber schwierig, das dem Kunden zu erklären.

Ben Aston:

Vieles lag auch daran, dass die Anforderungen (besonders beim Rabatt-System) zu Projektbeginn gar nicht so klar waren, oder?

Rebecca Germond:

Genau. Bei der initialen Anforderungsaufnahme war der Rabattmechanismus viel simpler geplant. Erst im Laufe der Umsetzung wurde es deutlich komplexer.

Ben Aston:

Das ist ja typisch für agile Projekte – dafür sind sie gemacht, aber das Kostenmodell muss stimmen. Ihr habt nun ein Festpreismodell. Was würdet ihr beim nächsten Mal anders planen?

Rebecca Germond:

Mit den Anforderungen, die wir hatten, haben wir es gut gemacht. Zukünftig würden wir dem Kunden eher eine Kostenspanne geben und dann je Sprint genauer kalkulieren, wie viel Teamkapazität gebraucht wird. Ich mochte, wie schlank unser Team war. Es wurde auch vereinfacht, weil nur ein wesentlicher Stakeholder beim Kunden involviert war – je größer der Kundenkreis, desto schwieriger. Das war ein Vorteil bei diesem Projekt.

Ben Aston:

Ihr hattet also ein kleines Team und eine hybride agile Herangehensweise. Wie war die konkrete Teamaufstellung?

Rebecca Germond:

Das ist in Agenturen generell schwierig, auf echtes Agile zu gehen, weil Kunden nicht für ein festes Team über Monate bezahlen wollen. Im Inhouse-Bereich mit festen Ressourcen geht das besser. In unserer Teamstruktur arbeiteten zwei Backend-Entwickler, zwei Frontend, eine halbe Stelle UX, ein Designer, der stichprobenartig dazu kam, und einer in der Qualitätssicherung, meist auch mit 50 %. Ein/e Business Analyst/in kam nicht zum Einsatz. Das war in Ordnung, da die Anforderungen klar waren und wir die kundenspezifische API selbst erarbeiten mussten. Auch ein Stratege war nicht nötig, denn der Kunde hatte eine präzise Vision vom MVP und eine klare Produktidee. Ich war natürlich auch dabei.

Wir hatten noch keine bestehenden Komponenten, also arbeiteten Design und UX jeweils einen Sprint vor der Entwicklung, um früh ein Gefühl für Look & Feel zu vermitteln. Typisch für agiles Arbeiten ist das eigentlich nicht, aber in diesem Fall war es sinnvoll, weil der Kunde visuell überzeugt werden musste. Der erste Sprint wurde für Design, UX und den Aufbau der Systemumgebung genutzt. Der Kunde war für agile Arbeitsweisen offen, was für die Zusammenarbeit sehr vorteilhaft war. Die Abstimmungsprozesse – Scrums, Sprint Reviews, Demos, Retrospektiven – wurden ernst genommen und der Kunde nahm an so gut wie allem teil.

Ben Aston:

Erzähl uns zum Kunden: Es gab einen einzigen Stakeholder, der auch als Product Owner agierte. Trotzdem kamen oft neue Features hinzu. Wie habt ihr das unter einem fixen Budget und einem agilen Ansatz gehandhabt?

Rebecca Germond:

Das war schwierig. Jeder neue Feature-Wunsch war ein Change Request, den wir als Zusatz kalkulierten. Das brachte mit sich, dass die Arbeit im Sprint für eine Schätzung kurz unterbrochen werden musste, was interessant war. Der Kunde war aber voll ermächtigt und handelte als Product Owner und wir konnten ihm direkt Feedback zu möglichen Features geben, was ihm und uns half.

So kamen mittendrin Features dazu, die sinnvoll waren. Zum Beispiel wollte man zunächst neue Kunden weiter manuell onboarden. Nach dem dritten Sprint haben wir dann gemeinsam einen Onboarding-Wizard (Assistenten) entwickelt, mit dem User sich selbst aktivieren, Passwörter setzen, Formulare herunterladen und hochladen konnten. Das hat den Prozess vereinfacht, war aber am Anfang nicht vorgesehen.

Ben Aston:

Zu den Lessons Learned: Ein Punkt war, das Team und den Kunden zu engagieren und einzubinden. Wie stellt man das in der Praxis am besten sicher?

Rebecca Germond:

Für uns war das ein neuer Arbeitsstil – viele unserer Kunden sind Legacy oder öffentliche Einrichtungen mit jahrelanger Zusammenarbeit und eingefahrenen Prozessen. Die hohe Einbindung des Kunden hat sich voll ausgezahlt, weil er damit sehr zufrieden war. Außerdem wollten wir ihn für eine Phase 2 des Projekts begeistern und aufzeigen, dass das Portal ein lebendiges Produkt ist. Die Entwickler waren begeistert, weil sie ihre Technik und Tools selbst wählen konnten, und schätzten die direkte Kommunikation in Slack sehr. Die Kombination aus neuer Technologie, Eigenverantwortung und direkter Rückkopplung machte das Projekt für alle attraktiv.

Ben Aston:

Ein weiteres Learning war das bewusste Ablegen unnötiger Prozesse und das Beibehalten relevanter Methoden. Gibt es Beispiele dafür bei euch?

Rebecca Germond:

Ja, nach dem zweiten Sprint-Retrospektive haben wir diese abgeschafft – wir wussten, was lief und was nicht und wollten keine Entwicklerzeit damit binden. Weil der Kunde so stark beteiligt war, bekamen wir direkt Feedback und konnten Prozesse laufend anpassen. Auch klassische tägliche Scrums waren schwer umzusetzen, denn das Team war auf Toronto und Vancouver verteilt. Daher setzten wir statt fester Termine eher Ad-hoc-Scrums an – ein 15-minütiges Meeting statt eine einstündige Slack-Diskussion.

Ben Aston:

Die Scrums waren also nicht täglich um 9:00 Uhr, sondern spontan?

Rebecca Germond:

Genau, um 9:30 haben wir es versucht. Später dann nach Bedarf oder als Slack-Austausch. Drei Sprints lang waren sie täglich, dann seltener oder via Slack.

Ben Aston:

Gab es Prozesse, die ihr abgeschafft, aber dann wieder eingeführt habt?

Rebecca Germond:

Nicht wirklich, aber wir hätten den QA-Prozess gerne schneller etabliert. Erst ab dem dritten Sprint gab es relevante Artefakte, die getestet werden konnten. Da waren wir manchmal Cowboy-mäßig unterwegs, schoben bis zur letzten Minute Features live und hofften, dass alles klappt. Es war wild, aber auch spannend.

Ben Aston:

Vielen Dank, Rebecca. Es war toll, dass du dabei warst.

Rebecca Germond:

Danke, immer wieder gern.

Ben Aston:

Zuletzt: Wenn Sie sich für Portalprojekte interessieren, lesen Sie unbedingt die von Rebecca verfasste Fallstudie. Dort gibt es viele nützliche Informationen. Weitere Diskussionen rund um Portalprojekte finden Sie auch im Slack-Team der Community. Gehen Sie auf digitalprojectmanager.com/slack, wo zahlreiche spannende Diskussionen rund um digitales PM stattfinden. Wenn Ihnen die heutige Folge gefallen hat, bewerten und rezensieren Sie uns gern bei Apple Podcasts. Bis zum nächsten Mal, danke fürs Zuhören!