Problém ale není jen v ignorování obecně platných pravidel, ale i v obsazování nekompetentních osob na klíčové pozice, v nedostatečné schopnosti zvážit rizika ohrožující jednotlivé projekty či ve stanovení postupů, jak taková rizika eliminovat. Zkrátka jednotlivé chyby se na sebe nabalují jak slupky od cibule a jak už to u cibule chodí, k slzám dříve či později není daleko.
V našem článku jsme se proto zaměřili na 13 nejčastějších chyb, kterých se IT oddělení při řízení projektů dopouští. Může vám to pomoci určit zranitelná místa IT projektu a opatření k jejich nápravě. Pokud se totiž vesměs katastrofálním následkům chybného plánování včas nepředchází, projekt s největší pravděpodobností skončí ve velmi drahé pasti.
Chyby v lidských zdrojích
Chyba č. 1: Projekt nedisponuje lidským kapitálem s požadovanými znalostmi a dovednostmi.
Důsledek: Nesprávně alokovaný lidský kapitál figuruje na předních pozicích žebříčku nejběžnějších chyb projektového managementu. Absence akceschopného týmu dokáže projekt rychle potopit.
Řešení: Je zapotřebí, aby projektoví a IT manažeři měli absolutní přehled o dovednostech a pracovním zatížením svěřených zdrojů, a to včetně sítě konzultantů, dodavatelů a outsourcingu. Zrovna ti podle expertů zůstávají velmi často ohledně zkušeností pozadu, a to i přesto, že na samotných projektech mnohdy odvedou obrovský kus práce. Právě zde se objevuje prostor pro implementaci aplikace, která projektovému managementu poskytne plný přehled znalostí, zkušeností, dovedností a pracovního vytížení jednotlivých účastníků projektu.
Ve chvíli, kdy IT a projektoví manažeři vědí, kdo a co umí, je zapotřebí rozvrhnout, jak alokovat zdroje napříč projektem až na úroveň jednotlivých dnů.
Zde lze využít mnoha druhů organizačních modelů, Richard Scannell, spoluzakladatel společnosti GlassHouse Technologies, navrhuje formovat tzv. „tiger team“, v jehož rámci jsou zaměstnanci na rok či více vyjmuti z běžného pracovního procesu za účelem práce na zcela specifickém projektu. Ken Cheney, ředitel společnosti HP Software PPM Center, zdůrazňuje, že problém v podobě omezené kapacity zaměstnanců zapojitelných do projektu lze řešit pozastavením či zrušením „volnějších“ aktivit (například takových, které nejsou úzce spjaty s podnikovou strategií). Doporučuje shlédnout portfolio veškerých podnikových projektů a následnou identifikaci těch, které nejsou pro společnost primárně důležité. Pozastavení takových projektů a relokace zdrojů z nich získaných umožní společnosti jako celku být pružnější a úspěšnější.
Chyba č. 2: Projekt nedisponuje zkušenými projektovými manažery.
Důsledek: Bez zkušeného, důvtipného a inteligentního manažera se může řízení projektu velmi rychle vymknout kontrole.
Řešení: Vyhledejte certifikovaného projektového manažera s odbornou kvalifikací k řízení lidských zdrojů. Metthew Strazza, viceprezident společnosti CA, říká, že dobrý projektový manažer musí mít silné osobní zkušenosti. Takoví lidé ví, jak vést úspěšná jednání, zvládat krizové situace a kterak komunikovat s nejrůznějšími zainteresovanými skupinami – obchodníky, které zajímá funkční stránka projektu, lidmi z IT oddělení, kteří dbají na bezpečnost, a v neposlední řadě i s finančními orgány, které dohlížejí na rozpočet.
Strazza taktéž zdůrazňuje, že jisté problémy lze eliminovat pravidelnou komunikací s investory, plánováním rozpočtu na tzv. week-to-week základě a uvědomováním klienta o sebemenší změně v projektu. Zároveň zastává názor, že dobrý projektový manažer musí mít odborné technologické znalosti z relevantního oboru.
Chyby v postupu
Chyba č. 3: IT oddělení neuplatňuje základní postupy projektového managementu.
Důsledek: Jedná se o druhou nejčastější chybu projektového managementu. Absence metodologie zvyšuje riziko, že úkoly s projektem spojené bude nutné přepracovat. To může v posledku znamenat značné překročení časového a rozpočtového rámce projektu.
Řešení: Vypracování metodologie projektového managementu vám umožní efektivní start a hladký průběh projektu. Zároveň podá jednoduchý přehled všech aktivit spojených s vypracováním daného projektu.
Možnost disponovat vypracovanou základní kostrou projektu a metodologií odstraňuje podle Cheneyho vznik mnohých možných rizik.
Douglas Clark, výkonný ředitel společnosti Métier, doporučuje zavést standardizované procesy pro schvalování, plánování, alokaci zdrojů a komunikaci s partnery. „To jsou věci, které je zapotřebí zařídit co nejdříve, protože se jejich využití velmi pravděpodobně značně vyplatí.“
Chyba č. 4: IT oddělení je zahlceno mnoha procesy.
Důsledek: Spuštění mnoha procesů najednou má za následek zcela neflexibilní projektový tým, jehož nepružnost frustruje zejména projektové partnery.
Fumi Kondová, generální ředitelka konzultační společnosti Intellilink Solutions, jednou vyslechla rozhovor mezi softwarovým vývojářem a projektovým manažerem, kdy vývojář navrhl, že by mohl do aplikace, na které právě pracuje, přidat bez jakéhokoliv úsilí funkci navíc. Projektový manažer zakázal tuto funkci přidat, protože o ni zákazník nepožádal. Moje odpověď by byla: „Obraťte se na uživatele aplikace a zjistěte, zda by pro něj taková funkce byla užitečná či vítaná,“ říká Kondová. „Na dodání něčeho navíc nevidím nic špatného, dokud není narušen původní časový plán nebo rozpočet.“
Řešení: Buďte flexibilní a komunikativní vůči investorům a partnerům zainteresovaným do projektu.
Chyba č. 5: IT nesleduje vliv dílčích změn na rámec celého projektu.
Důsledek: Rozpočet projektu i časový harmonogram bude překročen.
Řešení: Matthew Strazza ze společnosti CA doporučuje pro změnový proces následující postup – individuální změnu nad rámec projektu (například přidání funkce) je nutné promítnout do celého projektového dokumentu. Projektový manažer pak musí stanovit, jak taková žádost postihne rozpočet a časový harmonogram projektu. Sponzoři a investoři projektu musejí následně žádost o změnu odsouhlasit.
Chyba č. 6: IT nemá aktuální přehled o stavu projektu.
Důsledek: Co nelze analyzovat, to nelze řídit. Navíc pak není možné ani koordinovat zdroje, ani reagovat na změny a jejich vliv na rámec celého projektu. Řešení má přitom právě IT obvykle na dosah ruky.
Řešení: Software.
Chyba č. 7: IT ignoruje problémy.
Důsledek: Problémy se samy nevyřeší. Čím déle je ignorujete, tím se jejich stav zhoršuje a vrhá negativní stín na původní plán projektu.
Řešení: Pokud děláte něco špatně, vše se točí kolem toho, jak dobře svoji chybu napravíte. Většina lidí zatlouká a nepřizná, že je v bryndě. Umění pochopit, že je něco špatně, a být velmi rychle schopný svůj problém konzultovat s ostatními partnery projektu, případně odstranit vzniklé pochybnosti, vás uchrání před pádem do krizové situace.
Chyby v plánování
Chyba č. 8: IT nedefinovalo rozsah rámce celého projektu.
Důsledek: Pokud rámec projektu není dobře definován, celá práce může skončit obrovským nezdarem. Projekt pak samozřejmě postrádá srozumitelnost a směr, které IT potřebuje k jeho zdárnému zakončení v plánovaném čase, v rozmezí předem stanoveného rozpočtu a v rámci zadavatelských požadavků a očekávání.
Řešení: Špatně či nedostatečně definovaným projektům předejte vytvořením jasného (třeba i obchodního) modelu finálního stavu.
Chyba č. 9: IT nebere v úvahu vzájemnou závislost mezi projekty.
Důsledek: Projekty nejsou ostrovy. Často jsou ovlivňovány jinými projekty, které se vyvíjí ve stejném čase. Ve chvíli, kdy projektový management nevidí závislosti mezi jednotlivými projekty (například zaměstnanec, který pracuje na jednom projektu, je naráz zapojen i do druhého), dochází ke zpomalení prací, což může mít zdrcující dopad na všechny aktivity.
Řešení: Při odhalování závislostí může značně pomoci komunikace s partnery a tvorba vhodných diagramů.
Chyba č. 10: IT nebere v úvahu Murphyho zákon.
Důsledek: Co se může pokazit, to se opravdu pokazí. Projekt následně sejde z cesty, zatímco se IT snaží zvládnout nečekaný zmatek.
Richard Scannell z GlassHouse Technologies si vzpomněl na jednu společnost ve Velké Británii, která stěhovala svůj mainframe do nového datového centra. Skupina IT zaměstnanců zasvětila celou sobotu demontáži a převozu systému na nové místo. Cestu jim však zkřížila „Gay Pride Parade“, která zcela zablokovala potřebné komunikace. Museli jet tedy zpět a všechno dát na původním místě zase dohromady. Nečekaná chyba v plánovacím procesu způsobila, že zaměstnanci udělali mnohem více práce, než bylo původně zapotřebí.
Řešení: Zařaďte analýzu možných rizik jako součást projektového plánování. Zorganizujte týmový brainstorming a zkuste dát dohromady, co všechno by mohlo projekt zpomalit nebo vykolejit. Poté řádně promyslete postupy, jak taková rizika eliminovat.
Chyba č. 11: IT odbývá řízení projektových změn.
Důsledek: Je to pořád stejné: peníze a těžká práce, které byly vloženy do dodávky nové technologie, mohou přijít vniveč – stačí, když uživatelé nejsou schopni, nebo se nechtějí nové změně přizpůsobit.
Řešení: Během plánovací fáze věnujte čas úvaze, kde všude se v projektu mohou objevit překážky, které ho zpětně ovlivní, říká Douglas Clark ze společnosti Métier. Je třeba určit partnery a uživatele, jejichž práci změna ovlivní, a naplánovat, jak se bude změna komunikovat.
Komunikační problémy
Chyba č. 12: IT ignoruje nesmyslně stanovovaná data ukončení dílčích aktivit projektu.
Důsledek: IT si nezřídka samo na sebe uplete bič nesplnitelných termínů. Termín se pak snaží dodržet. Takové jednání však ve finále vyústí v problémy, které beztak prodlouží včasné dodání projektu. Pověst notorických „brzd z IT“ na sebe obvykle nenechá dlouho čekat.
Řešení: IT management musí vysvětlit svému výkonnému řediteli, za jakých okolností lze dodržet předem stanovený termín ukončení dílčích částí projektu a s ním plánované náklady a využití zdrojů. Nadřízený se pak musí rozhodnout, zda směřuje své priority na náklady, rámec projektu nebo časový harmonogram.
Chyba č. 13: Špatná komunikace mezi IT, stranami zainteresovanými v projektu a investory.
Důsledek: IT oddělení nesplňuje požadavky zadavatele projektu.
Řešení: Projektová komunikace musí mít své posluchače, říká Kondová. Nesrovnalosti v základním rámci projektu nebo v systémových požadavcích vzrůstají v případě, kdy IT oddělení svým partnerům poskytne příliš složitou dokumentaci obsahující podrobné systémové funkce a specifikaci projektu. Zadavatelé nejsou schopni tak podrobnou technickou dokumentaci pročíst a porozumět ji, proto ji ignorují. Pak je IT oddělení frustrováno a brání se slovy: „Popsali jsme jim to do detailu. Jak je tedy možné, že odevzdaná práce neodpovídá jejich požadavkům?“
Kondová v tomto případě doporučuje podat každému do projektu zainteresovanému partnerovi kompletní projektovou dokumentaci, od návrhu až po školení. Dokument by měl zdůraznit aktivity, které vyžadují interakci s partnery a měl by podat vysvětlení, proč a kde je zapotřebí zpětné vazby.
PŘEDPLATNÉ
ČLÁNKY DO MAILU