Kdysi jsem se podílel na rozsáhlém projektu vybudování Centra sdílených účetních služeb pro jednu z největších polských společností. Složitost vyžadovala vytvoření několika projektových týmů, které se zabývaly účetními procesy, přípravou a vybavením místa, IT a HR. Celkem se do projektu zapojilo asi 50 lidí!
Naše cesta k plánování projektu dosáhla zásadního bodu během schůzky, na které projektový manažer představil plán projektu ve formátu, který byl vizuálně přitažlivý a velmi praktický – Ganttův diagram. Tento pečlivě vypracovaný plán, vytištěný na speciálním plotru a vystavený na stojanu, nabízel komplexní pohled na časový plán a úkoly projektu. Byl to převratný nástroj, který nám umožnil sledovat průběh projektu a efektivněji koordinovat naše úsilí.
Projektový manažer byl pyšný na „mistrovské dílo“, které vytvořil; nikdo z přítomných nikdy neviděl rozsáhlejší projektový plán. Počáteční nadšení a hrdost na komplexnost Ganttova diagramu však rychle vystřídaly problémy s jeho využitím pro efektivní řízení projektů.
Od té doby uplynulo mnoho let, během nichž jsem měl možnost řídit nejméně desítku velkých projektů – například budování informačních systémů, navrhování strategií pro velké společnosti, projekty optimalizace procesů ve firmách, vývoj a zavádění metodik a systémů pro řízení controllingových projektů ve velkých kapitálových skupinách atd. Na základě vlastních zkušeností, analýzy přečtených knih, odborných studií a článků jsem dospěl k následujícím závěrům ohledně efektivity používání Ganttova diagramu při řízení projektů.
Při pozorování různých projektových týmů je vidět, že postupují tak, že sestavují plán/harmonogram projektu ve formě Ganttova diagramu; často se tak děje bez důkladného pochopení toho, co by měl projekt nakonec přinést.
Přesto je možné sestavit „dobře vypadající“, ale obsahově chudý Ganttův diagram – má definované úkoly, milníky, vazby mezi úkoly, přiřazenou odpovědnost atd. – vypadá profesionálně. Problém je však v tom, že:
Cíl viditelný v mlze je obtížně navigovatelný, není ostrý. Totéž platí pro realizaci projektu. Vidět cíl projektu v mlhavé podobě znemožňuje vytvořit dobrý Ganttův diagram. Problém je v tom, že projektové týmy si to musí plně uvědomit a začít projekt s takto vytvořeným harmonogramem.
Poměrně rychle se například může ukázat, že harmonogram je třeba upravit, protože po prvním tzv. Business Project Review sponzor nebo vedení projektu zjistí, že jeho představa byla trochu jiná, a začne ji formulovat. V tu chvíli vedoucí projektu a jeho tým aktualizují Ganttův diagram a s největší pravděpodobností se ukáže, že spousta práce přišla nazmar. V důsledku toho jsme vyčlenili zdroje na zbytečné úkoly, což znamená, že nám vznikly zbytečné náklady. Je také možné, že projekt zdržujeme, a co je horší, motivace v týmu klesá.
Tomu se dalo snadno předejít, kdyby se na začátku věnovalo více času definování a dobrému pochopení účelu a rozsahu projektu. Téměř magickou otázkou, která řeší mnohé, ale málokdy se klade, je: „Co není v rozsahu projektu?“. Často je snazší pochopit rozsah projektu tím, že si probereme, co v něm není. A teď si představte, že aktualizujete „velký“ Ganttův diagram, věšíte ho na věšák, znovu tisknete – spousta frustrující a zbytečné práce – a přesto to není správná cesta.
Rád bych se na chvíli vrátil k příkladu uvedenému na začátku článku. „Velký“ Ganttův diagram zavěšený na věšáku na mapy je nepraktický. Řídit s ním projekt je příliš složité. Projektový manažer totiž předpokládá, že čím více Gantt zobrazuje všechny, i malé úkoly, tím je přesnější a efektivnější.
V praxi to má přesně opačný účinek. Takový plán bude vyžadovat trvalé změny. Sledovat stavy jednotlivých úkolů nebude snadné. Poměrně rychle se stane spíše „berličkou“ než nástrojem, který pomáhá úspěšně dokončit projekt. Alternativou je sestavení Ganttova diagramu, který se zaměřuje na „velké“ úkoly a tzv. dílčí úkoly nebo jednotlivé činnosti jsou v detailu hlavního úkolu – na Ganttově diagramu nejsou vidět. Výhodou takového přístupu je, že harmonogram je dobře čitelný a v důsledku toho vyžaduje méně významných změn, což z něj činí stabilnější plán projektu.
CEO FlexiProject