Jak vytvořit projektový plán: 7 kroků a příklady

Bent Flyvbjerg zkoumal 258 projektů ve 20 zemích v průběhu 70 let. U 9 z 10 projektů došlo k překročení rozpočtu. Náklady v průměru přesáhly odhady o 28 %.

Příčinou nebyla špatná realizace, ale to, jak týmy s plánem zacházely. Jednou ho sepsaly, nechaly schválit a pak ho přestaly používat. Když se situace změnila, plán zůstal stejný.

Většina plánů se už ve třetím týdnu přestane dodržovat. Byly vytvořeny proto, aby byly schváleny, nikoli použity. Zaměňují plánování (co dělat a proč) s časovým rozvrhem (kdy to udělat). A neobsahují jasný postup, jak zvládnout změnu rozsahu projektu, aniž by se plán zhroutil.

Tato příručka ukazuje, jak napsat projektový plán v sedmi krocích, které fungují v jakémkoli nástroji. Uvidíte také příklady z praxe z oblastí Waterfall, Agile, marketingu a stavebnictví. Navíc se podíváte na to, kde se plány ve skutečnosti nacházejí: v tabulkách, sdílených dokumentech a specializovaných nástrojích pro řízení projektů.

Co je to projektový plán?

Projektový plán je formální dokument, který popisuje, jak bude projekt realizován, monitorován a uzavřen. Zahrnuje rozsah, harmonogram, zdroje, rizika a komunikační postupy a slouží jako základ, od kterého se tým odvíjí, jakmile začne realizace.

Co projektový plán není

Projektový plán není totéž jako projektová charta. Charta schvaluje projekt a uděluje projektovému manažerovi pravomoci. Odpovídá na otázky „Měli bychom to udělat a kdo za to nese odpovědnost?“ Plán navazuje tam, kde charta končí, a odpovídá na otázky „Jak, kdy, kým a za jakou cenu?“

Projektový plán také není specifikací rozsahu. Specifikace rozsahu definuje, co projekt přinese a co ne. Říká vám, jak bude vypadat „hotový“ projekt. Projektový plán zahrnuje specifikaci rozsahu plus harmonogram, zdroje, rizika, komunikaci a řízení změn. Říká vám, jak se tým k cíli dostane, kdo co dělá a co se stane, když dojde ke změně.

5 fází projektového plánu

Projektový plán zahrnuje pět fází, které Project Management Institute (PMI) definuje jako životní cyklus projektu: zahájení, plánování, realizace, sledování a řízení a uzavření.

Samotný plán vzniká ve fázi plánování, ale aktivně se využívá i během fáze realizace a monitorování. Plán, který končí s ukončením fáze plánování, je plán, který se brzy opustí.

Proč je projektový plán důležitý?

Pokud plán vynecháte, budou se stále opakovat stejné problémy. Rozšiřování rozsahu projektu, protože nikdo nedefinoval hranice, konflikty zdrojů, protože dva pracovní toky si nárokovaly stejného inženýra, a nedodržení termínů, protože se pozdě objevily skryté závislosti.

Projektový plán těmto selháním předchází tím, že zviditelňuje práci ještě před zahájením realizace.

Plán je výchozí bod, nikoli přesná předloha

Většina projektových manažerů považuje plán za dokument určený k předání. Vypracujete jej, abyste zainteresovaným stranám ukázali, co vytvoříte, a aktualizujete jej pouze tehdy, když k tomu budete donuceni. Výsledkem je tak pouze momentální snímek, nikoli nástroj pro rozhodování.

Skutečným úkolem projektového plánu je poskytnout vám konkrétní oporu, o kterou se můžete opřít, když se budoucnost vyvine jinak, než jste očekávali. Žádosti o změnu rozsahu se posuzují podle výchozího stavu, nikoli podle pocitu. Zpoždění v harmonogramu se měří podle plánu, nikoli podle vzpomínek. Úspěšný je ten plán, který se aktualizuje při každém milníku.

Z toho vyplývají dvě pravidla, na nichž je založena zbývající část tohoto průvodce:

Tento přístup řeší to, co Flyvbjerg nazval optimistickým zkreslením: systematickou tendenci plánovačů podceňovat náklady, časové harmonogramy a rizika a zároveň přeceňovat přínosy. Plány vytvořené jako statické předpovědi toto zkreslení přebírají již od prvního dne a nikdy jej nekorigují.

Klíčové složky projektového plánu

Každý projektový plán, ať už je obecný nebo velmi podrobný, vychází ze stejných základních složek. Níže uvedený seznam zahrnuje všechny tyto složky a to, co by měly obsahovat.

Ne každý projekt však vyžaduje všech osm částí v stejné podrobnosti. U dvoutýdenního interního projektu lze některé části sloučit do jedné stránky. U projektu v regulovaném odvětví, například u iniciativy zaměřené na dodržování předpisů ve farmaceutickém průmyslu, lze každou část rozvést do samostatného poddokumentu s formálními schvalovacími kroky.

Jak vypracovat projektový plán v 7 krocích

Těchto sedm kroků funguje bez ohledu na použitou metodiku: Waterfall, Agile nebo hybridní. Pořadí je důležité, protože každý krok navazuje na ten následující. Přeskočení některého kroku vede k dodatečné práci, která je nákladnější než správné naplánování hned napoprvé.

Krok 1: Definujte své cíle a identifikujte zainteresované strany

Začněte svými cíli. Nejčastější chybou při plánování je přejít rovnou k otázce „co musíme udělat?“, aniž byste si nejprve odpověděli na otázku „jak vypadá úspěch?“. Každý cíl spojte s měřitelným výsledkem a termínem.

Například „Přepracovat webové stránky“ je úkol. „Zvýšit konverzní poměr na stránce s cenami o 15 % do 3. čtvrtletí“ je cíl, který určuje všechna následná rozhodnutí.

Dále si sepište všechny osoby, které mají v rámci projektu pravomoc, vliv nebo na něm závisí. Roztřiďte je podle rolí. Sponzor schvaluje změny rozpočtu a rozsahu, spolupracovníci vykonávají práci a informované strany potřebují aktuální informace, ale nerozhodují. Jednoduchá mapa zainteresovaných stran vám pomůže udržet v tom pořádek.

Krok 2: Stanovte rozsah projektu a výstupy

Rozsah představuje hranici. Vše, co se nachází uvnitř, je zajištěno zdroji a naplánováno; vše, co je mimo, je výslovně odloženo nebo zamítnuto. Dvousloupcový seznam „v rozsahu/mimo rozsah“ zabraňuje nejednoznačnosti, která později způsobuje rozšiřování rozsahu.

Rozlišujte mezi výstupy projektu a úkoly. Výstup je hmatatelný výsledek, který obdrží zainteresovaná strana: „migrovaná databáze“, „schválený návrh makety“, „zveřejněná dokumentace API“. Úkoly jsou práce potřebné k jeho vytvoření. Toto rozlišení je důležité, protože zainteresované strany se zajímají o výstupy; váš tým se zajímá o úkoly.

Nejčastější chyba při definování rozsahu projektu? Stanovení hranic tak široce, že je nelze použít k odmítnutí dodatečných požadavků.

„Zlepšit uživatelský zážitek“ může znamenat cokoli. „Přepracovat proces platby pro mobilní prohlížeče, s vyloučením rozvržení pro tablety a změn poskytovatelů platebních služeb“ vám dává zdokumentovaný důvod, proč odmítnout požadavek na podporu tabletů uprostřed projektu.

Krok 3: Vytvořte strukturu rozdělení práce

Vezměte každý výstup z kroku 2 a rozdělte jej na nejmenší úkoly, které lze jednotlivě přidělit, odhadnout a sledovat. Tato hierarchie – projekt -> výstup -> pracovní balíček -> úkol – představuje vaši strukturu rozdělení práce (WBS).

Užitečné pravidlo: pokud úkol trvá déle než několik dní, lze jej pravděpodobně dále rozdělit na menší části.

WBS je základem harmonogramu a plánu zdrojů. Pokud je neúplná, vše, co na ni navazuje, je nespolehlivé. Váš harmonogram bude nesprávný, protože vám unikly některé práce, a váš plán zdrojů bude mít mezery.

Takto by to například vypadalo v ClickUp:

Krok 4: Vytvořte harmonogram projektu a milníky

Vezměte si úkoly ze své struktury WBS a seřaďte je podle pořadí: které úkoly závisí na tom, že budou nejprve dokončeny jiné (závislosti), a které lze provádět souběžně.

Milníky projektu označují dokončení hlavních fází nebo výstupů. Jedná se o kontrolní body: „fáze návrhu dokončena“ nebo „obdržen souhlas s UAT“. Využijte je k vytvoření přirozených bodů pro revizi se zainteresovanými stranami. U složitých projektů vizualizujte harmonogram pomocí Ganttova diagramu, aby byly jasně patrné závislosti a kritická cesta.

Do harmonogramu si vytvořte rezervu pro reálné nepředvídané okolnosti. Poté přidejte rezervu v rámci jednotlivých fází, zejména při testování a revizi, namísto toho, abyste ji zařadili jako celek na konec, kde bude pod tlakem zkrácena.

Krok 5: Přidělte role a alokujte zdroje

Každý úkol z WBS přiřaďte konkrétnímu odpovědnému pracovníkovi. Sdílená odpovědnost znamená žádnou odpovědnost. Přidělení zdrojů znamená ověření, že přidělení pracovníci mají v plánovaném časovém rámci volnou kapacitu.

Právě zde se plány střetávají s realitou. Váš vedoucí vývojář může být přidělen ke třem projektům současně. Plán tento konflikt odhalí ještě předtím, než způsobí nedodržení termínu.

Rámec RACI (Responsible, Accountable, Consulted, Informed) jasně určuje, kdo co dělá, aniž by docházelo k nadměrné dokumentaci. Pokud projekt vyžaduje nový software nebo dodavatele, schvaluje se to společně s plánem.

Krok 6: Posouzení rizik a plánování komunikace

Zjistěte, co by se mohlo pokazit, posuďte pravděpodobnost a dopad každého rizika a zdokumentujte opatření pro každé z nich.

Zaznamenejte běžná projektová rizika do registru rizik, aby byla viditelná a aby za ně někdo nesl odpovědnost. Zde je příklad.

Krok 7: Získejte souhlas zainteresovaných stran a stanovte výchozí stav

Plán není konečný, dokud jej sponzor a klíčové zainteresované strany formálně neschválí. Tímto schválením vzniká výchozí stav projektu: dohodnutý rozsah, harmonogram a rozpočet, podle nichž se posuzují všechny budoucí změny.

Bez výchozího stavu není možné odlišit oprávněnou změnu od původní dohody.

Jakmile je plán stanoven, jakákoli změna rozsahu, časového harmonogramu nebo rozpočtu prochází procesem řízení změn, který jste v plánu definovali. Sdílejte schválený plán se všemi zúčastněnými stranami. Uložte jej na sdílené místo s kontrolou verzí, které je vždy přístupné. Ne někde zapadlé v e-mailové konverzaci z před třemi měsíci.

Příklady projektových plánů

Níže uvedené příklady ukazují, jak se stejné základní komponenty přizpůsobují různým kontextům. U každé z nich je popsána její struktura, v čem spočívá její specifika a kdy ji použít.

Příklad projektového plánu podle vodopádového modelu

Plán podle modelu „vodopádu“ postupuje v následujícím pořadí: požadavky, návrh, vývoj, testování, nasazení. Každá fáze končí formálním milníkem. Zainteresované strany práci zkontrolují a schválí další fázi. Dokud není předchozí fáze schválena, nic se neposune dál.

Příklad postupu:

V čem spočívá jeho odlišnost: Celý rozsah projektu je pevně stanoven již ve fázi definice požadavků. Hlavním výstupem je Ganttův diagram, který znázorňuje jednotlivé fáze v chronologickém pořadí. Žádosti o změny jsou formální a nákladné. Metodika Waterfall upřednostňuje předvídatelnost na úkor flexibility.

Nejvhodnější pro: Projekty s pevně danými požadavky, pravidly a předpisy nebo externí týmy, které potřebují pevně stanovený rozsah. Hodí se zejména pro vládní zakázky, práci v oblasti dodržování předpisů a výrobu.

Není vhodné, pokud: Na začátku projektu nedokážete s vysokou jistotou definovat, co znamená „hotovo“. Zafixování rozsahu, kterému nerozumíte, vás vyjde dražší než postupné zdokonalování.

Příklad agilního projektového plánu

Agilní plán stanoví vizi produktu, seřazený seznam úkolů (backlog), délku sprintu (obvykle dva týdny) a role v týmu. Podrobný plán se rozvíjí sprint po sprintu. Tým se z každého kola poučí a provádí úpravy.

Příklad postupu:

V čem spočívá jeho jedinečnost: Plán nezamyká rozsah práce za hranicemi následujícího sprintu. Zainteresované strany vidí plán témat po čtvrtletích, nikoli seznam výstupů po jednotlivých sprintech. Retrospektiva představuje smyčku zpětné vazby. Bez ní se agilní přístup promění v postupné rozšiřování rozsahu s nadbytečnými kroky.

Nejvhodnější pro: Projekty, u nichž se mění potřeby, práce se řídí zpětnou vazbou od zákazníků nebo tým dodává v malých dávkách. Agilní přístup je běžný v oblasti softwaru, produktového designu a interních nástrojů.

Tento postup přeskočte, pokud: zainteresované strany vyžadují předem stanovený rozsah a termín. Flexibilita agilního přístupu vám může uškodit, pokud je smlouva striktně daná.

Příklad projektového plánu marketingové kampaně

Multikanálová marketingová kampaň spojuje obsah, placená média, e-mail a akce. Vytváří kreativní výstupy s cykly revizí, koordinuje externí dodavatele (agentury, nezávislé pracovníky) a sjednocuje všechny kanály do jednoho data spuštění.

Příklad postupu:

V čem spočívá jeho výjimečnost: Marketingové plány mají více zainteresovaných stran, které mají své názory, než těch, které mají rozhodovací pravomoci. Bez jasného schvalovacího postupu prochází každý materiál pěti koly úprav a termín spuštění se posouvá. Matice RACI zde není volitelná. Právě ona chrání termín spuštění.

Další specifické riziko: Kanály se sbíhají v jeden termín, ale každý z nich má jinou dobu realizace. Tisk potřebuje šest týdnů. Placená reklama na sociálních sítích potřebuje dva. E-mail potřebuje jeden. Pokud plánujete dopředu od zahájení projektu namísto zpětně od spuštění, kanály s dlouhou dobou realizace mají zpoždění již od prvního dne.

Nejvhodnější pro: Uvedení produktů na trh, sezónní kampaně, rebranding nebo jakoukoli práci, která probíhá ve více než dvou kanálech ve stejný den.

Tuto část přeskočte, pokud: Provozujete program na jednom kanálu, který běží nepřetržitě (například pouze blog nebo pouze placený účet). V takovém případě vám postačí obsahový kalendář a týdenní kontrola. Kompletní plán kampaně by pro vás představoval zbytečnou zátěž, kterou nevyužijete.

Příklad plánu stavebního projektu

Stavební projekty se řídí přísnými pravidly (povolení, kontroly) a jsou vázány na konkrétní fyzické podmínky. Nelze provést elektroinstalaci dříve, než je hotová hrubá stavba.

Příklad postupu:

V čem spočívá jeho výjimečnost: Hlavním rizikem je harmonogram, nikoli rozsah projektu. Zpoždění v jedné fázi má dopad na všechny následující fáze. Pokud se montáž kostry zpozdí o týden, posunou se i elektroinstalace, instalatérské práce a vzduchotechnika. Stavební plány počítá s časovou rezervou uvnitř každé fáze, nikoli na jejím konci. Proč? Rezerva na konci projektu je vždy vyčerpána kroky, které se zpozdily již dříve.

Vhodné zejména pro: Jakoukoli práci, která zahrnuje fyzické závislosti, rizika spojená s počasím nebo koordinaci více řemesel.

Tuto část přeskočte, pokud: Zabýváte se znalostní prací. Využívání těžkých bran ze stavebnictví pro marketingovou kampaň zvyšuje náklady, aniž by poskytovalo skutečnou ochranu.

Nezačínejte svůj další projekt od prázdné stránky. Šablona projektu na vysoké úrovni od ClickUp vám nabízí hotovou strukturu se stavy úkolů, vlastními poli pro sledování schválení a přidělení úkolů členům týmu a pěti vestavěnými zobrazeními, včetně časové osy a seznamu výstupů.

Získejte šablonu zdarma

Kde by měly být projektové plány uloženy?

Metoda určuje, jak budete práci rozvrhovat. Nástroj rozhoduje o tom, zda plán přežije i po třetím týdnu. Máte tři možnosti.

Tabulkové procesory (Google Sheets, Excel)

Jedná se o standardní nástroje pro týmy, které vždy používaly tabulkové procesory. Jedna tabulka pro úkoly, jedna pro časový plán, jedna pro registr rizik. Každý může provádět úpravy. Nic se neporouchá, pokud je někdo offline.

Co funguje

Kde to selhává

Vhodné pro: Projekty s jedním týmem, které obsahují méně než 20 úkolů, mají jednoho jasně určeného vlastníka a neobsahují vnořené závislosti.

Tento krok přeskočte, pokud: Je třeba koordinovat více než dva týmy nebo se časový harmonogram mění častěji než jednou týdně.

Sdílené dokumenty (Google Docs, Notion, Confluence, ClickUp Docs)

Plán založený na dokumentu funguje, pokud je plán převážně psán formou prózy: popis rozsahu, mapa zainteresovaných stran, kritéria úspěchu a registr rizik. Úkoly jsou uvedeny v odrážkových seznamech s uvedením odpovědných osob a termínů.

Co funguje

Kde to selhává

Nejvhodnější pro: Krátké projekty (do jednoho měsíce), plány s velkým podílem textu nebo jako úvodní část k nástroji pro sledování úkolů. Rozsah projektu a zúčastněné strany jsou uvedeny v dokumentu. Úkoly jsou uloženy jinde.

Tuto část přeskočte, pokud: Potřebujete zjistit, kdo a v čem má dnes překážky.

Specializované nástroje pro řízení projektů (ClickUp, Asana, Jira, Monday)

Speciálně navržené systémy, ve kterých úkoly, závislosti, odpovědné osoby a časové osy sdílejí jeden datový model. Plán a práce představují jeden a tentýž objekt.

Co funguje

Kde to selhává

Nejvhodnější pro: Projekty, na kterých spolupracují více týmů, které mají proměnlivé závislosti a které vyžadují výchozí základ, který obstojí i při změnách rozsahu.

Tuto část přeskočte, pokud: Jedná se o jednoduchý projekt s jedním vlastníkem, jedním týmem, pevně stanoveným rozsahem a trváním kratším než tři týdny. V takovém případě je rychlejší použít dokument.

6 důvodů, proč projektový plán selže

Většina projektových plánů ztrácí na dynamice z předvídatelných důvodů.

1. Formulujte rozsah tak široce, aby nebylo možné ho odmítnout

Rozsah projektu je užitečný pouze tehdy, pokud vám poskytuje zdokumentovaný důvod k odmítnutí dodatečných požadavků. Pokud nemůžete odkázat na dokument s rozsahem projektu a říci: „To je mimo rozsah“, je rozsah příliš vágní na to, aby projekt ochránil.

Každou hranici rozsahu projektu formulujte jako testovatelné tvrzení. „Přepracovat proces platby pro mobilní prohlížeče, s výjimkou rozvržení pro tablety a změn poskytovatelů platebních služeb“ je hranice. „Zlepšit uživatelský zážitek“ jí není.

2. Získávání odhadů od manažerů

Odhady sestavované shora dolů jsou vždy příliš optimistické. Jedná se o již zmíněnou „optimistickou zaujatost“, která se v tomto případě projevuje právě při odhadech. Osoba, která práci přiděluje, ji téměř vždy podceňuje ve srovnání s osobou, která ji vykonává.

Vývojář, který práci provádí, ví, kde se skutečně vyskytují problémy. Vytvořte WBS společně, jinak počítejte s nutností oprav.

3. Shromáždění všech rezerv na konec

Harmonogram, který na konci čtyřměsíčního projektu počítá s dvoutýdenní „rezervou“, je harmonogram bez skutečné rezervy. Právě tato rezerva se totiž jako první omezí, jakmile se zvýší tlak.

Do jednotlivých fází, zejména do testování a revize, kde se obvykle spotřebovává, přidejte rezervní čas. Rezerva, která je součástí práce, zůstává zachována. Ta, která je umístěna na konci, zmizí dříve, než ji projekt potřebuje.

4. Nedefinování pojmu „hotovo“

Pokud nejsou specifikována kritéria dokončení, má pojem „hotovo“ pro každého zúčastněného něco jiného:

U každého výstupu si zapište, co znamená „hotovo“. Poznamenejte si, jaká kritéria by měl splňovat, v jakém formátu bude a kdo jej schválí. Nejasná kritéria jsou hlavní příčinou dodatečných úprav v pozdější fázi projektu.

5. Uložení plánu jako přílohy e-mailu

Plán, který nikdo nemůže najít, je v podstatě totéž jako žádný plán.

Pokud se tým musí ptát, kde je aktuální verze, nebude se podle ní při rozhodování řídit, nevšimne si, když bude zastaralá, ani ji neaktualizuje, když se změní skutečná situace.

Plán uložte tam, kde tým pracuje, zajistěte jeho verzování a propojte jej s úkoly, které řídí. Plán by měl být dostupný pouhými dvěma kliknutími z pracovního prostoru každého člena týmu.

6. Považování plánu za jednorázový dokument

Nejrychlejší poznávací znak: Datum poslední úpravy plánu je starší než nejnovější úkol, který jste přidali. Pokud se práce posunula a plán nikoli, plán přestal projekt řídit již před nějakou dobou a nikdo si toho nevšiml.

Vyhraďte si 15 minut na revizi plánu při každém milníku a pokaždé, když bude schválena žádost o změnu. Nejde o to, abyste plán přepisovali od začátku. Cílem je ověřit, zda základní plán stále odpovídá skutečnosti, nebo zdokumentovat, kde tomu tak není.

Jak v ClickUp vytváříme a spravujeme projektové plány

My projektové plány nepíšeme do Google Docs a nespoléháme se na to, že to nějak dopadne. Naše plány jsou uloženy přímo v ClickUp, hned vedle úkolů, které popisují. Díky tomu plán nikdy neztrácí aktuálnost.

Dokumenty k rozsahu projektu a mapa zainteresovaných stran (kroky 1 a 2)

ClickUp Docs obsahuje popis rozsahu projektu, metriky úspěchu a tabulku zainteresovaných stran. Jelikož se tento dokument nachází ve stejném pracovním prostoru jako úkoly, je snadné odpovědět na otázku „spadá to do rozsahu projektu?“. Když někdo navrhne změnu, odkážeme ho na ten samý dokument, který schválil zadavatel, a ne na dokument Google Docs starý tři měsíce.

Úkoly a podúkoly pro WBS (krok 3)

Ganttův diagram pro závislosti a kritickou cestu (krok 4)

<14>V zobrazení Gantt v ClickUp přetáhněte čáru mezi úkoly a nastavte tak závislost. Kritická cesta je viditelná a pokud dojde ke zpoždění jednoho úkolu, posunou se s ním i následující úkoly. Harmonogram zůstává realistický, aniž by ho někdo musel ručně upravovat. Právě v tomto bodě selhávají tabulkové kalkulátory nejčastěji, a právě díky tomu si nástroje pro řízení projektů zaslouží své místo.

Přehledové panely pro výchozí stav (krok 7)

Jakmile sponzor plán schválí, řídicí panely ClickUp načtou aktuální data o míře dokončení, úkoly po termínu a pracovní zátěži. Odpověď na otázku „kde jsme?“ vychází ze stejných dat, na kterých tým pracuje, nikoli z paralelního dokumentu o stavu. Zainteresované strany si zkontrolují řídicí panel, místo aby žádaly o schůzku k projednání stavu.

Kdy není ClickUp tou správnou volbou

ClickUp se osvědčí zejména u projektů, na kterých se podílí více lidí, s proměnlivými termíny a mezifunkčními předávkami. Čím více je vaše práce propojená, tím větší přínos z něj získáte.

Tento kurz přeskočte, pokud: Jste freelancer, který sleduje jen několik výstupů, nebo tým, který potřebuje komplexní finanční modely a kontingenční tabulky. V takovém případě by vám lépe posloužil jednoduchý dokument nebo tabulkový procesor.

Vytvořte projektový plán, který bude váš tým skutečně využívat

Projektový plán funguje pouze tehdy, když zachycuje ucelený obraz: všechny výstupy, odpovědné osoby, závislosti a rizika na jednom místě. Navíc je nutné se jím řídit během práce a nezapomenout na něj již při dosažení prvního milníku.

V rámci stovek projektů týmy, které projekty úspěšně dokončují, vždy považují své plány za živé dokumenty. Při každém milníku je revidují, při změně podmínek aktualizují předpoklady a každou žádost o změnu rozsahu projektu řeší prostřednictvím zdokumentovaného procesu změn. Právě to udržuje projekty na správné cestě.

Pokud váš tým již překročil možnosti sdílených dokumentů a základních tabulek, vyplatí se vyzkoušet nástroj jako ClickUp. Můžete tak mít rozsah projektu, úkoly, závislosti, odpovědné osoby a přehledové panely na jednom místě, přičemž zobrazení se synchronizují s vývojem plánu.

Zaregistrujte se do ClickUp ještě dnes!

Často kladené otázky týkající se projektových plánů

Jaký je rozdíl mezi projektovým plánem a plánem řízení projektu?

Projektový plán se zaměřuje na konkrétní výstupy, harmonogram a zdroje pro jeden konkrétní projekt. Plán řízení projektu (termín používaný organizací PMI) má širší záběr a zahrnuje dílčí plány týkající se řízení změn, rizik, komunikace a zadávání zakázek, které určují, jakým způsobem je projekt řízen. Pro většinu týmů mimo formální prostředí PMI zahrnuje pojem „projektový plán“ obojí.

Je možné vytvořit projektový plán bez softwaru pro řízení projektů?

Ano, u krátkých projektů s jedním odpovědným a méně než asi 20 úkoly. Sdílený dokument s popisem rozsahu, seznamem zainteresovaných stran a jednoduchou tabulkou odpovědných osob a termínů je rychlejší než nastavení nástroje pro řízení projektů. Rozhodujícím faktorem jsou obvykle závislosti mezi týmy: když je třeba koordinovat více než dva týmy, tabulka začíná ztrácet přesnost.

Co je to kritická cesta v projektovém plánu?

Kritická cesta je nejdelší řetězec závislých úkolů ve vašem harmonogramu, který určuje nejbližší možný termín dokončení projektu. Jakékoli zpoždění úkolu na kritické cestě zpozdí celý projekt; zpoždění u nekritických úkolů lze kompenzovat pomocí časové rezervy. Ganttovy diagramy znázorňují kritickou cestu, takže projektoví manažeři vědí, která zpoždění skutečně mají význam a která nikoli.

Kdo je zodpovědný za vypracování projektového plánu?

Projektový manažer je zodpovědný za plán, neměl by jej však sestavovat sám. Odborníci v dané oblasti poskytují odhady náročnosti úkolů, zadavatel schvaluje rozsah a rozpočet a spolupracovníci ověřují závislosti. Plány sestavené shora dolů bez zapojení lidí, kteří práci skutečně vykonávají, důsledně podceňují náročnost projektu – tento vzorec dokumentuje výzkum Benta Flyvbjerga na základě tisíců projektů.

Jaký je rozdíl mezi projektovým plánem a harmonogramem projektu?

Projektový plán definuje, co se bude dělat, kdo to bude dělat, za jakou cenu a jak se budou řídit rizika. Projektový harmonogram je jednou ze složek plánu, která mapuje, kdy se úkoly budou provádět a v jakém pořadí. Smíchání těchto dvou prvků vede k tomu, že časové osy určují rozsah projektu namísto opačného postupu, což je jednou z nejčastějších chyb při plánování.

Jak často byste měli aktualizovat projektový plán?

Projektový plán byste měli aktualizovat při každém významném milníku a vždy, když je schválena žádost o změnu. Plán, který ve třetím měsíci odráží předpoklady z prvního týdne, vyvolává falešný pocit jistoty. PMI doporučuje formální revize plánu při každé fázi projektu, s ad hoc aktualizacemi v případě, že se rizika projeví nebo jsou schváleny změny rozsahu prostřednictvím procesu řízení změn.