Projektmanagement Prompts

Erstellen Sie den Projektauftrag (Scope Statement) für das Projekt [Name des Projekts] bei [Unternehmen]. Projektziel: [Ziel]. Auftraggeber: [Auftraggeber]. Team: [Zusammensetzung]. Budget: [Budget]. Zieltermin: [Frist]. Auslöser des Projekts: [Kontext].

Struktur: Kontext und Problemstellung (3 Zeilen), messbar formuliertes Ziel, eingeschlossener Umfang (Scope), explizit AUSGESCHLOSSENER Umfang (ebenso detailliert wie der Einschluss, um Scope Creep zu vermeiden), Deliverables mit Abnahmekriterien, datierte Meilensteine, Rollen und Verantwortlichkeiten (wer entscheidet, wer führt aus, wer wird konsultiert, wer wird informiert), identifizierte Risiken mit entsprechenden Gegenmaßnahmen ([bereits vermutete Risiken]), Annahmen und Abhängigkeiten.

Formulieren Sie jeden Abschnitt so, dass eventuelle Unstimmigkeiten JETZT bei der Durchsicht auffallen und nicht erst mitten im Projekt. Schließen Sie mit den 3 kritischen Fragen ab, die vor dem Start im Lenkungsausschuss geklärt werden müssen.

Transformieren Sie meine rohen Besprechungsnotizen in ein strukturiertes Ergebnisprotokoll. Meeting: [Gegenstand der Besprechung] vom [Datum], Teilnehmer: [Teilnehmer]. Hier sind meine Notizen: [rohe Notizen, auch ungeordnet].

Ausgabeformat: Getroffene Entscheidungen (eindeutig formuliert, inklusive Entscheidungsträger), Aufgaben (Tabelle: Aufgabe, Verantwortlicher, Frist; falls eine Angabe in meinen Notizen fehlt, markieren Sie diese mit „ZU KLÄREN“ statt zu improvisieren), diskutierte Punkte ohne Entscheidung (max. 2 Zeilen pro Punkt), vertagte Punkte mit Datum der nächsten Besprechung.

Regeln: Maximal eine Seite, keine Umformulierungen, die den Sinn des Gesagten verändern, keine diplomatischen Floskeln, die Entscheidungen verwässern (Formulierungen wie „man kam überein, das Thema weiter zu verfolgen“ sind untersagt). Schließen Sie mit der Liste der „ZU KLÄREN“-Punkte ab, die zur Validierung an die Teilnehmer gesendet werden.

Unterteilen Sie das folgende Projekt in Arbeitspakete und erstellen Sie den Zeitplan. Projekt: [Projektbeschreibung und Endprodukt]. Frist: [Datum]. Verfügbares Team: [Personen und Verfügbarkeit, z. B. 2 Personen in Teilzeit]. Bekannte Einschränkungen: [Einschränkungen: Kundenabnahme, Lieferantenabhängigkeit, Urlaubszeiten].

Gehen Sie wie folgt vor: Unterteilung in Arbeitspakete, die jeweils ein überprüfbares Ergebnis liefern (kein Paket „Koordination“), Zerlegung jedes Pakets in Aufgaben von 0,5 bis 3 Tagen, Identifikation der Abhängigkeiten und des kritischen Pfads, Einplanung expliziter Puffer für unsichere Aufgaben statt versteckter Puffer überall.

Liefern Sie: Die strukturierte Liste Arbeitspakete → Aufgaben mit Schätzungen, den Wochenplan mit Validierungsmeilensteinen, den hervorgehobenen kritischen Pfad und die 3 Aufgaben, die sofort gestartet werden müssen, da sie den Rest bedingen. Weisen Sie darauf hin, wenn die Frist [Datum] mit dem beschriebenen Team nicht haltbar ist (mit Zahlen belegt), anstatt Schätzungen stillschweigend zu komprimieren.

Erstellen Sie den wöchentlichen Statusbericht für das Projekt [Projektname] an [Empfänger, z. B. Lenkungsausschuss]. Daten der Woche: Fortschritt [Ist vs. Soll], Schwierigkeiten [aufgetretene Probleme], sich entwickelnde Risiken [Risiken], verbrauchtes Budget [Ist vs. Plan], erwartete Entscheidungen [blockierende Entscheidungen in Wartestellung und seit wann].

Striktes einseitiges Format: Projekt-Ampel (Grün/Gelb/Rot) mit EINEM Satz, der die Farbe rechtfertigt, 3 Highlights der Woche, Fortschritt vs. Plan (eine Zeile pro aktivem Arbeitspaket), Risiken und kritische Punkte (nur Änderungen zur Vorwoche), erwartete Entscheidungen mit Name des Entscheiders und Auswirkung bei Verzögerung, Prioritäten der nächsten Woche.

Regeln: Ein Projekt springt nie auf Grün zurück, ohne zu erklären, wodurch das Problem gelöst wurde; ein gelber Status in zwei aufeinanderfolgenden Wochen wird automatisch Rot; bei ausstehenden Entscheidungen wird das Datum der ursprünglichen Anfrage genannt.

Bereiten Sie die Moderation einer Retrospektive für das Projekt [Projektname] vor, das gerade abgeschlossen wurde [Ausgang: termingerecht, verspätet um X, abgebrochen]. Teilnehmer: [Teilnehmer und Rollen]. Dauer: [Dauer, z. B. 90 Min.]. Highlights des Projekts: [was gut oder schlecht lief, eventuelle Spannungen].

Liefern Sie: Den zeitlichen Ablauf (Eröffnung mit der Regel „wir suchen Ursachen, keine Schuldigen“, Einzelabfrage vor der Gruppendiskussion zur Vermeidung von Gruppenzwang, Diskussion der Hauptpunkte, Beschlüsse), die exakten Fragen, um über Allgemeinplätze hinauszugehen („Zu welchem Zeitpunkt wussten wir genau, dass der Termin rutscht? Was hat uns gehindert, es auszusprechen?“), und die Technik, um über [eventuelles sensibles Thema] zu sprechen, ohne dass es in gegenseitige Zuweisungen ausartet.

Ausgabeformat der Erkenntnisse: Jede Lektion wird zu einer umsetzbaren Regel für das nächste Projekt („Ab jetzt werden wir...“), mit einem Verantwortlichen für die Umsetzung. Maximal 5 Regeln: Mehr wird in der Praxis nicht angewendet.

Sie sind ein erfahrener Projektleiter. Helfen Sie mir, die Machbarkeitsstudie für das Projekt [Projektname] bei [Unternehmen] zu erstellen. Problem oder Chance als Auslöser: [Kontext]. Erwarteter Nutzen: [erhoffte Vorteile]. Maximal denkbares Budget: [Betrag]. Bekannte Alternativen: [Alternativen, einschließlich Nichtstun].

Strukturieren Sie das Dossier in 6 Teile: Zu lösendes Problem und Kosten der Untätigkeit, mögliche Optionen (einschließlich Status Quo) mit Vor- und Nachteilen, grobe Schätzung von Kosten und Zeitrahmen pro Option als Spanne, erwarteter Nutzen verknüpft mit messbaren Indikatoren, Hauptrisiken jeder Option, begründete Empfehlung.

Einschränkungen: Jeder Nutzen muss mit einem überprüfbaren Indikator verknüpft sein, andernfalls ist er als „nicht messbare Wette“ zu klassifizieren. Formulieren Sie 5 Go/No-Go Entscheidungskriterien, die das Gremium abhaken kann. Schließen Sie mit der Liste fehlender Informationen ab, die die Studie schwächen, und wer diese liefern muss.

Erstellen Sie eine einseitige Projekt-Charter für ein kleines Projekt, das keinen vollständigen Projektauftrag rechtfertigt. Projekt: [Beschreibung in 2 Sätzen]. Auftraggeber: [Auftraggeber]. Beteiligte Personen: [Personen und verfügbare Zeit]. Gewünschte Frist: [Datum]. Eventuelles Budget: [Betrag oder keines].

Vorgegebenes Format, maximal eine Seite: Ziel in einem messbaren Satz, Endprodukt und woran man erkennt, dass es fertig ist, was explizit ausgeschlossen ist (mindestens 3 Zeilen, dies ist der nützlichste Abschnitt), wer bei Konflikten entscheidet, Meilensteine (maximal 3), das Hauptrisiko und die Gegenmaßnahme.

Einschränkungen: Kein Projektmanagement-Jargon, Sätze, die ein Laie beim ersten Lesen versteht. Wenn meine Eingangsdaten eine Rubrik nicht abdecken, schreiben Sie „ZU KLÄREN mit [Person]“ statt zu improvisieren. Schließen Sie mit den 2 Fragen ab, die dem Auftraggeber vor dem Start gestellt werden müssen.

Ich starte das Projekt [Projektname] für [Unternehmen] und muss die Anforderungen aufnehmen, bevor der Umfang festgeschrieben wird. Zu befragende Personen: [Liste der Profile, z. B. Geschäftsführung, Anwender, Support, IT]. Was das Projekt liefern soll: [vermutetes Ergebnis]. Verfügbare Zeit pro Interview: [Dauer].

Bereiten Sie für jedes Profil einen angepassten Interviewleitfaden vor: 8 bis 10 offene Fragen, sortiert von allgemein bis spezifisch. Unterscheiden Sie Fragen zum aktuellen Ablauf (Pain Points, Workarounds, Volumina) von Fragen zum zukünftigen Bedarf. Fügen Sie für jedes Profil 2 Fangfragen hinzu, die nicht ausgesprochene Bedürfnisse hervorlocken, z. B. „Was tun Sie, wenn das aktuelle Tool nicht ausreicht?“.

Einschränkungen: Keine Suggestivfragen oder Ja/Nein-Fragen. Liefern Sie zudem eine Vorlage für die Zusammenfassung: geäußerte Bedarfe, abgeleitete Bedarfe, Widersprüche zwischen Profilen zur Klärung und prägnante Zitate.

Transformieren Sie diese rohen Anforderungen in User Stories, die für ein Umsetzungsteam nutzbar sind. Projekt: [Name und Kurzbeschreibung]. Betroffene Nutzer: [Nutzerprofile]. Geäußerte Bedarfe: [Liste der Bedarfe, auch vage].

Erstellen Sie für jeden Bedarf: Die User Story im Format „Als [Profil] möchte ich [Aktion], um [Nutzen] zu erreichen“, 3 bis 5 Akzeptanzkriterien, die binär formuliert sind (mit Ja oder Nein prüfbar, keine Begriffe wie „schnell“ oder „benutzerfreundlich“ ohne Schwellenwert) sowie Fragen an den Auftraggeber, falls der Bedarf zu vage für eine Aufteilung ist.

Einschränkungen: Eine Story muss in wenigen Tagen umsetzbar sein, schlagen Sie andernfalls eine Aufteilung vor. Identifizieren Sie Anforderungen, die eigentlich schon Lösungen sind, und formulieren Sie diese in echte Bedarfe um. Präsentieren Sie das Ergebnis als Tabelle: Story, Akzeptanzkriterien, geschätzte Größe (S/M/L), offene Fragen. Schließen Sie mit der Liste der Abhängigkeiten zwischen den Stories ab.

Helfen Sie mir, das Backlog für das Projekt [Projektname] zu priorisieren. Ausstehende Elemente: [Liste der Anfragen mit je einem Satz Beschreibung]. Teamkapazität: [Kapazität, z. B. 15 Personentage pro Monat]. Prioritäres Quartalsziel: [Ziel]. Auftraggeber mit dem größten Druck: [eventueller politischer Kontext].

Bewerten Sie jedes Element auf zwei Achsen: Wert (Beitrag zum Quartalsziel, Anzahl betroffener Nutzer, Kosten des ungelösten Problems) und geschätzter Aufwand in relativer Größe. Kategorisieren Sie anschließend in 4 Gruppen: Sofort erledigen (hoher Wert, geringer Aufwand), Einplanen (hoher Wert, hoher Aufwand), als Füllmaterial gruppieren (geringer Wert, geringer Aufwand), explizit ablehnen oder verschieben (geringer Wert, hoher Aufwand).

Einschränkungen: Der Druck eines Auftraggebers ist kein Wertkriterium, führen Sie jedoch Ablehnungen, die eine Erläuterung erfordern, separat auf. Erstellen Sie das Ranking als Tabelle mit Begründung pro Zeile. Verfassen Sie zudem die 3 schwierigsten Ablehnungsnachrichten kurz und sachlich.

Erstellen Sie die Roadmap für die nächsten 2 Quartale für [Produkt oder Projekt] bei [Unternehmen]. Jahresziele: [Ziele]. Mögliche Vorhaben: [Liste der geplanten Vorhaben]. Teamkapazität: [Größe und Verfügbarkeit]. Bereits eingegangene Verpflichtungen: [nicht verhandelbare Kunden- oder interne Zusagen].

Organisieren Sie die Roadmap nach Quartalen. Formulieren Sie jede Zeile als erwartetes Ergebnis, nicht als Funktion („Bearbeitungszeit für Anfragen reduzieren“ statt „Modul X entwickeln“). Pro Quartal: Maximal 2 bis 3 Vorhaben, das angestrebte Ergebnis, der Indikator für den Erfolg, Abhängigkeiten.

Einschränkungen: Halten Sie 20 % der Kapazität für Unvorhergesehenes frei und weisen Sie dies explizit aus. Listen Sie auf, was bewusst fehlt und warum, um Fragen wie „Warum nicht X?“ vorzubeugen. Liefern Sie zwei Versionen: Eine detaillierte für das Team und eine 5-zeilige Zusammenfassung für die Geschäftsführung. Markieren Sie Vorhaben, deren Wert zu unklar für eine Einplanung ist.

Helfen Sie mir, den Aufwand für das Projekt [Projektname] zu schätzen. Inhalt: [Liste der identifizierten Pakete oder Aufgaben]. Team: [Profile und Erfahrung]. Verfügbare Historie: [vergleichbare abgeschlossene Projekte und deren reale Dauer, falls bekannt].

Für jedes Paket: Eine Schätzung als Korridor (optimistisch, wahrscheinlich, pessimistisch) statt einer Einzelzahl, die zugrunde liegenden Annahmen (was muss zutreffen, damit die Schätzung hält) und der Faktor, der zum pessimistischen Szenario führen würde.

Einschränkungen: Wenn eine Historie vergleichbarer Projekte existiert, gleichen Sie die Schätzung mit der realen Dauer ab und erklären Sie Abweichungen. Fügen Sie systematisch Aufwände hinzu, die oft vergessen werden: Nachbesserungen nach der Abnahme, Koordination, Einarbeitung, vorhersehbare Abwesenheiten. Präsentieren Sie die Summe in 3 Szenarien mit der prozentualen Abweichung zwischen optimistisch und pessimistisch. Wenn die Abweichung mehr als das Doppelte beträgt, benennen Sie Informationen, die die Unsicherheit vor einer Zusage reduzieren würden.

Erstellen Sie das vollständige Budget für das Projekt [Projektname] bei [Unternehmen]. Geplante interne Aufwände: [Personentage pro Profil und Tagessatz, falls bekannt]. Externe Einkäufe und Dienstleistungen: [Liste]. Dauer: [Dauer]. Freigegebener Rahmen: [Betrag].

Erstellen Sie zuerst das Budget nach Positionen: Bewertete interne Aufwände, externe Dienstleistungen, Lizenzen und Tools, Nebenkosten sowie eine Risikoreserve, deren Prozentsatz Sie basierend auf der Unsicherheit begründen. Prüfen Sie die Kohärenz mit dem freigegebenen Rahmen und weisen Sie sofort auf Überschreitungen hin.

Erstellen Sie dann das monatliche Controlling: Tabelle Ist vs. Budget pro Position, neu geschätzter Restaufwand (Estimate to Complete, nicht nur Restbudget), Projektion zum Projektende und 2 bezifferte Warnschwellen, die eine Information des Sponsors auslösen. Schließen Sie mit den 3 häufigsten Budgetabweichungen bei dieser Art von Projekt und wie man sie frühzeitig erkennt.

Erstellen Sie das Risikoregister für das Projekt [Projektname]. Kontext: [Projektbeschreibung, Frist, Ziele]. Bereits vermutete Risiken: [identifizierte Risiken]. Externe Abhängigkeiten: [Lieferanten, andere Teams, erwartete Validierungen].

Ergänzen Sie meine Liste um typische Risiken dieser Projektart, die ich nicht genannt habe, unterteilt in 4 Kategorien: Menschlich (Abgänge, Überlastung, fehlende Kompetenz), Technisch, Organisatorisch (schleppende Entscheidungen, Scope Creep), Extern. Für jedes Risiko: Konkrete Beschreibung der Auswirkungen, Wahrscheinlichkeit (niedrig/mittel/hoch), Auswirkung (niedrig/mittel/hoch), resultierende Kritikalität, beobachtbares Frühwarnsignal, Präventionsmaßnahme, Notfallplan bei Eintritt, Verantwortlicher für die Überwachung.

Einschränkungen: Formulieren Sie jedes Risiko als Ereignis („Der Dienstleister liefert mit einem Monat Verspätung“), niemals als vages Thema („Termine“). Sortieren Sie nach abnehmender Kritikalität und begrenzen Sie das Register auf die 10 Risiken, die wirklich eine Überwachung verdienen. Legen Sie den Review-Rhythmus fest.

Erstellen Sie ein Stakeholder-Mapping für das Projekt [Projektname] bei [Unternehmen]. Identifizierte Akteure: [Liste der Personen oder Einheiten mit ihrer Rolle]. Was sich durch das Projekt für jeden ändert: [vermutete Auswirkungen]. Bereits wahrgenommene Unterstützung oder Widerstände: [Kontext].

Positionieren Sie jeden Akteur auf zwei Achsen: Einfluss auf das Projekt (kann blockieren, beschleunigen oder neutral) und aktuelle Einstellung (Unterstützer, neutral, skeptisch). Für jeden einflussreichen Akteur: Was er durch das Projekt zu gewinnen oder zu verlieren hat, sein wahrscheinlicher Einwand in seinen Worten formuliert und die passende Maßnahme (Einbindung in Entscheidungen, regelmäßige Information, Einzelgespräch vor Ankündigungen).

Einschränkungen: Verwechseln Sie das Organigramm nicht mit realem Einfluss; weisen Sie auf Akteure ohne Titel hin, deren Meinung Gewicht hat. Erstellen Sie den Engagement-Plan als Tabelle: Akteur, aktuelle Position, Zielposition für den Projekterfolg, Maßnahmen, Verantwortlicher, Termin. Schließen Sie mit den 2 Akteuren ab, die diese Woche prioritär kontaktiert werden müssen.

Erstellen Sie den Kommunikationsplan für das Projekt [Projektname]. Zielgruppen: [Zielgruppen, z. B. Sponsor, Team, betroffene Nutzer, andere Abteilungen]. Projektdauer: [Dauer]. Bekannte Schlüsselmomente: [Meilensteine, Go-Live, Ankündigungen]. Verfügbare Kanäle: [Kanäle: Meeting, E-Mail, Intranet, Aushang].

Definieren Sie für jede Zielgruppe: Was sie wissen muss (und nur das), die passende Frequenz, den Kanal, das Format (2 Zeilen, eine Seite, Meeting) und wer die Nachricht erstellt. Unterscheiden Sie zwischen laufender Kommunikation (Fortschritt) und anlassbezogener Kommunikation (Kick-off, Go-Live, Vorfall, Abschluss).

Einschränkungen: Jede Kommunikation muss die Frage des Empfängers „Was ändert das für mich?“ beantworten, andernfalls ist sie zu streichen. Erstellen Sie Entwürfe für die Kick-off-Nachricht und die Go-Live-Ankündigung. Präsentieren Sie den Plan als Übersichtstabelle und listen Sie die 3 häufigsten Kommunikationsfehler bei dieser Projektart auf sowie wie dieser Plan sie vermeidet.

Erstellen Sie die RACI-Matrix für das Projekt [Projektname]. Hauptaktivitäten: [Liste der Aktivitäten oder Deliverables]. Akteure: [beteiligte Personen oder Funktionen]. Bereits festgestellte Spannungen oder Unklarheiten: [Kontext, z. B. zwei Personen glauben, über dasselbe Thema zu entscheiden].

Weisen Sie für jede Aktivität Rollen zu: R (Responsible - führt aus), A (Accountable - trägt die Verantwortung und entscheidet, nur einer pro Zeile), C (Consulted - wird vorher gefragt), I (Informed - wird danach informiert). Erklären Sie jede nicht offensichtliche Zuweisung in einer Zeile.

Qualitätsprüfung: Niemals zwei A in einer Zeile, keine Zeile ohne R. Weisen Sie auf Akteure hin, die in fast jeder Zeile als C stehen (Flaschenhals) oder Akteure ohne jegliche Rolle. Präsentieren Sie die Matrix als Tabelle. Listen Sie die 3 Zeilen auf, die am ehesten zu Konflikten führen könnten, mit Ihrer Empfehlung zur Absicherung sowie Fragen, die vor der Verteilung im Team geklärt werden müssen.

Bereiten Sie das Kick-off-Meeting für das Projekt [Projektname] vor. Teilnehmer: [Teilnehmer und Rollen]. Dauer: [Dauer, z. B. 1 Std.]. Stand der Planung: [Projektauftrag validiert oder in Arbeit]. Sensible Punkte: [Spannungen, Skepsis, Historie gescheiterter Projekte zum Thema].

Liefern Sie: Den zeitlichen Ablauf (Warum dieses Projekt und warum jetzt, konkretes Endergebnis, was ist Out-of-Scope, wer macht was, Meilensteine, Regeln der Zusammenarbeit, Fragen), die 3 Kernbotschaften, die jeder Teilnehmer mitnehmen muss, und die Art und Weise, wie [sensibler Punkt] angesprochen wird, ohne die Stimmung zu drücken oder dem Thema auszuweichen.

Einschränkungen: Das Kick-off ist keine reine Informationsveranstaltung. Planen Sie 2 Momente ein, in denen die Teilnehmer aktiv beitragen (z. B. Ad-hoc-Risikoidentifikation, Blitzlicht zu individuellen Einschränkungen). Liefern Sie zudem den Einladungstext mit Agenda und Vorbereitungsaufgaben sowie eine Liste der Dinge, die VOR dem Kick-off geklärt sein müssen.

Bereiten Sie den nächsten Lenkungsausschuss für das Projekt [Projektname] vor. Teilnehmer: [Mitglieder des Gremiums]. Dauer: [Dauer]. Projektsituation: [Fortschritt, Schwierigkeiten, Budget]. Benötigte Entscheidungen: [erwartete Entscheidungen mit Optionen]. Themen, die die Diskussion dominieren könnten: [sensible Themen].

Erstellen Sie die Agenda ausgehend von den zu treffenden Entscheidungen, nicht vom Statusbericht: Jede Entscheidung wird ein Agendapunkt mit Zeitvorgabe, vorbereiteten Optionen (2 oder 3 mit Vor-/Nachteilen und Empfehlung) und den Konsequenzen bei einer erneuten Vertagung. Der Statusbericht wird in maximal 10 Minuten basierend auf einem vorab versendeten Dokument abgehandelt.

Liefern Sie: Die zeitlich gegliederte Agenda, die exakte Formulierung jeder Entscheidungsanfrage, die Technik, um Abschweifungen zu [sensiblem Thema] höflich zu unterbinden, und eine Vorlage für das Entscheidungsprotokoll (Versand innerhalb 24 Std.). Schließen Sie mit der Liste der Unterlagen ab, die 48 Std. vorab an die Teilnehmer gehen müssen.

Strukturieren Sie die Präsentation für den Lenkungsausschuss des Projekts [Projektname]. Daten des Monats: Fortschritt [Ist vs. Soll], Budget [Ist vs. Plan], Risiken [Entwicklung], erwartete Entscheidungen [Liste], Highlights [Ereignisse des Monats].

Erstellen Sie die Struktur Slide für Slide, maximal 10 Slides: Zusammenfassung (Ampelstatus, Kernbotschaft, Entscheidungsbedarf), Fortschritt pro Arbeitspaket mit Abweichungsanalyse, Budgetverlauf, Risiken mit veränderter Bewertung, Fokus auf den kritischen Punkt des Monats mit Optionen und Empfehlung, geforderte Entscheidungen (eine Slide pro Entscheidung), nächste Schritte.

Für jede Slide: Der Titel als Botschaft formuliert („Arbeitspaket 2 holt Rückstand auf“, nicht „Status Arbeitspaket 2“), Inhalt in maximal 5 Stichpunkten und was mündlich ergänzt werden sollte. Einschränkungen: Keine Slides zur Wiederholung des Kontexts, gerundete und verglichene Zahlen (vs. Plan, vs. Vormonat), Details in den Anhang. Schließen Sie mit dem Test ab: Wenn das Gremium nur Slide 1 liest, hat es das Wesentliche?

Richten Sie den Prozess für Änderungsanträge (Change Requests) für das Projekt [Projektname] ein. Kontext: [Ursprung der Anfragen, z. B. Kunde fügt laufend Wünsche hinzu, Geschäftsführung ändert Meinung]. Bestehende Gremien: [Meetings und Ausschüsse]. Verfügbare Puffer: [verbleibender Zeit- und Budgetpuffer].

Definieren Sie: Das minimale Antragsformular (Beschreibung, Antragsteller, Begründung, reale Dringlichkeit), die 4 systematischen Prüffragen (Auswirkung Zeit, Auswirkung Budget, Auswirkung auf andere Pakete, was passiert bei Nicht-Umsetzung), wer je nach Auswirkung entscheidet (bezifferte Schwellenwerte vorschlagen) und wie Entscheidungen in einem Change Log dokumentiert werden.

Verfassen Sie zudem 3 Antwortvorlagen: Antrag angenommen mit angekündigten Auswirkungen, Antrag auf spätere Version vertagt, Antrag abgelehnt mit Begründung. Einschränkungen: Der Prozess muss auf eine halbe Seite passen, sonst wird er nicht genutzt. Keine mündlichen Zusagen ohne Eintrag ins Log. Schließen Sie mit der Argumentation gegenüber einem drängenden Antragsteller ab.

Helfen Sie mir, die Neuverhandlung einer unmöglichen Frist vorzubereiten. Projekt: [Projektname]. Gewünschte Frist: [Datum]. Meine Überzeugung: Es werden [realistische Dauer] benötigt, weil [Gründe: geschätzter Aufwand, Abhängigkeiten, verfügbares Team]. Sponsor: [Profil des Sponsors und was ihm wichtig ist]. Hintergrund des Termins: [Warum dieses Datum, falls bekannt].

Erstellen Sie: Den faktischen Nachweis der Lücke (Aufwand vs. Kapazität in einfachen, prüfbaren Zahlen), gefolgt von 3 ehrlichen Optionen: Termin halten durch Reduzierung des Umfangs (präzise benennen, was wegfällt), Umfang halten durch Verschiebung des Termins, Ressourcen aufstocken mit Kosten und Grenzen dieser Option (neue Mitarbeiter sind nicht sofort produktiv).

Einschränkungen: Niemals „das ist unmöglich“ ohne Alternative sagen. Akzeptieren Sie im Meeting keinen Kompromiss ohne Nachberechnung. Bereiten Sie Antworten auf die 3 wahrscheinlichsten Einwände vor, darunter „Sehen Sie zu, wie Sie das hinkriegen“ und „Wir schauen einfach mal“. Format: Eine Seite Argumentarium plus Tabelle der 3 Optionen mit Konsequenzen.

Erstellen Sie den Aufholplan für das Projekt [Projektname], das [Dauer der Verzögerung] hinter dem Termin [Datum] liegt. Identifizierte Ursachen: [Ursachen]. Restaufwand: [verbleibende Pakete mit Schätzungen]. Team: [Zusammensetzung und Verfügbarkeit]. Handlungsspielraum: [mögliches Zusatzbudget, verhandelbarer Umfang].

Beginnen Sie mit der Diagnose: Liegt die Verzögerung an zu niedrigen Schätzungen, Scope Creep, abgezogenen Ressourcen oder externen Blockaden? Die Antwort bestimmt den Plan. Erstellen Sie dann den Aufholplan basierend auf realen Hebeln: Umfangskürzung, Parallelisierung von Aufgaben, Streichung unnötig gewordener Tasks, gezielte Verstärkung nur auf dem kritischen Pfad.

Einschränkungen: Es ist untersagt, den Rückstand durch grundlose „Komprimierung“ von Schätzungen aufzuholen. Test- und Abnahmezeiten dürfen nicht gestrichen werden. Liefern Sie: Den neuen Zeitplan mit verlässlichem Datum, die dafür gebrachten Opfer, die 2 Bedingungen für das Gelingen und die Nachricht an den Sponsor, die die Verzögerung eingesteht, ohne sie zu beschönigen.

Bereiten Sie die Eskalation einer Blockade im Projekt [Projektname] vor. Blockade: [Beschreibung, z. B. ausstehende Entscheidung, fehlende Ressource, Konflikt zwischen Abteilungen]. Seit: [Datum]. Bisherige Versuche: [Mahnungen und Schritte]. Empfänger der Eskalation: [Person und Ebene]. Beteiligte Personen: [Akteure mit eventuellen Empfindlichkeiten].

Verfassen Sie die Eskalationsnachricht: Zusammenfassung der Blockade in 3 sachlichen, datierten Zeilen, konkrete Konsequenzen des Stillstands (verlorene Tage, Kosten, gefährdete Meilensteine), 2 bis 3 Lösungsoptionen mit meiner Empfehlung, geforderte Entscheidung bis wann.

Einschränkungen: Keine persönlichen Vorwürfe, Fakten und Daten sprechen für sich. Der Empfänger muss allein durch das Lesen dieser Nachricht entscheiden können, ohne Meeting. Bereiten Sie zudem einen 60-sekündigen „Elevator Pitch“ für ein zufälliges Treffen vor sowie eine Nachricht an die von der Eskalation betroffenen Personen, damit diese nicht überrascht werden.

Organisieren Sie die Aufgabenverfolgung für das Projekt [Projektname] zwischen den Meetings. Aktuelle Situation: [festgestelltes Problem, z. B. Aufgaben werden nur zur Hälfte erledigt, Nachfragen wirken wie Überwachung]. Meeting-Rhythmus: [Frequenz]. Verfügbare Tools: [Tools: Excel, Ticket-System, Messenger].

Schlagen Sie ein System vor: Format der Aufgabenliste (Aufgabe mit Verb und prüfbarem Ergebnis, ein Verantwortlicher, Frist, Status), Aktualisierungsritual (wer aktualisiert wann wie lange) und eine abgestufte Mahn-Mechanik: Automatische Erinnerung 2 Tage vor Frist, sachliche Einzelnachricht bei Fristablauf, Erwähnung im Meeting erst bei zweiter Überschreitung.

Verfassen Sie Vorlagen für Mahnungen auf den 3 Ebenen, kurz und ohne Vorwurf. Einschränkungen: Aufgaben ohne Frist oder klaren Verantwortlichen werden abgelehnt und im Meeting neu formuliert. Die Liste darf die Kapazität des Teams nicht übersteigen (Vorschlag für Limitierung). Schließen Sie mit der Präsentation des Systems gegenüber dem Team ab, damit es als Unterstützung wahrgenommen wird.

Konzipieren Sie das Dashboard für das Projekt [Projektname]. Art des Projekts: [Typ und Deliverable]. Dauer: [Dauer]. Zu überwachende kritische Punkte: [Ziele, z. B. enge Frist, knappes Budget, kritische Qualität]. Verfügbare Daten: [Quellen: Ticket-System, Zeiterfassung, Budget].

Wählen Sie maximal 6 bis 8 Indikatoren aus, verteilt auf 3 Blöcke: Fortschritt (Ist vs. Soll bei abgeschlossenen Deliverables, nicht in Prozentangaben laufender Aufgaben), Gesundheit (verspätete Aufgaben, ausstehende Entscheidungen und deren Alter, steigende Risikobewertungen), Ressourcen (Ist vs. Budget, Auslastung des Teams).

Für jeden Indikator: Präzise Definition, Quelle, Aktualisierungsfrequenz, begründete Warnschwelle. Einschränkungen: Keine unverifizierbaren Selbsteinschätzungen („80 % fertig“), sondern binäre Logik (Fertig/Nicht fertig). Beschreiben Sie den wöchentlichen 15-Minuten-Check: Lesereihenfolge, Fragen und wann über das Team hinaus alarmiert werden muss.

Erstellen Sie den monatlichen Statusbericht für das Projekt [Projektname] an [Empfänger, z. B. Geschäftsführung]. Daten des Monats: Erfolge [was geliefert wurde], Abweichungen [Verzögerungen oder Überschreitungen], Budget [Ist vs. Plan], Risiken [Entwicklungen], getroffene Entscheidungen [Liste], Warnsignale [kritische Punkte].

Vorgegebenes Format, eine Seite: Gesamtverlauf in 2 Sätzen (wird das Projekt im Zeit- und Budgetrahmen landen, ja oder nein, und was hat sich diesen Monat geändert), Erfolge des Monats in 3 Punkten verknüpft mit Meilensteinen, Abweichungen mit Ursache und Gegenmaßnahme (keine isolierte Abweichung ohne Plan), Budget in einer Zeile mit Projektion, Warnsignale mit expliziter Forderung an die Geschäftsführung.

Einschränkungen: Die Geschäftsführung liest viele solcher Berichte. Keine Selbstdarstellung oder Füllsätze. Jedes Warnsignal muss in eine präzise Anfrage münden (Entscheidung, Mittel, Priorisierung). Schlechte Nachrichten und Abweichungen stehen oben, nicht am Ende der Seite.

Helfen Sie mir, Ressourcen zwischen konkurrierenden Projekten zu priorisieren. Laufende Projekte: [Liste der Projekte mit Frist, Bedeutung und Status]. Gemeinsame Ressourcen: [Personen in Mehrfachbesetzung und aktuelle Verteilung]. Aktueller Konflikt: [Beschreibung des Ressourcenkonflikts]. Wer entscheidet letztinstanzlich: [Gremium oder Person].

Erstellen Sie zuerst ein ehrliches Bild: Wer arbeitet woran (in realen Prozenten, nicht theoretisch) und wo liegen Überlastungen über 100 % vor. Schlagen Sie dann eine Bewertungsmatrix nach expliziten Kriterien vor: Strategische Bedeutung, Kosten einer Verzögerung pro Projekt, Unumkehrbarkeit (Zeitfenster), externe Verpflichtungen.

Wenden Sie die Matrix auf den Konflikt an und erstellen Sie 2 Szenarien der Zuweisung mit den jeweiligen Gewinnen und Verlusten pro Projekt sowie dem daraus resultierenden Enddatum. Einschränkungen: Konflikte dürfen nicht durch Überlastung von Personen oder unrealistische Teilzeitversprechen auf 3 Projekte gelöst werden. Das gewählte Szenario muss gegenüber den „verlierenden“ Projektleitern begründbar sein.

Bereiten Sie das nächste Sprint Planning für das Team [Team] im Projekt [Projektname] vor. Sprintdauer: [Dauer]. Kapazität: [anwesende Personen, geplante Abwesenheiten, Zeitaufwand außerhalb des Sprints: Support, Meetings]. Priorisiertes Backlog: [Kandidaten mit Schätzungen]. Reste aus dem Vorsprint: [nicht abgeschlossene Elemente].

Strukturieren Sie die Sitzung: Berechnung der Nettokapazität (verfügbare Zeit minus Fixaufwände minus Puffer nach einer einfachen Regel), Formulierung des Sprint-Ziels in einem Satz (Ergebnis am Ende, keine Ticketliste), Auswahl der Elemente innerhalb der Kapazitätsgrenze (beginnend mit Resten), kollektive Prüfung, ob jedes Element verstanden und ausreichend definiert ist.

Einschränkungen: Ablehnung von Elementen ohne Akzeptanzkriterien. Wenn der Druck die Kapazität übersteigt, ist die Antwort eine Auswahl zwischen Elementen, niemals eine stillschweigende Überplanung. Liefern Sie den Ablauf, das Sprint-Ziel und 3 Anzeichen während des Sprints, dass das Commitment gefährdet ist.

Bereiten Sie die Moderation der Sprint Retrospektive für das Team [Team] vor. Dauer: [Dauer, z. B. 45 Min.]. Aktuelle Stimmung: [Kontext, z. B. abgenutztes Ritual, Schweigen, Spannungen, neues Team]. Aktuelle Themen: [Ereignisse des letzten Sprints]. Maßnahmen aus vorherigen Retros: [beschlossene Punkte und realer Status].

Liefern Sie: Den Ablauf beginnend mit dem Check der alten Maßnahmen (eine Retro ohne Umsetzung stirbt nach 3 Iterationen), ein zur Stimmung passendes Moderationsformat mit exakten Anweisungen, Fragen bei oberflächlichen Antworten und die Auswahlmethode: Maximal 2 Verbesserungsmaßnahmen, vom Team gewählt, mit Verantwortlichem und Termin im nächsten Sprint.

Einschränkungen: Keine Maßnahmen wie „besser kommunizieren“, jede Maßnahme beschreibt eine beobachtbare Änderung. Themen außerhalb der Teamkontrolle (Organisation, Hierarchie) werden separat notiert und eskaliert, nicht endlos durchgekaut. Schlagen Sie zudem 2 alternative Formate für die nächsten Termine vor.

Strukturieren Sie das Daily Standup für das Team [Team] im Projekt [Projektname]. Aktuelle Situation: [Problem, z. B. Daily dauert 30 Min., ist ein Bericht an den Chef, einige schalten ab]. Teamgröße: [Anzahl]. Arbeitsmodus: [Präsenz, Remote, Hybrid].

Schlagen Sie das Zielformat vor: Maximale Dauer, feste Zeit und Fokus auf Koordination: Was ist seit gestern fertig, was blockiert oder könnte blockieren, was brauche ich von anderen. Themen, die nicht der Koordination dienen (technische Debatten, Problemlösung), werden notiert und danach im kleinen Kreis besprochen.

Liefern Sie: Moderationsregeln gegen den „Bericht-an-Chef“-Modus (Team spricht miteinander, wechselnde Moderation), Sätze zum Unterbinden von Abschweifungen, Anpassungen für [Arbeitsmodus] und 3 Signale, dass ein Daily seinen Zweck verliert, inklusive Korrekturmaßnahmen. Schließen Sie mit der Ankündigung des neuen Formats an das Team ab, die das „Warum“ erklärt, ohne das alte Vorgehen abzuwerten.

Helfen Sie dem Team [Team], seine Definition of Done (DoD) für das Projekt [Projektname] festzulegen. Art der Ergebnisse: [z. B. Softwarefunktionen, Schulungsunterlagen, Studien]. Festgestellte Probleme: [Symptome, z. B. Ergebnisse werden als fertig gemeldet und dann wieder geöffnet, schwankende Qualität, Lücken bei der Abnahme].

Erstellen Sie die DoD auf 3 Ebenen: Was macht ein Element „fertig“ (prüfbare Kriterien: Peer-Review, getestet, dokumentiert, von wem validiert), was ist explizit ausgeschlossen, um realistisch zu bleiben, und zulässige Ausnahmen mit Regeln zu deren Dokumentation.

Einschränkungen: Maximal 8 Kriterien, alle mit Ja/Nein prüfbar. Keine Kriterien, die das Team mit aktuellen Mitteln nicht erfüllen kann (sonst wird die DoD bei der ersten Eile ignoriert). Liefern Sie zudem: Die Methode zur Einführung im Team-Workshop, die Anwendungsregel für laufende Arbeiten und das Review-Ritual nach einigen Wochen.

Organisieren Sie die Anwenderabnahme (UAT) für das Projekt [Projektname]. Zu testendes Ergebnis: [Beschreibung]. Verfügbare Tester: [Profile und Verfügbarkeit]. Geplante Dauer: [Dauer]. Bestehende Akzeptanzkriterien: [zuvor definierte Kriterien oder keine].

Erstellen Sie: Den Testplan mit Testfällen nach realen User Journeys (nicht nach Bildschirmen oder Funktionen), jeder Fall mit Eingabedaten, Aktion und erwartetem Ergebnis; die Priorisierung (blockierend für Go-Live, wichtig, Komfort); Regeln zur Fehlerklassifizierung mit Beispielen zur Vermeidung von Diskussionen; den Prozess für Korrektur und Nachtest.

Liefern Sie zudem die Struktur des Abnahmeprotokolls: Was wurde getestet, Fehler nach Schweregrad, Entscheidung (Abnahme, Abnahme mit datierten Vorbehalten, Ablehnung) und Unterzeichner. Einschränkungen: Ein Test ohne realistische Daten ist wertlos, beschreiben Sie die Datenvorbereitung. Vorbehalte müssen einen Verantwortlichen und eine Frist haben.

Bereiten Sie den Inbetriebnahmeplan für [Produkt oder System] im Projekt [Projektname] vor. Zieldatum: [Datum]. Betroffene Nutzer: [wer und wie viele]. Zeitfenster: [z. B. Wochenende, Nacht, Geschäftszeiten]. Akteure der Umstellung: [Personen und Rollen]. Rollback möglich: [ja/nein/teilweise und wie].

Erstellen Sie: Die Checkliste vor der Umstellung (technische Voraussetzungen, Freigaben, Kommunikation, Backups, Verfügbarkeit der Akteure), den stündlichen Ablauf mit Verantwortlichkeiten und Erfolgskriterien pro Schritt, Go/No-Go Entscheidungspunkte (wer entscheidet worauf basierend), den Rollback-Plan (Auslöser und Durchführung) sowie die Überwachung der ersten Stunden und Tage.

Einschränkungen: Jeder Schritt hat ein prüfbares Erfolgskriterium, kein „sollte klappen“. Der Rollback-Plan muss so detailliert wie die Umstellung sein, da er unter Stress ausgeführt wird. Schließen Sie mit der Ankündigung an die Nutzer vor und nach der Umstellung ab.

Organisieren Sie die Betriebskontinuität während der Migration von [altes System/Prozess] auf [neues System/Prozess] bei [Unternehmen]. Geplante Übergangsdauer: [Dauer]. Kritische Aktivitäten: [Aktivitäten]. Betroffene Teams: [Teams]. Bekannte Risikozeiträume: [z. B. Monatsabschluss, Saisonspitzen].

Klären Sie die kritischen Fragen: Welches System ist während der Koexistenz für welche Daten führend (klare Regeln pro Fall), wie wird Doppelerfassung vermittelt oder sauber organisiert, wer bearbeitet laufende Vorgänge, die im alten System begannen und im neuen enden, und wie werden Daten zum finalen Stichtag eingefroren oder synchronisiert.

Liefern Sie: Eine Tabelle der kritischen Aktivitäten mit ihrem Modus während des Übergangs, die „Leading System“-Regeln, das verstärkte Support-Konzept der ersten Wochen und die 3 wahrscheinlichsten Störszenarien mit entsprechenden Handlungsanweisungen.

Bereiten Sie den Abschluss des Projekts [Projektname] vor, dessen Ergebnis am [Datum] abgenommen wurde. Projektbestandteile: [beteiligte Dienstleister, Budget, Dokumentation, Team]. Offene Vorbehalte: [eventuelle Mängel aus der Abnahme].

Erstellen Sie die vollständige Abschluss-Checkliste: Vertraglich (Abrechnung Dienstleister, Klärung Vorbehalte, Entzug von Zugängen), Finanziell (Stopp der Buchungen, Soll-Ist-Vergleich mit Begründung, Budgetabschluss), Dokumentarisch (Archivierung, Auffindbarkeit in 2 Jahren), Menschlich (Team-Reallokation, Dank an Beteiligte), Übergabe (Verantwortlichkeit für den Betrieb, Support-Modell).

Einschränkungen: Unterscheiden Sie zwischen Dingen, die den Abschluss blockieren, und solchen, die nachgelagert erfolgen können. Ein Projekt, das zu „98 % fertig“ über 6 Monate dahinplätschert, verursacht Kosten; setzen Sie ein festes Abschlussdatum. Liefern Sie zudem die Struktur des einseitigen Projektberichts: Kennzahlen, Erfolge, Abweichungen und Archivierungsort der Lektionen.

Organisieren Sie die Übergabe des Projekts [Projektname] von [scheidender PL] an [neuer PL]. Grund des Wechsels: [Grund und Kündigungsfrist]. Projektstatus: [Fortschritt, Brennpunkte, kommende Meilensteine]. Verfügbare Übergabezeit: [Überschneidungsdauer oder keine].

Erstellen Sie das Übergabedossier mit Fokus auf implizites Wissen: Historie der Entscheidungen und deren Gründe, mündliche Zusagen an Sponsor/Kunde, sensible Themen und Befindlichkeiten der Akteure, Risiken, die der scheidende PL informell überwacht, realer Status der Pakete jenseits des offiziellen Reportings.

Planen Sie die Einarbeitung: Meetings zur persönlichen Vorstellung (Sponsor, Kunde, Team), Priorisierung der Wissensthemen nach Dringlichkeit und die Ankündigung des Wechsels, die Sicherheit vermittelt, ohne Kontinuität vorzutäuschen. Einschränkungen: Die Übergabe muss prüfbar sein; erstellen Sie eine Liste von Fragen, die der neue PL am Ende allein beantworten können muss. Nicht übertragbare Punkte werden explizit mit Notfallkontakt gelistet.

Bereiten Sie das Onboarding für [Neuzugang, Profil] vor, der am [Datum] zum Projekt [Projektname] stößt. Projektstatus: [Fortschritt und Kontext]. Erwartete Rolle: [Aufgaben]. Verfügbare Zeit des Teams für die Begleitung: [reale Einschränkung].

Erstellen Sie den Plan für die ersten 2 Wochen: Lesepaket für Tag 1 (Projektauftrag, letzter Statusbericht, Risikoregister, Glossar), 4 Termine mit Schlüsselpersonen und deren Ziel, ein erster nützlicher und abgegrenzter Beitrag in Woche 1 (passend zu [Rolle]), ein Mentor mit täglichem 10-Minuten-Check.

Einschränkungen: Keine passiven 15-Meeting-Marathons; der Neuzugang lernt durch Tun. Erklären Sie explizit, was sonst niemand sagt: Befindlichkeiten, Tabuthemen, reale Entscheidungswege. Liefern Sie den 2-Wochen-Plan, die sortierte Leseliste und Fragen, die der Neuzugang nach 15 Tagen beantworten können sollte, um die Integration zu bestätigen.

Helfen Sie mir, einen Konflikt in meinem Projektteam zu lösen. Kontext: [sachliche Beschreibung des Konflikts zwischen zwei Personen, wertfrei] im Projekt [Projektname]. Festgestellte Auswirkungen: [z. B. Zurückhalten von Infos, angespannte Meetings, Verzögerungen]. Meine Rolle: [Projektleiter, ohne Disziplinarbefugnis / mit Disziplinarbefugnis]. Historie: [Dauer des Konflikts, bisherige Versuche].

Schlagen Sie ein 3-stufiges Vorgehen vor: Zuerst Einzelgespräche (Fragen zum Verständnis beider Versionen ohne Wertung, Fallen wie die Schiedsrichterrolle vermeiden), dann gemeinsames Gespräch (Rahmensetzung, Rückführung auf Fakten bei persönlichen Angriffen, Einigung auf 2 bis 3 konkrete Regeln der Zusammenarbeit), schließlich Follow-up (Prüfung der Einhaltung ohne offene Überwachung).

Einschränkungen: Bleiben Sie in der Rolle des Projektleiters; Themen für Personalabteilung oder Disziplinarvorgesetzte werden identifiziert und weitergegeben, nicht selbst gelöst. Keine der Personen darf vor dem Team als Alleinschuldige dastehen. Nennen Sie Signale, die eine sofortige Eskalation erfordern.

Helfen Sie mir, einen Dienstleister zu korrigieren, der im Projekt [Projektname] Minderleistung zeigt. Dienstleister: [Firma und Leistung]. Festgestellte Abweichungen: [datierte Fakten: Verzug, Mängel, Personalwechsel, gebrochene Versprechen]. Vertraglicher Rahmen: [Deliverables, Fristen, eventuelle Pönalen]. Abhängigkeit: [Ersetzbarkeit des Dienstleisters].

Erstellen Sie eine Eskalationsstufen: Zuerst das Korrekturgespräch (faktische Liste der Abweichungen Soll vs. Ist, datiert und belegt; Ablauf des Meetings, das einen datierten Verbesserungsplan fordert statt Entschuldigungen), dann engmaschige Kontrolle (kurze Meilensteine, explizite Exit-Kriterien, schriftliches Protokoll nach jedem Termin), schließlich Vorbereitung der Alternative (diskret starten, falls die Abhängigkeit hoch ist).

Einschränkungen: Alles wird nach mündlichem Austausch schriftlich fixiert zur Absicherung bei Rechtsstreitigkeiten. Bleiben Sie sachlich und vertragskonform, keine leeren Drohungen. Liefern Sie: Die Mängelliste als Tabelle, die Einladungsmail, die Agendastruktur und objektive Kriterien für einen Projektabbruch.

Erstellen Sie das Lastenheft für die Ausschreibung von [Gegenstand, z. B. Website-Relaunch, Tool-Einführung] für [Unternehmen]. Bedarf: [Beschreibung des Problems]. Technischer und organisatorischer Kontext: [Bestand, Einschränkungen]. Indikatives Budget: [Spanne oder bewusst offen]. Zeitplan: [Fristen].

Struktur: Vorstellung des Unternehmens und Kontexts (halbe Seite), zu lösendes Problem und Ziele als erwartete Ergebnisse (Bedarf beschreiben, nicht die Lösung, außer bei begründeten Vorgaben), Scope und Ausschlüsse, nicht verhandelbare Rahmenbedingungen (technisch, rechtlich, zeitlich), erwartete Deliverables, Auswahlkriterien mit Gewichtung, Ablauf der Ausschreibung (Fragen, Abgabefrist, Präsentationen) und vorgegebenes Antwortformat zur Vergleichbarkeit.

Einschränkungen: Jede Anforderung muss bei Lieferung prüfbar sein. Unterscheiden Sie zwischen Muss- und Kann-Kriterien; alles als „Muss“ zu deklarieren, verhindert den Vergleich. Schließen Sie mit 5 Fragen für die Bieterpräsentation ab, die zeigen, ob der Dienstleister den Bedarf wirklich verstanden hat.

Erstellen Sie eine Bewertungsmatrix zum Vergleich der Angebote für [Gegenstand]. Angebote: [Anzahl und kurze Zusammenfassung: Preis, Termin, Ansatz, Highlights]. Wichtige Kriterien: [Prioritäten, z. B. Termintreue, Begleitung, Gesamtkosten, Zukunftsfähigkeit]. Wahrgenommene Signale: [zu prüfende Eindrücke, z. B. sehr niedriger Preis, generische Antwort].

Erstellen Sie die Matrix: Kriterien gruppiert nach Kategorien (Bedarfsverständnis, methodischer Ansatz, tatsächlich zugewiesenes Team, Gesamtkosten über Laufzeit inkl. versteckter Kosten, vergleichbare Referenzen, Vertragsbedingungen), Gewichtung basierend auf Prioritäten, Bewertungsskala mit Beschreibung pro Stufe zur Reduzierung von Subjektivität.

Wenden Sie die Matrix auf die beschriebenen Angebote an und markieren Sie: Unerklärte Preisunterschiede (niedrige Preise verstecken oft reduzierten Scope, Fragen dazu formulieren), in der Präsentation gezeigte Experten, die nicht im Projekt arbeiten werden, laufende versteckte Kosten. Liefern Sie die ausgefüllte Vergleichstabelle, Klärungsfragen pro Bieter und eine 5-zeilige begründete Empfehlung.

Erstellen Sie den Change Management Plan für [Projekt, z. B. neues Tool, Prozessänderung] bei [Unternehmen]. Betroffene Gruppen: [Gruppen mit Anzahl und Änderungen]. Geäußerte oder vermutete Ängste: [antizipierte Widerstände]. Zeitplan: [Schlüsseldaten]. Verfügbare Mittel: [Zeit, Budget, Multiplikatoren].

Für jede Gruppe: Was sich konkret im Alltag ändert (Gewinne UND Verluste, verschwiegene Verluste rächen sich später), benötigtes Begleitniveau (Information, Training, Coaching) und die Kernbotschaft aus deren Perspektive.

Zeitliche Struktur: Vorher (Ankündigung, Netzwerk glaubwürdiger Multiplikatoren, Training), Währenddessen (verstärkter Support, systematisches Feedback, sichtbare Korrektur gemeldeter Probleme), Danach (Messung der realen Nutzung statt nur Trainingsquote, Umgang mit verbleibenden Widerständen).

Einschränkungen: Kein Plan nach dem Motto „mehr kommunizieren“, ohne zu sagen, was an wen. Jede Maßnahme hat einen Verantwortlichen und ein Datum. Liefern Sie den Plan als Tabelle pro Gruppe und den konsolidierten Zeitplan.

Erstellen Sie das Schulungskonzept für Endanwender zur Einführung von [Tool/Prozess] bei [Unternehmen]. Nutzer: [Profile, Anzahl, IT-Affinität, Standorte]. Was jedes Profil beherrschen muss: [Aufgaben pro Profil]. Einschränkungen: [Verfügbarkeit, Budget, Go-Live Termin].

Erstellen Sie ein profilbasiertes System statt einer Einheitsschulung: Für jedes Profil die 5 bis 10 wichtigsten Handgriffe aus realen Szenarien (kein vollständiger Funktionsrundgang), passendes Format (Kurzsession, Tutorial, Training am Arbeitsplatz), Dauer und Referenzmaterial (Shortcards pro Aufgabe, je eine Seite, statt Handbuch).

Planen Sie die Sessions zeitnah zum Go-Live: Wissen aus Schulungen 6 Wochen vor Nutzung ist meist vergessen. Planen Sie Nachholsitzungen und Vor-Ort-Ansprechpartner (Key User) ein.

Einschränkungen: Erfolg wird an der realen Nutzung nach Go-Live gemessen (Beherrschung der Kernschritte, Support-Aufkommen) und nicht an der Teilnehmerquote. Liefern Sie den Plan als Tabelle pro Profil und die priorisierte Liste der zu erstellenden Unterlagen.

Ein schwerwiegender Vorfall betrifft das Projekt [Projektname]: [Art des Vorfalls, z. B. gescheiterter Go-Live, Datenverlust, Ausfall eines Kundendienstes, gravierende Abweichung entdeckt]. Festgestellte Auswirkungen: [wer ist wie betroffen]. Status der Lösung: [was bekannt ist, was noch unklar ist]. Zu informierende Gruppen: [Geschäftsführung, interne Teams, Kunden, Partner].

Erstellen Sie die Kommunikationsabfolge: Die schnelle Erstnachricht (was wir wissen, was wir nicht wissen, was wir tun und wann das nächste Update kommt – Termin für Update nennen, nicht für die Lösung), Status-Updates im versprochenen Rhythmus auch ohne Neuigkeiten, und die Abschlussnachricht mit Maßnahmen zur Vermeidung von Wiederholungen.

Passen Sie die Nachricht pro Gruppe an: Die Geschäftsführung will Auswirkungen und Entscheidungsbedarf, Nutzer wollen wissen, wie sie arbeiten können, Kunden wollen Schutz ihrer Interessen. Einschränkungen: Keine Spekulationen über Ursachen, keine Schuldzuweisungen, keine Terminversprechen, die nicht gehalten werden können (Glaubwürdigkeit). Liefern Sie anpassbare Vorlagen und die Regelung, wer mit wem spricht.

Helfen Sie dem Team [Team] bei [Unternehmen], seine OKRs für das Quartal [Quartal] zu formulieren. Unternehmensprioritäten: [Prioritäten]. Laufende Aufgaben des Teams: [Daueraufgaben]. Geplante Vorhaben: [Projekte/Ideen]. Teamgröße: [Anzahl].

Erstellen Sie maximal 2 bis 3 Ziele (Objectives): Jedes als inspirierender, aber konkreter Zustandswechsel formuliert (keine Aufgabenliste), explizit verknüpft mit einer Unternehmenspriorität. Pro Ziel 2 bis 4 Schlüsselergebnisse (Key Results): Messbar mit Start- und Zielwert, Messung eines Ergebnisses, nicht einer Tätigkeit („Bearbeitungszeit von X auf Y reduzieren“ statt „Tool Z einführen“).

Einschränkungen: Das Tagesgeschäft (Run) wird nicht zu OKRs, sondern separat gesteuert. Ein Key Result, dessen Messbarkeit heute unklar ist, wird umformuliert oder gestrichen. Markieren Sie Ziele, auf die das Team zu wenig Einfluss hat. Liefern Sie die OKR-Vorschläge, Fragen für den Team-Workshop und das Review-Ritual (Frequenz, 15-Minuten-Format, Vorgehen bei Abweichungen).

Bereiten Sie das Quartals-Review der OKRs für das Team [Team] vor. OKRs des abgelaufenen Quartals: [Ziele und Ergebnisse mit Erreichungsgrad]. Besondere Ereignisse: [Kontext: Unvorhergesehenes, Prioritätenwechsel, Abgänge]. Teilnehmer: [Teilnehmer]. Dauer: [Dauer].

Strukturieren Sie das Review in 3 Phasen: Ehrliche Bewertung jedes Key Results basierend auf realen Zahlen (nicht gemessen bedeutet nicht erreicht, kein „fast fertig“), Abweichungsanalyse (Unterscheidung zwischen Ausführung, falscher Ambition oder externen Faktoren), Entscheidungen für das nächste Quartal (was wird fortgeführt, was gestrichen, was neu kalibriert).

Einschränkungen: Das Review ist keine Rechtfertigungsübung. Keine Kontext-Slides, direkt zu den Zahlen. Ein zu 100 % erreichtes Ziel im ersten Quartal hinterfragt die Ambition ebenso wie ein 20 %-Ziel die Ausführung hinterfragt. Liefern Sie den Ablauf, das Bewertungsschema, Analysefragen pro Key Result und eine Vorlage für die Zusammenfassung nach dem Review.

Bereiten Sie das Post-Mortem für den Vorfall [Beschreibung] vom [Datum] im Projekt [Projektname] vor. Bekannte Chronologie: [Ablauf mit Uhrzeiten]. Beteiligte Personen: [Akteure]. Klima: [Kontext, z. B. jemand fühlt sich angegriffen, Geschäftsführung sucht Schuldigen].

Strukturieren Sie das Dokument und das Meeting: Gemeinsam rekonstruierte Fakten-Chronologie (stündlich, wertfrei), Ursachenanalyse über den individuellen Fehler hinaus (menschliches Versagen ist ein Symptom: Was hat den Fehler ermöglicht, was hätte ihn vor der Auswirkung abfangen müssen?), was bei Erkennung und Reaktion gut lief und Präventionsmaßnahmen.

Moderationsregeln für den Start: Wir suchen nach Schwachstellen im System, nicht nach dem Verursacher. Wer einen Fehler zugibt, hilft allen und darf dies nie bereuen. Einschränkungen: Maximal 5 Maßnahmen, jeweils mit Verantwortlichem und Frist. Bevorzugen Sie Maßnahmen, die Fehler technisch ausschließen, gegenüber Appellen zu mehr Wachsamkeit. Liefern Sie die Dokumentvorlage und den Meeting-Ablauf.

Helfen Sie mir, die gesammelten Erfahrungen von [Team/Unternehmen] in Arbeitsstandards zu überführen. Verfügbares Material: [Quellen: Retro-Protokolle, Projektabschlussberichte, Post-Mortems, wiederkehrende Anmerkungen]. Aktuelles Problem: [Symptom, z. B. gleiche Fehler wiederholen sich, Berichte werden geschrieben und nie wieder gelesen].

Gehen Sie wie folgt vor: Gruppieren Sie Lektionen nach Themen und identifizieren Sie Wiederholungen (Priorität für Standards), formulieren Sie jede Lektion in eine umsetzbare Regel mit Auslöser um („Bei jedem Projektstart tun wir X“). Definieren Sie, wo diese Regeln leben müssen, um im richtigen Moment gesehen zu werden (Integration in Vorlagen und Checklisten statt in einem separaten Wissensdokument).

Einschränkungen: Maximal 10 Regeln insgesamt, jede mit einem „Eigentümer“. Planen Sie ein halbjährliches Review zur Löschung unnötig gewordener Regeln ein (ein wachsendes Regelwerk stirbt). Liefern Sie die vorgeschlagenen Regeln nach Einsatzzeitpunkt, den Ort der Integration und die Ankündigung an das Team.

Bereiten Sie das Projekt [Projektname] auf ein Audit oder Quality Review durch [Auditor: Interne Revision, Kunde, Zertifizierer, Geschäftsführung] am [Datum] vor. Angekündigter Scope: [Prüfungsinhalte]. Realer Projektstatus: [bekannte Stärken/Schwächen, Stand der Dokumentation]. Bedeutung: [z. B. Finanzierung, Kundenvertrauen, Zertifizierung].

Organisieren Sie die Vorbereitung: Zusammenstellung der Referenzunterlagen (Auftrag, Entscheidungen, Risikomanagement, Protokolle, Budget) mit Fokus auf fehlende oder veraltete Dokumente, wahrscheinlichste Fragen des Auditors und die ehrliche Position zu bekannten Schwachstellen: Eingestehen, Aufzeigen der Kontrolle und Präsentation des datierten Maßnahmenplans.

Einschränkungen: Niemals Dokumente schönen oder rückdatieren. Eine eingestandene Schwachstelle mit glaubwürdigem Plan wirkt besser als eine Fassade, die im Interview bröckelt. Briefen Sie die Beteiligten auf Fakten, nicht auf Marketing-Sprech. Liefern Sie die Checkliste der Unterlagen, wahrscheinliche Fragen mit Antworten und den Zeitplan für die Vorbereitung.