Přejít k obsahu
Knihovna AI promptů

Prompty pro Projektové řízení

Definice cílů, zápisy z porad, plánování a řízení rizik pro projekty, které dodrží termíny. Doplňte vlastní údaje do závorek a zkopírujte text nebo jej rovnou otevřete v chatu.

  • 50 promptů pro Projektové řízení
  • Zkopírovat nebo otevřít v chatu

Sestavení zakládací listiny projektu (Project Charter)

Dokument, který sjednotí všechny strany před startem: rozsah, rizika a klíčové milníky.

Sestav zakládací listinu projektu [název projektu] pro [název firmy]. Cíl projektu: [cíl]. Zadavatel: [jméno/role]. Tým: [složení]. Rozpočet: [částka v Kč]. Cílový termín: [datum]. Kontext vzniku projektu: [proč projekt vzniká].

Struktura: kontext a problém k řešení (max. 3 řádky), měřitelný cíl, zahrnutý rozsah (scope), výslovně VYČLENĚNÝ rozsah (out of scope – detailně, aby se předešlo neřízenému rozšiřování), výstupy s akceptačními kritérii, časové milníky, role a odpovědnosti (kdo rozhoduje, kdo koná, kdo je konzultován, kdo informován), identifikovaná rizika a opatření pro každé z nich ([očekávaná rizika]), předpoklady a závislosti.

Formuluj každou sekci tak, aby případné neshody vypluly na povrch TEĎ při čtení, nikoliv uprostřed realizace. Na závěr uveď 3 klíčové otázky, které musí vedení rozhodnout před spuštěním.

Převod poznámek z porady na akční zápis

Stručný zápis s jasnými rozhodnutími a úkoly na základě hrubých poznámek.

Převeď mé hrubé poznámky z porady na strukturovaný zápis. Porada: [předmět jednání] ze dne [datum], účastníci: [jména]. Zde jsou poznámky: [vložte poznámky, i nesouvislé].

Formát výstupu: přijatá rozhodnutí (formulovaná jednoznačně, včetně toho, kdo rozhodl), úkoly (tabulka: úkol, odpovědná osoba, termín; pokud v poznámkách něco chybí, uveď „DOPLNIT“ místo vymýšlení), diskutované body bez rozhodnutí (max. 2 řádky ke každému), odložené body s termínem příští diskuse.

Pravidla: maximálně jedna strana A4, žádné přeformulování měnící smysl řečeného, vyhni se diplomatickým frázím typu „bylo dohodnuto pokračovat v diskuzi“. Zakonči seznamem bodů „K DOPLNĚNÍ“, které je třeba rozeslat účastníkům k validaci.

Rozpad projektu na etapy a harmonogram

Cesta od cíle k plánu: pracovní balíčky, úkoly, závislosti a kritická cesta.

Rozděl následující projekt na pracovní balíčky a vytvoř harmonogram. Projekt: [popis projektu a finální výstup]. Termín: [datum]. Dostupný tým: [lidé a kapacita, např. 2 lidé na poloviční úvazek]. Známá omezení: [např. schválení klientem, závislost na dodavateli, celozávodní dovolená].

Postupuj následovně: rozděl projekt na etapy, z nichž každá má ověřitelný výstup (žádné balíčky typu „koordinace“), rozlož etapy na úkoly v délce 0,5 až 3 dny, identifikuj závislosti a kritickou cestu, u nejistých úkolů přiznej časovou rezervu explicitně, místo skrytých rezerv u všeho.

Výstup: strukturovaný seznam etapy → úkoly s odhady, týdenní harmonogram s milníky schválení, zvýrazněná kritická cesta a 3 úkoly, které musí začít okamžitě. Pokud je termín [datum] s popsaným týmem nereálný, upozorni na to na základě čísel, místo tichého zkracování odhadů.

Týdenní Flash Report pro vedení

Jednostránkový přehled stavu projektu: semafor, fakta a očekávaná rozhodnutí.

Sestav týdenní flash report projektu [název projektu] pro [příjemci, např. řídicí výbor]. Data za týden: progres [skutečnost vs. plán], potíže [problémy], vývoj rizik [rizika], čerpání rozpočtu [čerpáno vs. plán v Kč], očekávaná rozhodnutí [blokující body a jak dlouho čekají].

Striktní formát na jednu stranu: stav projektu (zelená/oranžová/červená) s JEDNOU větou zdůvodňující barvu, 3 klíčové události týden, progres vs. plán (jeden řádek na aktivní etapu), rizika a úzká hrdla (pouze změny od minule), očekávaná rozhodnutí se jménem odpovědné osoby a dopadem prodlení, priority na příští týden.

Pravidla: projekt se nikdy nevrátí do zelené bez vysvětlení nápravy; oranžový stav trvající dva týdny se mění na červený; u čekajících rozhodnutí uveď datum původního požadavku.

Moderování závěrečné retrospektivy projektu

Příprava užitečného vyhodnocení: průběh, otázky a konkrétní ponaučení pro příště.

Připrav scénář retrospektivy pro projekt [název projektu], který právě skončil [výsledek: včas, zpoždění o X, zrušen]. Účastníci: [jména a role]. Doba trvání: [např. 90 min]. Klíčové momenty: [co se povedlo/nepovedlo, případné konflikty].

Výstup: časový harmonogram (úvod s pravidlem „hledáme příčiny, ne viníky“, individuální sběr podnětů před diskusí pro zamezení stádního efektu, diskuse o hlavních bodech, rozhodnutí), přesné otázky pro překonání obecných frází (např. „v jakém přesném momentu jsme věděli, že termín nestihneme? co nám bránilo to říct nahlas?“), a technika, jak otevřít [citlivé téma], aniž by se zvrhlo v obviňování.

Formát výstupů: každé ponaučení se změní v akční pravidlo pro příští projekt („napříště budeme…“) s určeným garantem. Maximálně 5 pravidel, více se v praxi neudrží.

Zpracování studie proveditelnosti (Go/No-Go)

Strukturovaný podklad pro rozhodnutí: přínosy, varianty, náklady a rizika.

Jsi zkušený projektový ředitel. Pomoz mi sestavit studii proveditelnosti projektu [název projektu] pro [firma]. Výchozí problém nebo příležitost: [kontext]. Očekávané přínosy: [co získáme]. Maximální rozpočet: [částka v Kč]. Známé alternativy: [např. nedělat nic, outsourcing].

Strukturuj dokument do 6 částí: problém k řešení a náklady nečinnosti, možné varianty (včetně status quo) s výhodami a nevýhodami, hrubý odhad nákladů a termínů u každé varianty (rozmezí), očekávané přínosy navázané na měřitelné ukazatele, hlavní rizika každé varianty, argumentované doporučení.

Omezení: každý přínos musí být navázán na ověřitelný ukazatel, jinak jej označ za „neměřitelný předpoklad“. Formuluj 5 rozhodovacích kritérií pro Go/No-Go. Na závěr uveď seznam chybějících informací, které studii oslabují, a kdo je má dodat.

Stručný projektový list pro malé úkoly

Jednostránkový rámec pro menší projekty bez zbytečné administrativy.

Sestav projektový list na jednu stranu pro malý projekt. Projekt: [popis dvěma větami]. Zadavatel: [jméno]. Zapojení lidé: [kdo a kolik času mají]. Požadovaný termín: [datum]. Rozpočet: [částka nebo žádný].

Povinný formát (max. 1 strana): cíl jednou měřitelnou větou, finální výstup a jak poznáme, že je hotov, co je mimo rozsah (min. 3 řádky, nejdůležitější sekce), kdo má rozhodující slovo při sporech, milníky (max. 3), hlavní riziko a obrana proti němu.

Omezení: žádný projektový žargon, věty srozumitelné pro laika na první přečtení. Pokud chybí vstupní informace, napiš „VYJASNIT s [jméno]“ místo vymýšlení. Zakonči 2 otázkami, které musím položit zadavateli před startem.

Příprava rozhovorů pro sběr požadavků

Scénáře rozhovorů podle rolí pro zjištění reálných potřeb uživatelů.

Zahajuji projekt [název projektu] pro [firma] a potřebuji sesbírat požadavky. Koho budu zpovídat: [seznam rolí, např. vedení, koncoví uživatelé, IT, podpora]. Co má projekt vytvořit: [předpokládaný výstup]. Čas na jeden rozhovor: [doba].

Připrav pro každou roli scénář: 8 až 10 otevřených otázek od obecných po konkrétní. Rozlišuj otázky na současný stav (bolavá místa, obezličky, objemy dat) a na budoucí potřeby. Ke každé roli přidej 2 „chytáky“, které odhalí nevyřčené potřeby, např. „co děláte, když stávající nástroj selže?“.

Omezení: vyvaruj se návodných otázek a těch, na které lze odpovědět ano/ne. Připrav také šablonu pro syntézu: vyjádřené potřeby, odvozené potřeby, rozpory mezi rolemi k řešení a klíčové citace.

Tvorba User Stories a akceptačních kritérií

Převod hrubých požadavků na testovatelné příběhy uživatelů s jasnými kritérii.

Převeď tyto hrubé požadavky na User Stories pro realizační tým. Projekt: [název a krátký popis]. Uživatelé: [role]. Požadavky: [seznam, i vágní].

Pro každý požadavek vytvoř: User Story ve formátu „Jako [role] chci [akce], abych [přínos]“, 3 až 5 akceptačních kritérií formulovaných binárně (lze ověřit ano/ne, žádné „rychlý“ nebo „přehledný“ bez čísel), a otázky na zadavatele, pokud je potřeba příliš vágní.

Omezení: story musí být realizovatelná v řádu dnů, jinak ji navrhni rozdělit. Upozorni na „falešné“ požadavky (řešení převlečená za potřeby) a přeformuluj je. Výsledek v tabulce: Story, akceptační kritéria, odhadovaná velikost (S/M/L), otevřené otázky. Zakonči seznamem závislostí mezi stories.

Prioritizace přehlceného backlogu

Seřazení úkolů podle hodnoty a úsilí s obhajitelným zdůvodněním.

Pomoz mi prioritizovat backlog projektu [název projektu]. Položky k řešení: [seznam požadavků s krátkým popisem]. Kapacita týmu: [např. 15 člověkodnů měsíčně]. Hlavní cíl kvartálu: [cíl]. Kdo nejvíce tlačí na pilu: [politický kontext].

Ohodnoť každou položku na dvou osách: hodnota (přínos k cíli kvartálu, počet uživatelů, náklady na neřešení) a odhadované úsilí (relativní velikost). Rozřaď je do 4 kategorií: udělat hned (vysoká hodnota, malé úsilí), naplánovat (vysoká hodnota, velké úsilí), výplňové úkoly (nízká hodnota, malé úsilí), odmítnout/odložit (nízká hodnota, velké úsilí).

Omezení: tlak zadavatele není kritériem hodnoty, ale bokem vypiš odmítnutí, která budou vyžadovat vysvětlení. Výstup v tabulce se zdůvodněním, poté navrhni 3 nejcitlivější zprávy o odmítnutí – stručně a věcně.

Sestavení kvartální produktové roadmapy

Roadmapa orientovaná na výsledky s jasným zdůvodněním každé volby.

Sestav roadmapu na příští 2 kvartály pro [produkt/projekt] firmy [název]. Cíle roku: [cíle]. Kandidáti na realizaci: [seznam]. Kapacita týmu: [velikost a dostupnost]. Pevné závazky: [nasmlouvané termíny].

Organizuj roadmapu po kvartálech, kde každý řádek je očekávaný výsledek, nikoliv funkce („zkrácení doby odbavení“ místo „vývoj modulu X“). Pro každý kvartál: max. 2–3 velké celky, cílený výsledek, KPI úspěchu, závislosti.

Omezení: ponech 20 % kapacity jako rezervu na nepředvídané události a v roadmapě to uveď. Seznam věci, které záměrně chybí a proč, aby se předešlo dotazům „a proč ne X?“. Dodej dvě verze: detailní pro tým a pětivětou pro vedení. Upozorni na položky s nejasnou hodnotou.

Reálný odhad pracnosti projektu

Odhady v rozmezí s explicitními předpoklady a korekcí přehnaného optimismu.

Pomoz mi odhadnout pracnost projektu [název projektu]. Obsah: [seznam etap/úkolů]. Tým: [role a zkušenosti]. Historie: [podobné projekty a jejich reálná délka, pokud jsou známy].

Pro každou etapu: odhad v rozmezí (optimistický, pravděpodobný, pesimistický), předpoklady (co musí platit, aby odhad seděl) a faktor, který by způsobil pesimistický scénář.

Omezení: pokud existuje historie, porovnej odhad s realitou minulosti a vysvětli rozdíl. Přidej systémově opomíjené položky: opravy po testování, koordinace, zaučení, plánované absence. Výsledek ve 3 scénářích s procentuálním rozdílem. Pokud je rozdíl mezi scénáři více než dvojnásobný, urči, jaké informace sníží nejistotu.

Sestavení rozpočtu a měsíční sledování čerpání

Kompletní rozpočet po položkách se systémem sledování a varovnými signály.

Sestav kompletní rozpočet projektu [název projektu] pro [firma]. Interní náklady: [člověkodny dle rolí a sazby]. Externí nákupy a služby: [seznam]. Délka: [doba]. Schválený rámec: [částka v Kč].

Nejdříve vytvoř rozpočet po položkách: oceněné interní kapacity, externí služby, licence a nástroje, vedlejší náklady a rezerva na rizika (zdůvodni její % dle nejistoty). Prověř soulad se schváleným rámcem a na případné překročení upozorni hned při tvorbě.

Následně navrhni systém měsíčního sledování: tabulka čerpání vs. rozpočet, re-odhad zbývající práce (ETC – nejen zbývající peníze), projekce celkových nákladů (EAC) a 2 varovné prahy, které spouští informování sponzora. Zakonči 3 nejčastějšími příčinami prodražení u tohoto typu projektů.

Vytvoření registru rizik projektu

Ohodnocený a prioritizovaný seznam rizik s nápravnými opatřeními a garanty.

Sestav registr rizik projektu [název projektu]. Kontext: [popis, termín, sázky]. Očekávaná rizika: [seznam]. Externí závislosti: [dodavatelé, jiné týmy, schvalování].

Doplň můj seznam o typická rizika pro tento obor, která jsem nezmínil, ve 4 kategoriích: lidská (odchody, přetížení, chybějící know-how), technická, organizační (pomalé rozhodování, bobtnání rozsahu), externí. U každého: konkrétní popis dopadu, pravděpodobnost (nízká/střední/vysoká), dopad (nízký/střední/vysoký), výsledná kritičnost, varovný signál, preventivní opatření, záložní plán (mitigace), odpovědná osoba.

Omezení: formuluj rizika jako události („dodavatel dodá s měsíčním zpožděním“), nikoliv jako vágní pojmy („termíny“). Seřaď podle kritičnosti a omez se na 10 klíčových rizik. Definuj frekvenci revize registru.

Mapování zainteresovaných stran (Stakeholders)

Analýza vlivu a postoje aktérů s plánem komunikace pro každého z nich.

Zmapuj zainteresované strany projektu [název projektu] ve firmě [název]. Identifikovaní aktéři: [seznam osob/oddělení a jejich role]. Co projekt pro každého změní: [dopady]. Vnímaná podpora/odpor: [kontext].

Umísti každého aktéra na dvě osy: vliv na projekt (může blokovat, urychlit, nebo ani jedno) a aktuální postoj (podporovatel, neutrální, skeptik). Pro vlivné aktéry urči: co mohou získat/ztratit, jejich pravděpodobnou námitku formulovanou jejich slovy a vhodnou strategii zapojení (účast na rozhodování, pravidelné info, osobní schůzka před oznámením).

Omezení: nezaměňuj organizační schéma s reálným vlivem, upozorni na „šedé eminence“. Výstup v tabulce: aktér, aktuální pozice, cílová pozice pro úspěch projektu, akce, garant, termín. Urči 2 priority pro tento týden.

Sestavení komunikačního plánu projektu

Koho informovat, o čem, jak často a jakým kanálem, bez zbytečného spamování.

Sestav komunikační plán projektu [název projektu]. Cílové skupiny: [např. sponzor, tým, uživatelé, ostatní oddělení]. Délka projektu: [doba]. Klíčové momenty: [milníky, spuštění, oznámení]. Dostupné kanály: [např. porada, e-mail, intranet, Slack/Teams].

Pro každou skupinu definuj: co potřebují vědět (a jen to), frekvenci, kanál, formát (2 řádky, jedna strana, schůzka) a kdo zprávu připravuje. Rozlišuj pravidelnou komunikaci (progres) a jednorázovou (kick-off, incident, ukončení).

Omezení: každá zpráva musí odpovídat na otázku příjemce „co to mění pro mě?“, jinak ji z plánu vyřaď. Připrav textaci zprávy o spuštění a zprávy o ostrém provozu. Výstup v tabulce, plus 3 nejčastější chyby v komunikaci u tohoto typu projektů a jak jim tento plán předchází.

Tvorba matice RACI

Jednoznačné rozdělení odpovědností a odhalení konfliktů v rolích.

Sestav matici RACI pro projekt [název projektu]. Hlavní aktivity/výstupy: [seznam]. Aktéři: [osoby/funkce]. Zjištěné nejasnosti: [např. dva lidé si myslí, že rozhodují o stejném bodu].

Každé aktivitě přiřaď role: R (Responsible – vykonává), A (Accountable – nese konečnou odpovědnost, schvaluje, jen jeden na řádek), C (Consulted – konzultován předem), I (Informed – informován po akci). U nejasných přiřazení uveď vysvětlení.

Kontrola kvality: nikdy dva „A“ na řádku, žádný řádek bez „R“, upozorni na „C“ u téměř všech řádků (riziko zdržování) a na aktéry bez role (adepti na vyřazení). Výstup v tabulce, plus 3 kritické body s rizikem konfliktu a doporučením, jak je zabezpečit, a otázky pro tým před finálním schválením.

Příprava zahajovací schůzky (Kick-off)

Kompletní scénář kick-offu, který sjednotí tým a zajistí podporu účastníků.

Připrav zahajovací schůzku projektu [název projektu]. Účastníci: [jména a role]. Délka: [např. 60 min]. Stav přípravy: [zakládací listina hotová/v procesu]. Citlivé body: [např. skepticismus, historie neúspěšných pokusů].

Výstup: časový harmonogram (proč projekt vzniká a proč teď, konkrétní finální výsledek, co je mimo rozsah, kdo co dělá, milníky, pravidla spolupráce, dotazy), 3 hlavní sdělení, která si musí každý odnést, a způsob, jak adresovat [citlivý bod], aniž by to zkazilo atmosféru.

Omezení: kick-off není jen prezentace, navrhni 2 momenty pro zapojení účastníků (např. rychlý sběr rizik, kolečko k osobním omezením). Dodej text pozvánky s programem a seznam věcí, které musí být schváleny PŘED schůzkou, aby se nezačínalo v mlze.

Příprava programu a moderování řídicího výboru (COPIL)

Jednání zaměřené na rozhodnutí, nikoliv na předčítání stavu projektu.

Připrav podklady pro příští řídicí výbor projektu [název projektu]. Účastníci: [členové výboru]. Délka: [doba]. Stav projektu: [progres, potíže, rozpočet]. Potřebná rozhodnutí: [seznam rozhodnutí s variantami]. Témata s rizikem nekonečné diskuse: [citlivá témata].

Sestav program tak, aby začínal rozhodnutími, nikoliv reportem: každé rozhodnutí je samostatný bod s časem, připravenými variantami (2–3, výhody/nevýhody, doporučení) a důsledkem, pokud se nerozhodne. Report o stavu trvá max. 10 minut na základě podkladů zaslaných předem.

Výstup: časový program, přesná formulace požadavků na rozhodnutí, technika pro zdvořilé utnutí odboček k [citlivé téma] a šablona zápisu rozhodnutí k odeslání do 24 h. Seznam věcí k rozeslání 48 h předem.

Struktura prezentace pro řídicí výbor

Osnova prezentace pro COPIL, která je přehledná a má maximálně 10 slidů.

Navrhni strukturu prezentace pro řídicí výbor projektu [název projektu]. Data za měsíc: progres [skutečnost vs. plán], rozpočet [čerpáno vs. plán], rizika [vývoj], očekávaná rozhodnutí [seznam], klíčové události.

Výstup: osnova slide po slidu (max. 10): 1. Shrnutí (semafor, hlavní zpráva, rozhodnutí), 2. Progres po etapách s odchylkami, 3. Vývoj rozpočtu, 4. Rizika se změnou stavu, 5. Detailní pohled na kritický bod měsíce s doporučením, 6.–8. Požadovaná rozhodnutí (jeden slide na jedno), 9. Další kroky.

Pro každý slide: nadpis formulovaný jako sdělení („Etapa 2 dohání zpoždění“, nikoliv „Stav etapy 2“), obsah v max. 5 bodech a co říct ústně (co není na slidu). Omezení: žádné opakováni kontextu, čísla zaokrouhlená a srovnaná (vs. plán, vs. minulý měsíc), detaily v příloze. Test: pokud si přečtou jen slide 1, mají to podstatné?

Nastavení procesu řízení změn (Change Management)

Jednoduchý systém pro posuzování změn v rozsahu bez ohrožení celého projektu.

Nastav proces řízení změn pro projekt [název projektu]. Kontext: [původ požadavků, např. klient přidává požadavky za pochodu, vedení mění názor]. Stávající schůzky: [seznam]. Dostupná rezerva: [čas a peníze].

Definuj: minimální formulář požadavku (popis, žadatel, zdůvodnění, reálná naléhavost), 4 systematické otázky pro posouzení (dopad na termín, rozpočet, ostatní etapy, co se stane, když to neuděláme), kdo rozhoduje dle velikosti dopadu (navrhni finanční/časové prahy) a jak vést evidenci v registru změn.

Navrhni 3 vzorové odpovědi: schválená změna s dopady, odložená změna do další fáze, zamítnutá změna se zdůvodněním. Omezení: proces musí být na půl strany, jinak ho nikdo nebude dodržovat; žádná ústní dohoda bez zápisu do registru. Jak to prodat nejvíce tlačícímu žadateli, aniž by se urazil.

Vyjednávání o nereálném termínu se sponzorem

Argumentace podložená čísly a varianty řešení, když termín nelze stihnout.

Pomoz mi připravit vyjednávání o nereálném termínu. Projekt: [název]. Požadovaný termín: [datum]. Můj odhad: je potřeba [reálná doba], protože [důvody: pracnost, závislosti, kapacita]. Sponzor: [profil osoby a co je pro ni důležité]. Důvod termínu: [pokud je znám, např. zákon, veletrh].

Sestav: faktické doložení rozdílu (pracnost vs. kapacita v jednoduchých číslech), poté 3 poctivé varianty: dodržet termín snížením rozsahu (přesně co vypadne), dodržet rozsah posunutím termínu, navýšení zdrojů s náklady a limity (nový člověk nezačne hned produkovat).

Omezení: nikdy neříkej „to nejde“ bez alternativy, nikdy neschvaluj kompromis bez čísel. Připrav odpovědi na 3 pravděpodobné námitky: „nějak to udělejte“ a „uvidíme v průběhu“. Formát: jedna strana argumentace plus tabulka 3 variant se srovnáním důsledků.

Krizový plán pro projekt ve zpoždění

Diagnostika příčin a reálný plán nápravy bez kouzelného zkracování odhadů.

Sestav plán nápravy pro projekt [název], který má zpoždění [doba] oproti termínu [datum]. Zjištěné příčiny: [proč]. Zbývající práce: [etapy s odhady]. Tým: [složení a kapacita]. Manévrovací prostor: [možný rozpočet navíc, rozsah k jednání].

Nejdříve prověř diagnózu: je zpoždění z podhodnocení, bobtnání rozsahu, chybějících zdrojů nebo externích bloků? Odpověď určuje plán. Poté sestav nápravu z reálných pák: redukce rozsahu, paralelizace úkolů, zrušení zbytečností, posílení výhradně na kritické cestě.

Omezení: zakázáno dohánět zpoždění „stlačením“ zbývajících odhadů bez důkazu, zakázáno rušit testování. Výstup: nový harmonogram s reálným datem, co bylo obětováno, 2 podmínky pro udržení plánu a zpráva sponzorovi, která přiznává zpoždění, ale nabízí řešení.

Eskalace problému bez narušení vztahů

Věcná zpráva o blokaci s variantami řešení a vyčíslením nákladů na nečinnost.

Připrav eskalaci blokujícího bodu u projektu [název]. Problém: [popis, např. chybějící rozhodnutí, nepřidělený zdroj]. Trvá od: [datum]. Co jsem už zkusil: [upomínky, jednání]. Příjemce eskalace: [jméno a úroveň]. Zapojené osoby v konfliktu: [kdo, případné citlivosti].

Napiš eskalační zprávu: shrnutí blokace (3 věcné řádky s daty), konkrétní důsledky status quo vyčíslené v penězích nebo dnech zpoždění milníků, 2–3 varianty odblokování s mým doporučením, požadované rozhodnutí a do kdy.

Omezení: žádné osobní útoky, fakta a data mluví za tebe; příjemce musí být schopen rozhodnout jen na základě této zprávy bez schůzky. Připrav i 60vteřinovou ústní verzi pro náhodné setkání a zprávu pro dotčené osoby, aby se o eskalaci nedozvěděly oklikou.

Sledování úkolů mezi poradami

Systém kontroly a připomínání, který posouvá věci vpřed bez mikromanagementu.

Navrhni systém sledování úkolů projektu [název] mezi poradami. Současný stav: [problém, např. úkoly se plní jen z poloviny, připomínání působí jako buzerace]. Četnost porad: [frekvence]. Dostupné nástroje: [např. Excel, Jira, Asana, Teams].

Navrhni kompletní systém: formát registru úkolů (úkol začíná slovesem a má ověřitelný výstup, jeden odpovědný, termín, stav), rituál aktualizace (kdo, kdy, jak dlouho), a mechaniku odstupňovaných připomínek: automatické upozornění T-2 dny, věcná individuální zpráva v den termínu, zmínka na poradě až při druhém nesplnění.

Navrhni vzory zpráv pro 3 úrovně připomínání – krátké a bez výčitek. Omezení: úkol bez termínu nebo bez jednoho odpovědného je u zdroje odmítnut; registr nesmí přesáhnout reálnou kapacitu týmu. Jak to prodat týmu jako pomoc, ne jako bič.

Návrh projektového dashboardu

Ukazatele progresu, které ukazují reálný stav, nikoliv iluzi kontroly.

Navrhni dashboard projektu [název projektu]. Typ projektu: [např. IT, stavební, marketing]. Délka: [doba]. Kritické body: [např. napjatý termín, kvalita]. Dostupná data: [zdroje: výkazy času, rozpočet, úkoly].

Vyber max. 6–8 ukazatelů ve 3 blocích: Progres (skutečnost vs. plán v hotových výstupech, nikoliv v % rozpracovanosti), Zdraví (úkoly po termínu, čekající rozhodnutí a jejich stáří, rostoucí rizika), Zdroje (čerpání rozpočtu, vytížení týmu).

U každého ukazatele: definice, zdroj, frekvence aktualizace, zdůvodněný varovný práh. Omezení: vyřaď neověřitelné subjektivní údaje („hotovo na 80 %“) ve prospěch binárního hotovo/nehotovo; každý ukazatel musí při červené barvě vyvolat akci. Popiš 15minutovou týdenní revizi dashboardu.

Měsíční report pro vedení (Status Report)

Shrnutí na jednu stranu: trajektorie, rozhodnutí a varování.

Sestav měsíční status report projektu [název projektu] pro [příjemci, např. představenstvo]. Data: úspěchy [co je dodáno], odchylky [zpoždění/překročení], rozpočet [čerpáno vs. plán], rizika [změny], přijatá rozhodnutí, varování [kritické body].

Povinný formát na jednu stranu: celková trajektorie dvěma větami (dopadne projekt včas a v rozpočtu? ano/ne, co se změnilo), úspěchy měsíce navázané na milníky, odchylky s příčinou a řešením (žádná odchylka bez plánu nápravy), rozpočet s projekcí do konce, varování vyžadující zásah vedení s jasným požadavkem.

Omezení: vedení čte desítky takových reportů, žádná vata ani sebechvála; každé varování musí končit požadavkem (rozhodnutí, zdroje), jinak patří do reportu pro tým. Špatné zprávy a odchylky uváděj jako první, neschovávej je na konec.

Prioritizace zdrojů mezi více projekty

Metoda rozhodování o zdrojích s jasným zobrazením důsledků každé volby.

Pomoz mi rozhodnout o přidělení zdrojů mezi konkurenční projekty. Projekty: [seznam s termíny, důležitostí a stavem]. Sdílené zdroje: [lidé a jejich aktuální vytížení]. Aktuální konflikt: [popis, o koho se bojuje]. Kdo má konečné slovo: [role/výbor].

Nejdříve vytvoř reálný snímek: kdo na čem dělá v reálných % (ne teoretických) a kde jsou lidé vytíženi na více než 100 %. Poté navrhni rozhodovací matici: přínos pro firmu, náklady na zpoždění každého projektu, nevratnost (okno příležitosti), externí závazky.

Aplikuj matici na konflikt a vytvoř 2 scénáře alokace. U každého jasně uveď, co který projekt získá a ztratí a jaký to má dopad na finální termín. Omezení: neřeš konflikt přetížením lidí nebo slibováním polovičních úvazků na 3 projektech; vybraný scénář musí být obhajitelný před „poraženými“ manažery.

Příprava plánování sprintu (Sprint Planning)

Plánování s jasným cílem, reálnou kapacitou a závazkem, který tým splní.

Připrav plánování příštího sprintu týmu [název] na projektu [název]. Délka sprintu: [doba]. Kapacita: [lidé, dovolené, čas na provoz/support]. Prioritizovaný backlog: [položky k výběru s odhady]. Zbytek z minulého sprintu: [nedokončené položky].

Struktura schůzky: výpočet reálné kapacity (dostupný čas minus provoz minus rezerva), formulace Cíle sprintu jednou větou (výsledek, nikoliv seznam ticketů), výběr položek do limitu kapacity (začni resty), společné ověření, že každá položka je pochopena a připravena k zahájení.

Omezení: odmítni položky bez akceptačních kritérií; pokud zadavatel tlačí nad kapacitu, řešením je výměna položek, nikoliv tiché navýšení závazku. Výstup: časový plán schůzky, formulace Cíle sprintu a 3 signály v průběhu sprintu, že závazek je v ohrožení.

Moderování agilní retrospektivy s výsledky

Krátký formát retrospektivy, který vede k akčním krokům a předchází únavě z rituálu.

Připrav scénář retrospektivy sprintu pro tým [název]. Délka: [např. 45 min]. Aktuální nálada: [např. únava, ticho, nedávný konflikt, nový tým]. Události sprintu: [co se stalo]. Akce z minulých retrospektiv: [stav plnění].

Výstup: časový plán začínající kontrolou akcí z minula (pokud se akce neplní, retrospektiva do 3 cyklů umře), formát aktivity vhodný pro [nálada] s přesnými instrukcemi, doplňující otázky pro hlubší analýzu a metoda výběru: max. 2 akce ke zlepšení, vybrané týmem, každá s odpovědnou osobou a termínem v příštím sprintu.

Omezení: žádné vágní akce typu „lépe komunikovat“, každá akce musí být pozorovatelná změna; témata mimo vliv týmu (hierarchie, organizace) zapiš bokem pro eskalaci, neřeš je dokola. Navrhni 2 alternativní formáty pro příště.

Nastavení efektivního Daily Standupu

Pravidla pro krátkou denní synchronizaci, která odhaluje bloky, ne seznam úkolů.

Nastav pravidla denního standupu týmu [název]. Současný stav: [např. trvá 30 minut, je to report šéfovi, lidé nedávají pozor]. Velikost týmu: [počet]. Způsob práce: [kancelář, remote, hybrid].

Navrhni cílový formát: maximální délka, pevný čas a obsah zaměřený na koordinaci: co je hotovo od včera, co mě blokuje/ohrožuje, co potřebuji od ostatních. Vše, co není koordinace (technické debaty, řešení problémů), se zapíše a řeší hned po standupu jen s dotčenými.

Dodej: pravidla, která brání reportování šéfovi (tým mluví k sobě, rotace moderátora), větu pro zdvořilé utnutí odboček, úpravy pro [způsob práce] a 3 signály, že standup přestal sloužit, s nápravou. Zakonči zprávou pro tým o novém formátu, která vysvětlí přínos.

Definice hotového (Definition of Done) a kvality

Sdílená shoda na tom, co znamená „hotovo“, aby se předešlo nedodělkům.

Pomoz týmu [název] definovat Definition of Done (DoD) pro projekt [název]. Typ výstupů: [např. software, analýzy, školení]. Zjištěné problémy: [např. věci se vrací jako nedodělané, kolísavá kvalita, chyby při akceptaci].

Sestav DoD ve 3 úrovních: co dělá položku „hotovou“ (ověřitelná kritéria: peer-review, otestováno, zdokumentováno, schváleno kým), co je z definice záměrně vyjmuto (kvůli reálnosti) a přípustné výjimky s pravidlem pro jejich evidenci.

Omezení: max. 8 kritérií, všechna binární (ano/ne), žádné kritérium, které tým nemůže splnit vlastními silami (jinak bude DoD při prvním stresu ignorována). Dodej: metodu, jak DoD zavést v týmovém workshopu, pravidlo pro rozpracované věci a rituál revize po několika týdnech.

Organizace uživatelské akceptace (UAT) a předávací protokol

Plán testování s prioritami, pravidly pro vady a šablonou rozhodnutí.

Zorganizuj uživatelskou akceptaci (UAT) projektu [název]. Co se testuje: [popis]. Testeři: [role a čas]. Plánovaná délka: [doba]. Stávající kritéria: [seznam, nebo žádná].

Sestav: plán akceptace s testovacími scénáři dle reálných průchodů uživatele (ne podle funkcí), každý scénář má vstupní data, akci a očekávaný výsledek; prioritizaci vad (blokující spuštění, významná, kosmetická); pravidla pro klasifikaci vad s příklady pro zamezení sporů; proces oprav a re-testů.

Výstup: šablona předávacího protokolu (co se testovalo, vady dle úrovní, rozhodnutí: přijato, přijato s výhradami a termíny, zamítnuto) a podpisy. Omezení: akceptace bez reálných dat nic nedokazuje, popiš přípravu dat; výhrady musí mít termín odstranění, jinak se stanou trvalými.

Příprava plánu nasazení a checklistu pro spuštění

Harmonogram spuštění hodinu po hodině, kritéria Go/No-Go a plán návratu (Rollback).

Připrav plán nasazení [výstup/systém] pro projekt [název]. Termín: [datum]. Dotčení uživatelé: [kdo a kolik]. Okno pro zásah: [např. noc, víkend]. Aktéři: [jména a role]. Možnost návratu: [ano/ne/částečně, jak].

Sestav: checklist před spuštěním (technické prerekvizity, schválení, komunikace, zálohy, dostupnost lidí), harmonogram spuštění hodinu po hodině s odpovědností a ověřitelným výsledkem každého kroku, rozhodovací body Go/No-Go (kdo a podle čeho rozhodne), plán návratu (Rollback) spouštěný jakými signály a jak provedený, a monitoring v prvních hodinách/dnech.

Omezení: každý krok má jasné potvrzení úspěchu, žádné „mělo by to být ok“; plán návratu musí být stejně detailní jako nasazení (provádí se pod stresem). Zakonči textem zprávy pro uživatele před a po nasazení.

Zajištění kontinuity provozu během migrace

Organizace přechodného období, kdy koexistuje starý a nový systém.

Zorganizuj kontinuitu provozu během migrace z [starý systém/proces] na [nový systém/proces] ve firmě [název]. Plánovaná doba přechodu: [doba]. Kritické aktivity: [co se nesmí zastavit]. Dotčené týmy: [seznam]. Rizikové období: [např. účetní závěrka, sezónní špička].

Vyřeš klíčové otázky: který systém je v období koexistence „pravdivý“ pro různé typy dat (jasné pravidlo), jak zamezit dvojímu zadávání nebo jak ho řízeně provádět, kdo řeší rozpracované případy (začaté postaru, dokončené ponovu) a jak proběhne zmrazení/synchronizace dat při finálním přepnutí.

Výstup: tabulka kritických aktivit s režimem fungování při přechodu, pravidla „kdo je master“ pro různé případy, posílený support v prvních týdnech a 3 nejčastější krizové scénáře s návodem na řešení.

Řádné ukončení projektu a kapitalizace zkušeností

Checklist administrativního, smluvního a dokumentačního uzavření projektu.

Připrav uzavření projektu [název], jehož výstup byl akceptován dne [datum]. Součásti projektu: [dodavatelé, rozpočet, dokumentace, tým]. Zbývající výhrady: [pokud jsou].

Sestav kompletní checklist uzavření: smluvní část (vyrovnání s dodavateli, vyřešení výhrad, zrušení přístupů externistům), finanční část (ukončení vykazování, bilance čerpání vs. rozpočet s vysvětlením, uzavření nákladových středisek), dokumentační část (kam co archivovat, co musí být dohledatelné za 2 roky a kým), lidská část (oznámení o přeřazení týmu, jmenovité poděkování), předání (kdo přebírá výstup do provozu a s jakou podporou).

Omezení: rozlišuj, co blokuje uzavření a co lze dodělat po něm; projekt „hotový na 98 %“, který se vleče 6 měsíců, je drahý – stanov pevné datum konce. Výstup: jednostránkové shrnutí projektu (čísla, úspěchy, odchylky, archivace ponaučení).

Předání projektu mezi projektovými manažery

Předávací složka a plán souběhu pro změnu pilota bez ztráty kontinuity.

Zorganizuj předání projektu [název] mezi [odcházející PM] a [nastupující PM]. Kontext odchodu: [důvod a výpovědní lhůta]. Stav projektu: [progres, horká místa, milníky]. Možný souběh (shadowing): [doba].

Sestav předávací složku s důrazem na to, co není v dokumentech: historie rozhodnutí a jejich skutečné důvody, ústní přísliby klientovi/sponzorovi, citlivá témata a nálady aktérů, rizika, která odcházející PM sleduje neformálně, reálný stav etap oproti oficiálnímu reportingu.

Naplánuj souběh: schůzky, kde odcházející osobně představí nástupce (sponzor, tým), pořadí témat dle naléhavosti a zprávu o změně, která uklidní okolí. Omezení: předání je ověřitelné – připrav seznam otázek, které musí nástupce umět na konci souběhu zodpovědět sám; co se nepodařilo předat, uveď jako seznam s kontaktem pro nouzi.

Začlenění nového člena do projektového týmu

Plán adaptace, který zajistí rychlou produktivitu bez přetížení zbytku týmu.

Připrav onboarding pro [jméno/role], který se připojuje k týmu projektu [název] dne [datum]. Stav projektu: [progres a kontext]. Očekávaná role: [úkoly]. Kapacita týmu pro doprovod: [reálné omezení].

Sestav plán na první 2 týdny: čtecí minimum pro první den (zakládací listina, poslední report, registr rizik, slovníček pojmů), 4 schůzky s klíčovými lidmi a jejich cíl, první užitečný a jasně ohraničený úkol hned v prvním týdnu (vyber dle role), a určený mentor s 10minutovým denním check-inem.

Omezení: zakaž kolečko 15 pasivních schůzek, nováček se učí prací; vysvětli, co se nováčkům neříká (vztahy, tabuizovaná témata, reálné rozhodovací cesty). Výstup: harmonogram 2 týdnů, seznam četby a otázky, na které musí nováček umět odpovědět po 15 dnech pro potvrzení adaptace.

Řešení konfliktu mezi členy projektového týmu

Třífázový mediační postup pro řešení sporů ohrožujících projekt.

Pomoz mi vyřešit konflikt v týmu. Kontext: [věcný popis sporu mezi dvěma lidmi bez soudů] na projektu [název]. Zjištěný dopad: [např. zadržování informací, napjaté porady, zpoždění]. Moje role: [vedoucí projektu, bez/s přímou podřízeností]. Historie: [jak dlouho to trvá, co se zkusilo].

Navrhni postup ve 3 krocích: 1. Individuální rozhovory (otázky pro pochopení verze každého, aniž bys stranil, pasti typu „dělání soudce“), 2. Společná schůzka (rámec úvodu, jak vracet diskuzi k faktům, jak dosáhnout shody na 2–3 pravidlech spolupráce), 3. Následné sledování (jak ověřit dodržování bez nápadného slídění).

Omezení: zůstaň v roli PM, věci patřící pod HR nebo liniový management identifikuj a předej, neřeš je; nikdo nesmí z procesu vyjít jako označený viník před týmem. Uveď signály, kdy je nutné eskalovat okamžitě.

Náprava nefungujícího externího dodavatele

Stupňovaný proces od věcného upozornění až po přípravu ukončení spolupráce.

Pomoz mi sjednat nápravu u dodavatele, který neplní závazky na projektu [název]. Dodavatel: [firma a služba]. Zjištěná pochybení: [datovaná fakta: zpoždění, nízká kvalita, výměna lidí, nesplněné sliby]. Smluvní rámec: [co říká smlouva: výstupy, termíny, sankce]. Závislost: [jak moc je nahraditelný].

Sestav stupňovaný plán: nejdříve schůzka k nápravě (faktický soupis odchylek mezi závazkem a realitou, datovaný a doložený; scénář schůzky vyžadující plán nápravy s termínem, ne omluvy), poté úzké sledování (krátké milníky, jasná kritéria konce krize, zápis po každém kontaktu), nakonec příprava alternativy, pokud náprava selže (začít diskrétně hned, pokud je závislost vysoká).

Omezení: vše stvrzuj písemně po každém ústním jednání (ochrana pro spor); zůstaň věcný a smluvní, žádné plané hrozby. Výstup: tabulka odchylek, e-mail s pozvánkou na schůzku, osnova jednání a objektivní kritéria pro ukončení spolupráce.

Zpracování zadávací dokumentace (Poptávka)

Zadání, které popisuje potřebu a omezení, aniž by diktovalo konkrétní řešení.

Sestav zadávací dokumentaci pro poptávku [předmět, např. nový web, implementace CRM] pro firmu [název]. Potřeba: [popis problému k řešení]. Technický a organizační kontext: [stávající stav, omezení]. Orientační rozpočet: [rozmezí v Kč, nebo neuvedeno]. Harmonogram: [termíny].

Struktura: představení firmy a kontextu (půl strany), problém k řešení a cíle formulované jako očekávané výsledky (popiš potřebu, ne řešení, pokud to není nutné), rozsah a výluky, nepodkročitelná omezení (technická, legislativní, termínová), požadované výstupy, kritéria výběru s váhou, proces výběrového řízení (dotazy, termín odevzdání, prezentace) a povinný formát nabídky pro snadné srovnání.

Omezení: každý požadavek musí být při dodání testovatelný; rozlišuj povinné požadavky a přání. Zakonči 5 otázkami pro prezentace, které odhalí, zda dodavatel skutečně pochopil zadání.

Srovnání nabídek dodavatelů v objektivní matici

Vážená analýza nabídek pro výběr nejvhodnějšího partnera bez emocí.

Sestav srovnávací matici pro nabídky na [předmět poptávky]. Nabídky: [počet a stručné shrnutí: cena, termín, přístup]. Co je pro nás klíčové: [priority, např. dodržení termínu, podpora, celkové náklady TCO, stabilita dodavatele]. Varovné signály: [např. podezřele nízká cena, obecná odpověď].

Sestav matici: kritéria ve skupinách (pochopení zadání, navržený přístup, reálný tým, celková cena včetně skrytých nákladů, srovnatelné reference, smluvní podmínky), váha kritérií dle priorit, bodová škála s popisem úrovní pro snížení subjektivity.

Aplikuj matici na popsané nabídky a upozorni na: nevysvětlené cenové rozdíly (nízká cena často maskuje malý rozsah), rozdíl mezi lidmi na prezentaci a lidmi na projektu, skryté provozní náklady. Výstup: vyplněná tabulka, doplňující dotazy pro každého dodavatele a argumentované doporučení v 5 řádcích.

Sestavení plánu řízení změn (Change Management)

Plán podpory uživatelů podle skupin, od interních ambasadorů po podporu po spuštění.

Sestav plán řízení změn pro [projekt, např. nový ERP, změna procesů] ve firmě [název]. Dotčené skupiny: [seznam, počet lidí a co se pro ně mění]. Očekávané obavy: [odpor]. Harmonogram nasazení: [klíčová data]. Dostupné zdroje: [čas, rozpočet, ambasadoři].

Pro každou skupinu definuj: co se konkrétně mění v jejich denní práci (přínosy I ztráty – zamlčené ztráty se později vymstí), úroveň potřebné podpory (info, školení, asistence) a klíčové sdělení z jejich pohledu.

Strukturuj plán v čase: Před (oznámení, síť ambasadorů vybraných pro jejich autoritu u kolegů, školení), Během (posílená podpora, sběr podnětů, viditelné řešení nahlášených chyb), Po (měření reálného používání, nikoliv jen účasti na školení, práce se zbývajícím odporem).

Omezení: žádný plán typu „více komunikovat“ bez určení obsahu; každá akce má garanta a datum. Výstup v tabulce po skupinách a souhrnný kalendář.

Návrh plánu školení koncových uživatelů

Systém vzdělávání podle rolí, zaměřený na reálné scénáře a měřený používáním.

Navrhni plán školení pro nasazení [nástroj/proces] ve firmě [název]. Uživatelé: [role, počty, IT zdatnost, lokalita]. Co musí každá role umět: [úkoly]. Omezení: [dostupnost lidí, rozpočet, termín spuštění].

Sestav systém školení podle rolí: pro každou 5–10 klíčových úkonů z jejich praxe (ne kompletní výčet funkcí), vhodný formát (krátký workshop, tutoriál, stínování u stolu), délka a podklady (taháky na jednu stranu místo tlustých manuálů).

Naplánuj školení co nejblíže spuštění: školení 6 týdnů předem se zapomene. Navrhni systém pro absentéry a lokální podporu (key-users) v každém týmu.

Omezení: měř úspěch podle reálného používání po spuštění (schopnost provést úkon, počet dotazů na support), nikoliv podle prezenční listiny. Výstup v tabulce po rolích a prioritizovaný seznam podkladů k vytvoření.

Krizová komunikace při incidentu na projektu

Zprávy pro různé cílové skupiny od prvního nahlášení po vyřešení.

Na projektu [název] došlo k vážnému incidentu: [popis, např. selhání migrace, ztráta dat, výpadek služby, kritické zpoždění]. Zjištěné dopady: [kdo a jak je zasažen]. Stav řešení: [co víme, co nevíme]. Cílové skupiny: [vedení, interní týmy, klienti, partneři].

Sestav sekvenci zpráv: 1. Rychlá první zpráva (co víme, co nevíme, co děláme a kdy podáme další info – slib čas příští zprávy, ne čas vyřešení), 2. Průběžné info v oznámeném rytmu i bez novinek, 3. Zpráva o vyřešení s opatřeními proti opakování.

Uprav zprávu pro každou skupinu: vedení chce dopady a rozhodnutí, uživatelé chtějí vědět, jak pracovat náhradně, klienti chtějí vědět, zda jsou v bezpečí. Omezení: žádné spekulace o příčině, žádné hledání viníka, žádný nesplněný slib termínu (ztráta důvěry). Výstup: hotové texty k úpravě a pravidla, kdo s kým mluví.

Tvorba týmových OKR (Objectives and Key Results)

Kvartální cíle a měřitelné klíčové výsledky v souladu s prioritami firmy.

Pomoz týmu [název] firmy [název] sestavit OKR na [kvartál]. Priority firmy: [priority]. Provozní úkoly týmu: [stálá činnost]. Plánované projekty: [nápady]. Počet lidí: [velikost].

Vytvoř max. 2–3 Cíle (Objectives): každý formulovaný jako inspirativní, ale konkrétní změna stavu (nikoliv seznam úkolů), navázaný na prioritu firmy. Pro každý cíl 2–4 Klíčové výsledky (Key Results): měřitelné s výchozí a cílovou hodnotou, měřící výsledek, nikoliv aktivitu („zkrátit dobu X na Y“, nikoliv „nasadit nástroj Z“).

Omezení: běžný provoz se nemění v OKR, ten se řídí bokem; klíčový výsledek, který neumíme změřit, přeformuluj nebo zruš; upozorni na cíle, které tým nemá pod kontrolou. Výstup: návrh OKR, otázky pro tým a rituál sledování: frekvence, 15minutový formát a co dělat, když výsledek stagnuje.

Moderování kvartální revize OKR

Upřímné zhodnocení kvartálu, ponaučení a příprava na další období.

Připrav revizi OKR týmu [název] za uplynulý kvartál. OKR: [seznam a stav plnění]. Klíčové události: [kontext: změny priorit, odchody]. Účastníci: [seznam]. Délka: [doba].

Strukturuj revizi do 3 částí: 1. Upřímné bodování výsledků na základě reálných čísel (nezměřený výsledek = nesplněný výsledek, žádné „skoro hotovo“), 2. Analýza odchylek (rozlišuj špatnou exekuci, přehnané ambice a vnější vlivy), 3. Rozhodnutí pro příští kvartál (co pokračuje, co končí, co měníme).

Omezení: revize není obhajoba, zakaž omáčku a jdi k číslům; cíl splněný na 100 % hned v prvním kvartálu značí nízkou ambici stejně jako 20 % značí problém v realizaci. Výstup: harmonogram, bodovací tabulka, otázky k analýze a osnova shrnutí pro zbytek firmy.

Vedení post-mortemu po incidentu bez obviňování

Analýza incidentu zaměřená na systémové příčiny a prevenci opakování.

Připrav post-mortem incidentu [popis] ze dne [datum] na projektu [název]. Chronologie: [průběh událostí s časy]. Zapojení lidé: [aktéři]. Atmosféra: [např. někdo se cítí ohrožen, vedení hledá viníka].

Strukturuj dokument a schůzku: faktická chronologie sestavená společně (hodinu po hodině, bez interpretací), analýza příčin jdoucí za hranici individuální chyby (lidská chyba je symptom: co ji umožnilo, co ji mělo zachytit?), co zafungovalo dobře při detekci a reakci, a nápravná opatření.

Pravidla úvodu: hledáme, jak systém dovolil incidentu nastat, ne kdo udělal chybu; ten, kdo přizná chybu, pomáhá všem a nesmí být trestán. Omezení: max. 5 akcí, každá s garantem a termínem, přednost mají ty, které chybu technicky znemožní, před těmi, které žádají „větší pozornost“. Výstup: osnova dokumentu a scénář schůzky.

Převod zkušeností do týmových standardů

Cesta od zapsaných ponaučení k reálně používaným pravidlům fungování.

Pomoz mi přetavit zkušenosti (Lessons Learned) týmu [název] do standardů fungování. Podklady: [zdroje: zápisy z retrospektiv, závěrečné zprávy, post-mortemy]. Současný problém: [např. stejné chyby se opakují, zprávy nikdo nečte].

Postupuj takto: seskup zkušenosti podle témat a najdi ty opakující se (priorita pro standardizaci), změň každou zkušenost v akční pravidlo s jasným spouštěčem („při každém startu projektu uděláme X“), a urči, kde tato pravidla budou žít, aby byla na očích: v šablonách dokumentů a checklistech, nikoliv v samostatném manuálu, který nikdo neotevře.

Omezení: celkem max. 10 pravidel, každé má svého správce; navrhni pololetní revizi pro mazání zbytečností (příliš tlustý manuál umírá). Výstup: navržená pravidla dle momentu použití, místo jejich integrace a zpráva pro tým.

Příprava na audit nebo revizi kvality projektu

Příprava podkladů, přiznání slabých míst a scénář rozhovorů s auditorem.

Připrav projekt [název] na audit/revizi, kterou provede [auditor: interní audit, klient, certifikační orgán] dne [datum]. Rozsah revize: [co se bude zkoumat]. Reálný stav: [silné/slabé stránky, stav dokumentace]. O co jde: [např. pokračování financování, certifikace ISO, důvěra klienta].

Zorganizuj přípravu: seznam referenčních dokumentů k sestavení (zakládací listina, rozhodnutí, registr rizik, zápisy, rozpočet) s označením těch, které pravděpodobně chybí nebo jsou neaktuální (priorita k doplnění), otázky, které auditor pravděpodobně položí, a pro každé slabé místo upřímnou pozici: přiznat ho, ukázat, že o něm víme a řídíme ho, předložit plán nápravy s termínem.

Omezení: nikdy nefalšuj dokumenty ani nedopisuj data zpětně; přiznané slabé místo s plánem působí lépe než prasklá fasáda při pohovoru; instruuj tým k faktickým odpovědím, ne k mlžení. Výstup: checklist složky, pravděpodobné otázky s odpověďmi a harmonogram přípravy.

Otestujte tyto prompty pro Projektové řízení na svých datech

Zkopírujte prompt do GPTPro a porovnejte odpovědi modelů Claude, GPT, Gemini a Mistral pro váš konkrétní případ.