Wissensbasis

Projektmanager

Aufgaben-orientierte Wissensbasis für klassische Projektmanager, die digitale Web-Projekte steuern. Zwölf Aufgaben aus dem Alltag — Vorlauf, Briefing, Eskalation, BFSG, DSGVO.

12 Aufgaben + 2 Nachschlagewerke

01 Web endet nicht beim Launch
02 Briefing mit acht Pflichtfeldern füllen
03 Freigabekette beim Kick-off klären
04 Vorläufe mit Datum kommunizieren
05 Kundenwunsch durch Risiko-Filter
06 Kundenfeedback selbst sortieren
07 Tech-Limits mit Optionen erklären
08 BFSG-Pflicht im Projekt verankern
09 DSGVO-Aufgaben klar delegieren
10 Ausschreibungspflicht rechtzeitig prüfen
11 Zuständigkeiten nach Launch sichern
12 3-Indikator-Heuristik anwenden
Briefing-Vorlage
Eskalations-Pfad

Diese Wissensbasis ergänzt die Spielregeln und den Workflow. Awork-Routing, Vorlaufzeiten und Goldene Regeln werden dort behandelt — hier nicht doppelt.

wissenswert

Web endet nicht beim Launch

Wer Web wie Print steuert, plant zu wenig Pflege — und steht vier Wochen nach dem Launch ohne Zuständigkeiten da.

Problem: Print und Events haben einen harten Stichtag und dann ist Schluss. Web hat keinen Schluss — der Launch ist der Anfang. Pflege, Iteration und Monitoring laufen weiter.

Fehlende Pflege-Slots nach Phase 7 bedeuten: tote Links, veraltete Inhalte, Kundenbeschwerden ohne Ansprechpartner.

9 Phasen verinnern

Plane im 9-Phasen-Modell und verstehe: Phase 8 (Pflege) und Phase 9 (Deployment) sind Kernarbeit, kein Anhängsel.
Pflege-Slot reservieren

Reserviere für mindestens 4 Wochen nach Launch einen Pflege-Slot bei Content und Backend — fest im Kalender, nicht "wenn Zeit ist".
Kunden klar kommunizieren

Formuliere explizit: "Online ist nicht fertig." Der Kunde muss wissen, dass nach Launch noch Pflege-Sprechstunden kommen.
Sunset-Plan bei Kampagnensites

Wenn die Site nach einem Datum offline geht: Redirect-Strategie und Archivierung im Briefing aufnehmen.

Beispiel

Service-Hub-Launch

PM setzt "Online" auf den 15.10. und vereinbart 4 Wochen Pflege-Sprechstunde. Content aktualisiert Informationstexte, ergänzt Bilder — sauber dokumentiert, ohne Drama.

Gegenbeispiel

Kampagnen-Relaunch ohne Nachplan

"Am 30.06. live, danach ist gut." Drei Wochen später: Beschwerden über tote Links auf alte Unterseiten. Niemand zuständig, weil "das Projekt ist durch".

Wann NICHT

Bei reinen Microsite-Kampagnen mit klarem Ende (z.B. Messe-Site, geht nach 4 Wochen offline) ist Sunset-Plan Pflicht statt Pflegeplan.

kritisch

Briefing mit acht Pflichtfeldern füllen

"Modernes, frisches Design für unsere Website" produziert 30 Rueckfragen — jeder Tag Rueckfrage ist ein verlorener Tag im Wasserfall.

Problem: Ein unvollständiges Briefing laesst Design, Frontend und Content eigenständig raten — jedes Feld, das fehlt, kommt als Rueckfrage zurück.

Phase 1 startet später, Konzeptionsarbeit wird doppelt gemacht, Vorlauf brennt ohne Output.

Acht Felder ausfüllen

Fuelle alle 8 Pflichtfelder der Briefing-Vorlage (am Seitenende) aus: Ziel, Zielgruppe, Pflichtinhalte, Optionale Inhalte, Tonalität, Vorbilder, Termine, Freigabekette.
Jedes Feld aktiv prüfen

Ist "Ziel" ein konkreter Satz mit Verb und Zielgruppe — oder eine Richtungsangabe wie "modernes Design"? Wenn ja, nochmal nachfragen.
Vor Phase 1 verteilen

Schicke das ausgefüllte Briefing vor Phase 1 an Marc-Andre und Renana — nicht gleichzeitig mit dem Kick-off-Termin.
Kein offenes Feld starten

Ist ein Feld leer oder unklar, hole es vor Phase 1 ein. Ein Briefing mit offenem Feld startet nicht.

Beispiel

Produkt-Landingpage

Briefing vollständig ausgefüllt. Umsetzung in 6 Wochen vom Konzept bis Launch, 2 Korrekturschleifen.

Gegenbeispiel

"Macht mal was dazu"

"Macht mal was zur neuen Dienstleistung — ihr wisst schon." 4 Wochen später steht das Konzept noch nicht, weil keiner sagen kann, ob die Seite informieren oder zur Kontaktaufnahme führen soll.

Wann NICHT

Bei Bug-Tickets (Phase 9, Pflegezeitraum) ist das Voll-Briefing Overkill. Dann reicht: betroffene Seite, Beschreibung, Screenshot, Browser.

Weiter: Briefing-Vorlage

kritisch

Freigabekette beim Kick-off klären

Den echten Entscheider drei Wochen zu spät zu finden kostet mindestens zwei Wochen Projektzeit.

Problem: Du briefst die Pressestelle, freigegeben wird vom Fachbereichsleiter, kassiert wird vom Vorstand — am letzten Tag. Wenn der echte Entscheider nicht im Verteiler war, bricht alles auf.

Konzept oder Design muss nach finaler Freigabe nochmal überarbeitet werden. Vorlauf weg, Nerven auch.

Vier Freigaben benennen

Frage explizit beim Kick-off: "Wer gibt das Konzept frei? Wer das Design? Wer die Texte? Wer den Go-Live?"
Schriftlich bestätigen

Schreibe die vier Namen in die Briefing-Tabelle (Feld "Freigabekette"). Lass dir das schriftlich bestätigen — Mail reicht.
Bei Unklarheit: Workshop

Wenn der Stakeholder-Mix unklar ist: Renana fragt einen Freigabe-Workshop an, in dem das Org-Chart aufgemalt wird.

Beispiel

Portal-Relaunch mit großem Stakeholder-Mix

5 Personen aus dem Fachbereich + 2 aus der Pressestelle — unklar, wer freigibt. Renana terminiert Freigabe-Workshop, Org-Chart steht. Danach: keine Doppel-Rueckmeldungen mehr.

Gegenbeispiel

"Ich gebe das im Team rum"

Drei Wochen später melden sich 4 Personen mit unterschiedlichen Korrekturwünschen. Niemand weiß, wer Vorrang hat.

Wann NICHT

Bei Bestandskunden mit eingespieltem Workflow (gleiche Ansprechpartner seit 2 Jahren) reicht eine kurze Verifikation per Mail. Org-Chart-Workshop nur bei neuen Projekten oder wenn ein Schlüsselkontakt gewechselt hat.

kritisch

Vorläufe mit Datum kommunizieren

Ohne konkrete Zahlen gewinnst du die "Koennt ihr das schnell machen?"-Diskussion nie.

Problem: Kunden denken in "schnell machen" — wir denken in 9 Phasen. Wer keine Zahlen hat, verliert die Diskussion. Wer zu optimistische Zahlen nennt, eskaliert das Projekt.

Zu knappe Vorläufe setzen Phase 7 (Astro zu Fluid) unter Druck — die am häufigsten unterschätzte Phase.

Basiswerte aus Spielregeln

Nimm die Vorlaufzeiten aus den Spielregeln als Ausgangspunkt. Nicht raten, nicht schönen.
Verdoppeln bei Risikofaktoren

Verdoppele den Vorlauf bei: neuem Kunden, mehr als 3 Freigabestufen, parallel laufenden Projekten, Designer- oder Backend-Engpässen.
Datum nennen, nicht Wochen

Kommuniziere immer das konkrete Datum, nicht "in 4 Wochen". Beispiel: "Phase 1 Konzept: bis 19.05., Design-Freigabe: bis 02.06."
Phase 7 nie vergessen

Astro-zu-Fluid-Übernahme kostet 3-4 Tage. Sie wird gerne vergessen, weil sie im Kopf "nach Frontend" kommt und unsichtbar ist.

Beispiel

Konzept-Hub mit 3 Unterseiten

3 Unterseiten: Konzept 3 Tage, Design 3 Tage, Frontend 4 Tage, TYPO3-Übernahme 4 Tage, Pflege 4 Tage, Deploy 3 Tage = ca. 4 Wochen netto plus Freigabe-Wartezeiten.

Gegenbeispiel

"In 2 Wochen schaffen wir das"

Phase 7 (Astro → Fluid-Templates) nicht eingeplant, weil im Kopf "Frontend ist fertig." Launch 10 Tage spät.

Wann NICHT

Bei Notfall-Releases (BFSG-Beschwerdebrief) sind reguläre Vorläufe ausser Kraft. Eskalation an Hendrik, Crash-Plan mit reduziertem Scope.

kritisch

Kundenwunsch durch Risiko-Filter

"Koennt ihr noch einen Konfigurator einbauen?" klingt nach 1 Tag, ist aber 2 Wochen plus Datenschutz-Prüfung.

Problem: "Kann man das schnell machen?" klingt harmlos. Ohne Filter-Prüfung wird daraus ein Ticket — und dann ist es zu spät für ein Change-Request-Gespräch.

Das Team steht Kopf, weil ein Wunsch ohne Prüfung akzeptiert wurde. Zeitplan bricht, Kunde ist trotzdem enttäuscht.

Frage 1: Neue Daten?

Braucht der Wunsch eine neue Datenquelle, eine API, eine Datenbank? Wenn ja: kein normales Ticket.
Frage 2: Rechtliche Pflichten?

Löst er DSGVO-, BFSG- oder Disclaimer-Anforderungen aus? Wenn ja: Change-Request-Gespräch mit Renana.
Frage 3: CMS-Schnittstelle?

Berührt er die Schnittstelle zum CMS (neue Felder, neue Typen)? Wenn ja: Backend-Abschätzung nötig.
Frage 4: Phase abgeschlossen?

Fällt der Wunsch in eine bereits abgeschlossene Phase? Wenn ja: Change-Request-Gespräch mit Aufwandsschätzung durch Marc-Andre.

Beispiel

Standort-Karte 2 Wochen vor Launch

Kunde will interaktive Standort-Karte. Antwort: "Datenquelle, Fallback, Karten-Lizenz, Kontrast-Prüfung nötig. Vorlauf 4-5 Wochen ab Datenfreigabe. Soll Marc-Andre schätzen?"

Gegenbeispiel

"Klar, kriegen wir hin"

Drei Tage später: niemand hat geprüft, ob die Karten-API DSGVO-konform ist. Team steht Kopf.

Wann NICHT

Bei trivialen Anpassungen (Wortlaut, Reihenfolge, Bild-Tausch) sind die 4 Fragen Overkill. Direkt als Pflege-Ticket an Renana.

wichtig

Kundenfeedback selbst sortieren

Eine Excel mit 47 bunt gemischten Punkten 1:1 weiterzuleiten ist keine Projektsteuerung — das Backend lehnt sie dankend ab.

Problem: Du bekommst eine Liste mit 47 Punkten "Anmerkungen zum neuen Layout" — Mischmasch aus Bug, Wunsch, Geschmack, Missverständnis. Wer das unkommentiert weiterleitet, verlagert seine Arbeit auf das Team.

Backend und Design lehnen unsortierte Listen ab. Du sortierst trotzdem — nur eine Woche später und mit mehr Frust.

Fünf Kategorien

Sortiere selbst in: Bug, Feature, Schönheitsfehler, Content, Missverständnis.
Pro Kategorie ein Ticket-Set

Bugs in ein Pflege-Ticket, Features als Change-Request mit Aufwand, Schönheitsfehler in Sammel-Ticket, Content an Kunden-Redaktion, Missverständnisse selbst beantworten.
Missverständnisse selbst klären

Missverständnisse antwortest du per Mail — mit Verweis auf das Konzept. Das Team antwortet nicht für dich.

Beispiel

Produkt-Hub — 38 Punkte

6 Bugs (Pflege-Ticket), 4 Features (Change-Request), 12 Schönheitsfehler (Sammel-Ticket), 11 Content-Änderungen (zurück an Kunden-Redaktion), 5 Missverständnisse (PM antwortet per Mail).

Gegenbeispiel

Excel weiterleiten an Renana

"Bitte umsetzen." Renana lehnt ab — du sortierst trotzdem, nur eine Woche später und mit mehr Frust.

Wann NICHT

Wenn der Kunde bereits sortiert hat (Bug-Liste separat, Feature-Liste separat, Content in Word) — nur stichprobenhaft prüfen, nicht neu sortieren.

Weiter: Spielregeln (Feedback)

wichtig

Tech-Limits mit Optionen erklären

"Das geht nicht" macht uns klein. "Das geht" ohne Prüfung bricht uns später. Der Mittelweg ist ein Optionen-Angebot.

Problem: "Das geht bei uns nicht" ist die schlechteste Antwort. "Das geht" ohne Prüfung die zweitschlechteste — sie bricht später.

Der Kunde fragt sich, warum andere Anbieter das können. Nächstes Projekt geht woanders hin.

Wirkliches Ziel herausfinden

Was wünscht der Kunde wirklich? Nicht "wir wollen ein Karussell", sondern "wir wollen, dass Nutzer 8 Angebote schnell überblicken". Ersteres ist eine Lösung, letzteres das Problem.
Standard-Option benennen

Was geht im Standard, ohne Aufwand, im aktuellen Vorlauf? Das ist Option A.
Voll-Lösung schätzen

Was waere der Aufwand für das, was der Kunde ursprünglich wollte? Marc-Andre oder Dragan schätzen — nicht du alleine.
Kunde wählen lassen

Lass den Kunden zwischen Option A und B wählen, nicht zwischen "Ja" und "Nein".

Beispiel

Standort-Karte mit komplexer Datenquelle

Marc-Andre prüft: Karten-Lizenz teuer, DSGVO komplex. Antwort: "Option A: statische Standort-Liste mit PLZ-Filter (3 Tage). Option B: interaktive Karte, eigene Datenpflege, ca. X Euro/Jahr Lizenz. Was ist euch wichtiger?"

Gegenbeispiel

"Geht so eben nicht"

Ende. Der Kunde fragt sich, warum andere Anbieter das können, und vergibt das nächste Projekt anders.

Wann NICHT

Bei harten technischen Bremsen (TYPO3 ohne kostenpflichtige Extension nicht lösbar) — direkt mit Dragan oder Marc-Andre eskalieren, statt Optionen zu erfinden, die du nicht halten kannst.

kritisch

BFSG-Pflicht im Projekt verankern

Ab 28.06.2025 ist WCAG 2.2 AA für kommerzielle Web-Angebote Gesetz — nicht Empfehlung.

Problem: Online-Formulare, Shop-Strecken und Beratungsportale sind BFSG-relevant. Wenn das Projekt WCAG 2.2 AA nicht erfüllt, ist es ein juristisches Risiko für den Kunden.

2 Wochen vor Launch fällt auf, dass eine zentrale Tabelle nicht tastatur-bedienbar ist. Phase-3-Designs müssen geändert, Phase 7 verschoben werden.

Relevanz im Kick-off klären

Frage explizit: "Ist dieses Projekt BFSG-relevant?" Bei öffentlichen Web-Angeboten, Förder-Formularen, Ticket-Shops: ja.
Briefing-Felder ergänzen

Das Briefing-Feld "Pflichtinhalte" um Barrierefreiheits-Erklärung + Feedback-Mechanismus erweitern.
A11y-Check einplanen

Im Phasen-Workflow den A11y-Check vor Phase 9 einplanen. Wer prüft: Marc-Andre (technisch), Lina (visuell).
Erklärung abstimmen

Barrierefreiheits-Erklärung mit kundenseitiger Pressestelle abstimmen — nicht von uns schreiben, von denen freigeben lassen.

Beispiel

Online-Antragsstrecke mit BFSG-Pflicht

BFSG ab Tag 1 im Briefing. Marc-Andre prüft Kontraste in Phase 3, final in Phase 7. Barrierefreiheits-Erklärung mit Pressestelle abgestimmt — kein Last-Minute-Stress.

Gegenbeispiel

"Das ist doch was für Frontend"

2 Wochen vor Launch: Datentabelle nicht tastatur-bedienbar. Phase-3-Designs müssen geändert werden, Phase 7 verschoben.

Wann NICHT

Reine interne Tools (Mitarbeiter-Intranet, Verband-interne Plattformen) sind teils ausgenommen. Bei Unsicherheit Renana fragen — die holt Klarheit.

Weiter: A11y-Audit · Glossar (WCAG, BFSG)

kritisch

DSGVO-Aufgaben klar delegieren

Cookie-Banner und Datenschutz-Erklärung sind rechtliche Pflichten des Kunden — nicht technische Detail-Themen von uns.

Problem: Wenn du nicht klar trennst, wer was verantwortet, hast du am Ende 3 Wochen Diskussion über Banner-Texte mit der Pressestelle — 4 Tage vor Launch.

Notbremse bei Launch, weil Datenschutzbeauftragter ein nicht in der Erklärung erwahntes Tracking-Tool blockiert.

Aufgaben trennen

Datenschutz-Erklärung schreibt der kundenseitige Datenschutzbeauftragte. Cookie-Banner-Tool waehlst du gemeinsam mit Dragan.
Tracking gegen Erklärung prüfen

Was nicht in der Datenschutz-Erklärung steht, darf nicht laufen. Prüfe Tracking-Setup vor Phase 9.
Datenschutzbeauftragten benennen

Im Briefing explizit fragen: "Welcher Datenschutzbeauftragte ist Ansprechpartner?" Den Namen ins Briefing schreiben.
Früh einbeziehen

Datenschutzbeauftragten nicht erst 4 Tage vor Launch informieren — frühestens bei Tracking-Entscheidung, spätestens in Phase 8.

Beispiel

Antragsstrecke mit Matomo-Tracking

Du klärst mit dem kundenseitigen Datenschutzbeauftragten: Matomo on-premise, keine Drittland-Übermittlung. Banner mit "Statistik-Cookies optional" reicht.

Gegenbeispiel

"Macht ihr das Banner mal"

Kunde will Google Analytics. Banner enthält es nicht. Datenschutzbeauftragter widerspricht 4 Tage vor Launch. Notbremse, Frust.

Wann NICHT

Bei reinen B2B-Plattformen ohne Endkunden-Tracking (Verbands-Mitgliederbereich) ist die Banner-Frage trivial. Trotzdem: einmal mit dem kundenseitigen Datenschutzbeauftragten gegen-prüfen.

wissenswert

Ausschreibungspflicht rechtzeitig prüfen

Wer ein ausschreibungspflichtiges Projekt ohne Vergabe anfängt, riskiert Aufhebung — und unbezahlten Aufwand.

Problem: Oeffentliche Auftraggeber müssen ab bestimmten Schwellen ausschreiben. Wenn ein Projekt anfängt, das eigentlich ausschreibungspflichtig waere, kann der Auftrag aufgehoben werden.

Drei Wochen rein, der Vergabejurist stoppt das Projekt. Aufwand bisher: nicht abrechenbar.

Schwellen kennen

Ab ca. 25.000-50.000 Euro netto (kommunal abhängig) wird Ausschreibung relevant. Ab ca. 215.000 Euro EU-weit. Du bist kein Vergabejurist — du musst nur die Großen kennen.
Beim Kick-off fragen

Frage explizit: "Ist das Projekt ausgeschrieben oder Direktvergabe?" Bei Unsicherheit: Renana → Hendrik.
Vorlauf einplanen

Ausschreibung braucht 3-6 Monate vor Projektstart. Das in den Gesamt-Zeitplan einrechnen.
Fördermittel prüfen

Wenn der private Auftraggeber öffentliche Fördermittel nutzt (Bundesförderung, EFRE) — mit Renana prüfen, ob Vergaberecht trotzdem greift.

Beispiel

Portal-Projekt, ca. 80.000 Euro

Renana prüft: Direktvergabe nicht möglich. Ausschreibung über 4 Monate, dann erst Phase 1.

Gegenbeispiel

"Klärt sich noch"

"Wir starten schon mal, das Vergabe-Thema klärt sich." Drei Wochen rein — Vergabejurist stoppt. Aufwand nicht abrechenbar.

Wann NICHT

Bei privaten Auftraggebern ohne öffentliche Förderbindung reicht eine schriftliche Auftragsbestätigung.

wichtig

Zuständigkeiten nach Launch sichern

"Online" ist nicht "fertig" — wer das Routing nach Launch nicht klärt, hat vier Wochen später ein Ticket-Chaos.

Problem: Pflegezeitraum, Bug-Behebungen, Content-Updates und Monitoring laufen nach Launch weiter. Wenn Zuständigkeiten nicht klar sind, fallen Tickets durch.

2 Monate nach Launch: eine unstrukturierte Mail mit 18 Anmerkungen, alles dringend, nichts sortiert, keine Zuständigkeit.

Pflege-Sprechstunde einplanen

Launch-Tag plus 4 Wochen Pflege-Sprechstunde fest im Kalender — nicht "wenn notig".
Routing nach Launch klären

Bugs → Renana (via Awork). Content-Änderungen → kundenseitige Redaktion (TYPO3-Pflege selbst). Neue Features → Change-Request mit Aufwandsschätzung.
Monitoring delegieren

Monitoring (Erreichbarkeit, Errors) liegt bei Dragan/Klaus, nicht bei dir. Du bist Anlaufstelle für den Kunden, nicht für Server-Lights.
Sunset-Plan bei Kampagnensites

Bei Sites mit klarem Ende: Redirect-Strategie und Archivierungsplan im Briefing aufnehmen, nicht erst am letzten Tag.

Beispiel

Produkt-Hub nach Launch

4 Wochen Pflege-Sprechstunde: 6 Bugs, 12 Content-Updates (Kunde pflegt selbst), 1 Change-Request (Tabellen-Filter). Sauber in Awork.

Gegenbeispiel

Kontakt bricht nach Launch ab

Zwei Monate später: "Hier sind 18 Anmerkungen." Nichts sortiert, alles dringend, Pflege-Sprechstunde war nicht im Kalender.

Wann NICHT

Bei Microsites mit klarem Sunset-Datum entfällt die Pflege-Sprechstunde. Stattdessen: Sunset-Plan als Pflichtfeld im Briefing.

kritisch

3-Indikator-Heuristik anwenden

Du merkst es immer eine Phase zu spät — ausser du prüfst jede Woche dieselben drei Indikatoren.

Problem: Ohne regelmäßige Statusabfrage fällt erst auf, dass Phase 4 überzogen hat, wenn Phase 7 nicht starten kann. Die Kaskade beginnt eine Phase früher.

Hendrik eskaliert mit dem Kunden, du bist nicht im Loop — und hast keine Früherkennung gehabt.

Indikator 1: Zeitverzug

Liegt die aktuelle Phase mehr als 20 % über Plan? Wenn ja: Ampel auf Gelb.
Indikator 2: Kunden-Rueckfragen

Hat der Kunde mehr als 5 offene Rueckfragen, die du nicht innerhalb von 48h beantworten konntest? Wenn ja: Ampel auf Gelb.
Indikator 3: Team-Blockade

Hat das Team in der laufenden Phase eine oder mehr unbeantwortete fachliche Fragen an dich? Wenn ja: Ampel auf Gelb.
2 von 3: Plan B

Wenn 2 von 3 Indikatoren auf Gelb stehen: Marc-Andre und Renana einbeziehen, Plan B aufsetzen. Nicht warten, nicht hoffen.

Beispiel

Buchungs-Page, Woche 4 von 8

Phase 4 läuft 3 Tage hinten (Indikator 1). Du setzt Plan B auf: 2 Detail-Komponenten weglassen, Launch +1 Woche, Kunde am Mittwoch informiert. Hendrik muss nicht ran.

Gegenbeispiel

Hoffnung statt Heuristik

Du hoffst, dass es sich einrenkt. Eine Woche später: Phase 4 noch hinten, Phase 5 gestartet, Backend hat halbfertige Schnittstellen. Hendrik eskaliert.

Wann NICHT

Bei kleinen Pflege-Tickets (1-2 Tage Aufwand) ist die Heuristik Overkill. Da reicht der Awork-Status. Sie greift erst bei Projekten mit Phasen-Workflow ab ca. 3 Wochen Laufzeit.

Briefing-Vorlage

Acht Felder, die in jedes Briefing gehören. Wenn eines fehlt, fragen Devs zurück — und das Projekt verliert Tage.

Pflichtfelder für ein Web-Projekt-Briefing
Feld	Was reinmuss	Beispiel (konkret)
Ziel	Ein Satz, was die Seite bewirken soll.	"Interessenten sollen das passende Angebot in unter 3 Klicks finden."
Zielgruppe	Konkret, nicht "alle Nutzer".	"Geschäftsführer kleiner Unternehmen, 40-60 Jahre, wenig Online-Erfahrung."
Pflichtinhalte	Was MUSS auf die Seite — als Liste.	Leistungs-Übersicht, Preistabelle, PDF-Download, FAQ, Ansprechpartner.
Optionale Inhalte	Was waere "nice to have".	Video-Statement Geschäftsführung, interaktiver Konfigurator.
Tonalität	3 Adjektive + 2 Worte, die NICHT vorkommen sollen.	"Nuechtern, verbindlich, einladend. Nicht: hip, jung, lifestyle."
Vorbilder	2-3 Links zu Seiten als Stilrichtung.	Beispiel-Agentur A, Wettbewerber B, branchenangrenzende Referenz C.
Termine	Konzeptions-Termin, Design-Freigabe, Launch.	Konzept 12.05., Design-Freigabe 02.06., Launch 28.07.
Freigabekette	Wer gibt was frei? Reihenfolge!	Fachbereich → Marketingleitung → Geschäftsführung (Final).

Eskalations-Pfad

Vier Stufen — vom selbst lösen bis zur Geschäftsleitung. Eskaliere früh genug, aber nicht zu früh. Stufe 4 nur über Hendrik.

Eskalations-Stufen im Projekt
Stufe	Wer	Wann	Was
1	Du (PM)	Sofort bei Risiko-Erkennung	Mit Renana sprechen, Plan B vorbereiten, Kunde nicht ohne Plan ansprechen.
2	Marc-Andre (FE/UX-Lead) oder Dragan (BE)	Wenn fachliche Limitierung im Spiel	Aufwand realistisch schätzen, Optionen formulieren, Plan B verproben.
3	Hendrik (Leitung Unit)	Wenn Kundenkommunikation schwierig wird	Eskalations-Gespräch mit Kunden, Scope-Anpassung, ggf. neue Rahmen.
4	Geschäftsleitung	Vertragliche / finanzielle Konsequenzen	Nur über Hendrik — niemals direkt von dir.

Weiter im Material: Spielregeln · 9-Phasen-Workflow · Wer wir sind · A11y-Audit