když jsem otevíral tuto sérii, nečekal jsem, že mi potrvá rok a půl, než se dostanu k napsání dalšího pokračování. ale život (a stejně tak i projekt) jde málo kdy tou naplánovanou cestou. ostatně proto máme change a risk management, ale o těch až někdy jindy 🙂

jak jsem slíbil, budu se v této sérii věnovat check-listům jako jednoduchému nástroji, jak neztratit přehled o stavu projektu a ohlídat všechno podstatné, aniž by člověk musel umět metodiku zpaměti. jako vhodný začátek se mi proto jeví „check-list řízení projektu“. průřezový dotazník, který může být takovou metodickou minipříručkou, nebo třeba základem pro audit projektu, do kterého člověk naskakuje během realizace.

metodické zázemí projektu

a protože je to check-list poměrně komplexní, budu se v tomto díle věnovat jen jeho první části, která zkoumá metodickou připravenost projektu. check-list sestává z celé řady otázek, každá otázka představuje jedno téma (v této části jednu metodickou oblast). při jeho procházení je třeba pouze odpovědět, zda je daná oblast v projektu vyřešena, případně do poznámky uvést jak, nebo například který dokument problematiku řeší. zní to jednoduše a odškrtání by mohlo vypadat jako rutina. aby byl ale smysl check-listu naplněn, je třeba, aby se ten, kdo ho vyplňuje, hlouběji zamyslel zda je skutečně řešení dané otázky či oblasti vhodné pro daný projekt, zda je pojato efektivně (zejména u metodik je třeba vyhnout se stavu, který nazývám „overkill efekt„, tj. stavu, kdy přečíst všechny metodiky trvá málem déle, než dokončit projekt, který mají řídit).

ale už k vlastním otázkám, které check-list v metodické části obsahuje.

je definována metodika řízení projektu?

klíč k úspěšnému řízení projektu, lhostejno jak rozsáhlého nebo komplikovaného, je mít vyjasněno, podle jakých principů a pravidel se mají všichni, kdo na projektu jakkoliv participují, chovat. u jednoduchého projektu na pár dnů může jít o jednu stranu flipchartu s poznámkami z úvodní schůzky projektového týmu, u komplexních projektů se může jednat o stovky stran metodických předpisů, pravidel a pomůcek. vždy je ale důležité, aby metodika existovala, a aby všichni účastníci projektu věděli, kde ji najdou a že se jí musí řídit.

je důležité metodiku vždy upravit na míru danému projektu a projektovému týmu, protože generická opatření nevhodná do konkrétní situace svádějí k odchylování se od metodiky, což – byť může být v jednotlivých případech přínosem – přináší do projektu kulturu nerespektování metodiky a tím je v celkovém pohledu škodlivé.

zodpovězení této otázky tedy směřuje nejen k samé existenci metodiky, ale i k její vhodnosti pro daný projekt a projektový tým. současně také otevírá možnosti případné „customizace“ pro její lepší ukotvení v centru projektu a jeho řízení.

je definována organizační struktura projektu?

základní úrovně organizace projektu by měly být jasně nastaveny už před jeho spuštěním. stejně tak musí být definovány i jednotlivé projektové role, jejich odpovědnosti a pravomoci, a komunikační kanály mezi nimi.

jasná definice v této oblasti přispívá významnou měrou k úspěchu projektu. naopak jakákoliv vágnost či dvojznačnost je skvělým základem na problémy. při řízení a realizaci projektu musí být jasné, co má kdo dělat. musí být také jasné, kdo má právo o čem rozhodnout, a každý problém musí mít vždy právě jednoho vlastníka. jinak se snadno stane, že některé otázky řeší všichni (pokud možno každý jinak, takže se stejně nic nevyřeší), a jiné naopak zůstávají zapomenuty a neřešeny, a to je přímá cesta do projektového pekla 😉

je definován a popsán proces řízení změn?

řízení změn je relativně standardní proces, na kterém není moc co vymýšlet, je poroto dobré stručně ho popsat, zakomponovat ho do modelu pravomocí a odpovědností projektového týmu (zejména jde o nastavení prahových hodnot pro jednotlivé typy rozhodování, aby jednoduché změny s minimálními dopady neparalyzovaly projekt, protože je musí schvalovat řídící výbor, který se schází jednou měsíčně, a to ještě jen když se zadaří).

je definován a popsán proces řízení rizik?

řízení rizik je celá velká samostatná kapitola řízení projektu. někdy se zdá, že se dokonce jedná spíše o umění, než o technickou disciplínu. přesto je nutné vědět, jakým způsobem bude k rizikům na projektu přistupováno, jak je nastaveno vnímání a tolerance rizika, jaké jsou rezervy v jednotlivých složkách projektového trojimperativu pro případ aktivace významných rizik, atd.

i tady samozřejmě platí, že složitost systému by měla plně korespondovat se složitostí řešeného problému, a je tak na citu a zkušenostech projektového manažera, jak moc bude řízení rizik formalizovat. rozhodnutí by to ale vždy mělo být vědomé.

je definován a popsán proces řízení dokumentace?

dokumentace. noční můra všech, kdo raději něco dělají, než vytvářejí stohy papíru popisující co že se to vlastně udělalo. přesto je řízení dokumentace důležitou disciplínou, a se vzrůstající komplexitou projektu a projektového týmu její význam narůstá.

projektový manažer by se měl proto ujistit, že jsou nastavena taková pravidla, která zajistí, že všechny důležité kroky projektu jsou řádně dokumentovány, že je dokumentace označována a ukládána tak, aby bylo možné ji kdykoliv později v případě potřeby bez velkého úsilí nalézt a použít. a v neposlední řadě by se měl projektový manažer ujistit, že jsou naplněny všechny požadavky odpovídajících zákonů, směrnice všech dotčených organizací, smluvní závazky a další požadavky, které jsou pro správu projektových dokumentů relevantní.

součástí metodiky by měla být i jasná ujednání o tom, jak se s dokumentací naloží po skončení projektu.

je definován reporting na projektu?

reporting je součástí komunikace projektu a jako takový vy měl být popsán v organizační struktuře a v procesu řízení dokumentace. jedná se ale o natolik stěžejní problém (a to jak uvnitř projektu, tak z pohledu vazby projektu na jeho sponzory a další stakeholdery), že se vyplatí věnovat samostatnou úvahu tomu, zda je skutečně jednoznačně popsáno, kdo co komu kdy reportuje, proč to dělá, a jak je s vytvořenými reporty nakládáno, tj. jakou přidanou hodnotu projekt získává vytvořením každého jednotlivého typu reportu.

cílem reportingu totiž není (nebo by alespoň nemělo být) zabavit manažery, aby se nepletli projektovému týmu pod nohy, případně utavit projektový tým a jednotlivé vedoucí pracovních skupin na formalistních cvičeních. reporting by měl sloužit efektivní komunikaci na všech úrovních řízení projektu a ničemu jinému. a podle toho by měl být navržen.

je definován proces řízení integrace mezi jednotlivými projekty?

ačkoliv by se mohlo zdát, že koordinace projektů je především problémem portfolio managementu, je ve složitějším prostředí, a zejména v situaci zásadních závislostí na výstupech jiných projektů, nebo při sdílení kapacity klíčových zdrojů (nebo dokonce konkurenčního usilování o ně) důležité, aby základní mechanismy pro přenášení informací mezi projekty byly pevně ukotveny v řídícím procesu projektu.

jakékoliv spoléhání na ad-hoc řešení by mohlo být pro projekt fatální, stejně jako přesunutí odpovědnosti za přenos informací do struktury řízení programu nebo projektového portfolia.