Transkript:
Wenn du wissen möchtest, welcher Prozess euch dabei hilft, dass euer Relaunch sicherer und reibungsloser ablaufen wird, dann solltest du dieses Video nicht verpassen. Dranbleiben. Hallo und herzlich willkommen. Mein Name ist Andor Palau. Ich bin SEO Consultant für Saas-Unternehmen, Shops, Marktplätze und Publisher. Und in dieser Videoreihe gehe ich immer auf Fragen ein, die mir im Rahmen meiner Beratungstätigkeit typischerweise über den Weg laufen. Und heute sprechen wir über ein zentrales Element für eine erfolgreiche Migrations-Planung und warum es gerade in kritischen Phasen so unverzichtbar ist. Und wir reden über Wenn/Dann-Regeln. Ob ein IT-Projekt allgemein in der Produktentwicklung oder eben für einen Webseiten Relaunch. Ein detaillierter Projektplan mit vorausschauenden Wenn/Dann-Regeln wird immer signifikant zum Erfolg oder beim Fehlen eben auch zum Scheitern eines Projektes beitragen. Und zunächst einmal vielleicht kurz erklärt Was sind denn Wenn/Dann-Regeln in einer Projektplanung. Bei Wenn/Dann-Regeln, oder im Englischen halt auch contingency rules genannt, reden wir über vordefinierte Entscheidungslogiken. Wenn Ergebnis X eintritt, dann wird Maßnahme Y ausgelöst. Annahme, Risiken und Bedingungen, die das Projekt beeinflussen können, sind hier also schon bedacht. Beispiel: Wenn eine Testphase von zwei Wochen nicht gewährleistet ist, dann verschiebt sich der Go-Live Termin um mindestens eine Woche. Oder ein anderes Beispiel: Wenn bis zum Content-Freeze nicht alle Texte auf der Domain migriert sind, dann wird der Go-Live Termin eben um die Zeit verschoben, bis alle Contents überführt sind. Und warum solche Regeln bei einer Migration so wichtig sind, gerade an Meilensteinen, möchte ich gerne mal versuchen, mit drei Gründen zu belegen.
Der erste Grund ist, es existiert eine Klarheit bei Unsicherheit. Projekt Verläufe sind alles andere als linear. Meilensteine, bestimmte Sprint soft Launches, Content-Freezes, finale Abnahmen usw. Wenn/Dann-Regeln schaffen hier ein strukturelles Reaktionsmuster.
Der zweite Grund ist, dass die Entscheidungsfindung entlastet wird und das vor allen Dingen in Stresssituationen, wie eben beispielsweise kurz vor dem Launch, wo oft Zeit und Objektivität fehlt, wo die Emotionen hochkochen, wo vielleicht ein wichtiger Termin ansteht, die Geschäftsführung Druck macht. Wenn die Entscheidungslogiken bereits vordefiniert ist, dann ist das Team schneller und einheitlicher und kann sachlicher reagieren. Und ja, natürlich müssen müssen die handelnden Personen dann eben auch die Verantwortung wahrnehmen, wenn diese Regeln zum Einsatz kommen. Aber das ist eben wie mit allen Verträgen, da sind auch immer etliche Themen wie Kündigung usw. vordefiniert, für den Fall, dass es eben schlecht läuft und damit man dann Klarheit hat. Nichts anderes ist es, mit Wenn/Dann-Regeln, wo klare Entscheidungskompetenzen bei den jeweiligen Personen dann auch liegen müssen.
Der dritte Grund ist dann, es sorgt für Transparenz und das auch bei allen Beteiligten. Alle Stakeholder vom SEO über den Projektleiter bis hin zur IT wissen, was passiert, wenn. Keiner kann sagen: Oh, da haben wir aber noch nie drüber gesprochen. Das fördert in Summe dann das gegenseitige Vertrauen und reduziert interne Diskussionen im Ernstfall. Die nächste Frage ist dann häufig die nach der Risikominimierung durch Wenn/Dann-Regeln. Und hier bemühen wir uns vielleicht einfach mal der Bildersprache. Denn man könnte sagen, dass ein Projektplan für eine Migration ohne Wenn/Dann-Regeln, wie eine Beerdigung ohne Vorsorgeplanung ist. Man muss Entscheidungen treffen, wenn die Emotionen blank liegen. Und da ist die Gefahr viel größer, das was schiefgeht, als wenn man einen vordefinierten Plan hat, den man nur noch ausführen muss.
Und damit wir die Risiken ein bisschen besser einschätzen können, möchte ich im Folgenden mal auf vier Typen eingehen. Das erste wäre das zeitliche Risiko. Wenn bestimmte definierte Zustände zu bestimmten Zeitpunkten nicht vorhanden sind, verlängert sich Projektabschnitt X eben um Y Tage oder es verschiebt sich eben um Y Tage. Das ist sicherlich eines der wichtigsten Risikoszenarien, weil oftmals am Ende eben die Zeit knapp wird. Und das führt dann nicht selten dazu, dass Themen, die eigentlich zu Migration erledigt werden sollten, hintendran gestellt werden oder dass eben mit weniger Sorgfalt und weniger Akkuratesse getestet wird.
Das zweite Risiko wäre ein technisches Risiko. Wenn ein geplantes Deployment beispielsweise irgendwelche Deployment Prozesse fehlschlagen, dann muss klar definiert sein, wie es zu einem Roll Back Verfahren kommt. Das dritte könnten personelle Risiken sein. Also wenn beispielsweise Projektleiter Y ausfällt, dann muss klar sein, dass die gesamte Entscheidungs-Verfügungsmacht auf eine andere Person, auf seinen Stellvertreter beispielsweise, übergeht. Und das vierte wäre ein Risiko, Risiken bei externen Abhängigkeiten. Wenn also beispielsweise Partner X zu dem und dem Tag nicht bestimmte Daten liefern kann, dann muss eben mit einem Dummy Satz gearbeitet werden, damit weitergearbeitet werden kann. Diese Regeln reduzieren in der Regel dann Panikverzögerungen oder Kollateralschäden, weil sie vorbereitete Reaktion auf erwartbare Probleme darstellen.
Kommen wir dann noch einmal kurz zu der Frage, wie man wirksame Wenn/Dann-Regeln, dann in seinen Projektplan erstellt. Hier steht zu Beginn meistens eine Analysephase an. Was könnte alles schiefgehen. Also identifiziert man mögliche Risiken, Annahmen und Schwellenwerte usw. Man könnte auch einen Workshop stattfinden lassen mit allen Beteiligten, um darüber zu sprechen, welche Eventualitäten dieses Projekt nervös machen könnten. Der nächste Schritt wäre dann die Definition konkreter Auslöser und Maßnahmen. Für wenn, gibt es dann immer klar beobachtbare Bedingungen oder Schwellenwerte und für jedes dann, analog Handlungsanweisungen, Eskalationen oder eben ein Plan B. Und der dritte Schritt wäre dann die Verankerung in den Projektplan. Hier sind die Möglichkeiten mannigfaltig. Man könnte die Regeln sichtbar dem Projektplan hinzufügen oder an Meilenstein-Pläne hängen oder eine Risikomatrix erstellen.
Und der vierte Schritt ist dann sicherlich die Kommunikation des Regelsets. Jeder muss wissen, wer bei Eintritt einer bestimmten Bedingung was tun muss. Vermieden werden müssen unklare, schauen wir dann mal Regeln. Und auch wenn ich oben schon zwei, drei Beispiele mal habe anklingen lassen, hier vielleicht noch einmal so ein paar Praxisbeispiele bezüglich einer Webseitenmigration. Wenn die SEO Tests bis Freitag, 20.6. Nicht zu 95 % abgeschlossen sind, dann wird der Launch um eine Woche verschoben. Wenn nicht alle relevanten Stakeholder bis Dienstag EOB ihr Go gegeben haben, wird der Relaunch nicht am Mittwoch stattfinden. Wenn der Launch nicht spätestens an einem Donnerstag stattgefunden hat, wird er auf die kommende Woche verschoben. Sind nicht alle Livegang-relevanten Tickets bis zum Content-Freeze abgearbeitet, verlängert sich der Content-Freeze um mindestens zwei Wochen oder die Zeit, die zur Abarbeitung der Tickets notwendig sind. Wenn ein Testing, ein kritischer Bug, bei beispielsweise mobiler Version, Rendering oder Site Speed gefunden wird, dann wird automatisch ein Hotfix Task ausgelöst, der hohe Priorität hat.
Wenn ein relevanter Stakeholder ausfällt, geht seine komplette Entscheidungsbefugnis über an Person X. Wenn nach dem Go-Live mehr als 30 % der URLs im Crawling unerwartet ein 400 oder 500 Status Code liefern, dann wird sofortiger Rollback Plan der vorherigen Version ausgerollt und der Relaunch pausiert. Wenn die finale Freigabe durch das Legal- oder das Datenschutzteam nicht bis zum Stichtag erfolgt, dann darf maximal ein Soft-Relaunch auf no-index Techbasis durchgeführt werden, dann bis die finale Freigabe erteilt wird. Wenn beim finalen Test mehr als 5 % der URLs nicht eine Weiterleitung haben, dann wird beispielsweise mindestens der Relaunch um drei Tage verschoben, bis alle Redirects getestet werden konnten. Ihr seht also, es gibt eine ganze Menge an Möglichkeiten, wie man wirklich solche Szenarien aufbauen kann und vor allen Dingen, wie dann eben die Aufteilung in den jeweiligen Prozessen ist aber ein detaillierter Projektplan mit klaren Wenn/Dann-Regeln macht Projekte aus meiner Erfahrung heraus einfach resilienter gegen Störungen, handlungsfähiger bei Stress und verlässlicher für alle Beteiligten. In einer Zeit, und das gilt besonders für Migration und Relaunches, in der Kommunikation, Geschwindigkeit und Flexibilität über den Erfolg entscheiden, sind solche Regeln kein bürokratischer Ballast, sondern aus meiner Sicht ein strategischer Erfolgsfaktor. So, das war’s von dieser Folge. Ich hoffe euch gefallen. Wenn ja, dann hinterlasst mir gerne einen Daumen hoch hier. Aktiviert die Glocke, dann verpasst ihr auch nicht das nächste Video. Bei Fragen oder Anregungen gerne unten rein in die Kommentare. Und ansonsten freue ich mich, euch auch bei der nächsten Folge begrüßen zu können. Macht’s gut.