Môj známy, projektový manažér, mi hovorieval: “Hlavnou úlohou projektového manažéra je, aby bol zákazník “happy” (=šťastný). Ak je zákazník “happy”, je “happy” aj náš šéf a hlavnou úlohou šéfa je, aby udržiaval svojich projektových manažérov “happy”…”
Dnes je módne nazývať projektom kadečo, len nech sa to rieši tímovo. Ale projekty majú svoje presné pravidlá a projektoví manažéri sú na to, aby zabezpečili ich dodržiavanie. Naučil som sa to na vlastnej koži. Ešte kým som pôsobil na vysokej škole, nebol som ani vyslovený typ “výskumníka”, ani vyslovený typ “učiteľa” – bavilo ma aj organizovanie a riadenie zložitých činností. Keď sa naskytla príležitosť nastúpiť na pozíciu hlavného koordinátora dvoch medzinárodných projektov PHARE s účasťou Belgicka, Írska, Francúzska a Nemecka, nezaváhal som. Po dvoch rokoch skúseností ma oslovila firma Digital Equipment Corporation a ponúkla mi miesto profesionálneho projektového manažéra. Išlo o multinárodný projekt s účasťou Švédov, Holanďanov, Kanaďanov, Čechov, Američanov, firmy Digital a niekoľkých slovenských firiem. Práve sa podpísal kontrakt na projekt a práce sa rozbehli. Nastúpil som tak vlastne do rozbehnutého vlaku, kde sa okrem mňa na lokomotíve tiesnili aj nemecký a anglický projektový manažér s deľbou kompetencií a kooperácií.
Jazyk projektového manažmentu
Projekty majú svoju vlastnú reč. Ak ju ovládate, môžete sa sústrediť na prácu. Ak ju neovládate, vzniká nebezpečenstvo, že sa s kolegami nedokomunikujete. Preto prvá vec, čo som sa naučil, bola “projektovčina”. Náš projekt bol typu, ktorý označovali za evolučný – komplikovaný, neprehľadný a náročný. Všetky činnosti, ktoré sa mali v jeho priebehu vyskytnúť, boli rozdelené do jednotlivých blokov aktivít (obr. 1) – na analýzu požiadaviek na projekt, návrh priebehu projektu, riešenie projektu a jeho zavedenie u zákazníka.
Projekty však začínajú skôr. Napríklad pri predajnom rozhovore zistí obchodník potreby zákazníka, ktoré by sa mohli riešiť formou projektu “na kľúč”. Obchodník teda vystupuje v úlohe vyhľadávača príležitostí . Nemusí vystupovať v neskoršej fáze ako projektový manažér. Úlohu projektového manažéra môže prevziať iný pracovník, napr. technik, ktorý lepšie pozná technické možnosti podniku a svojich dodávateľov. Ten sa potom spolu s vyhľadávačom zúčastňuje prvých stretnutí a rozpracuje informácie, ktoré získal od zákazníka, do návrhu projektu. Pokiaľ ide o dodávku “na kľúč”, na ktorú sa vypisuje konkurz, potom je návrh projektu podkladom pre vypracovanie ponuky. Keď sa zákazník k ponuke vyjadrí a naša firma ju vyhrá, vyjasníme si so zákazníkom požiadavky, podpíšeme zmluvu a spúšťame projekt.
Každý projekt sa rieši po jednotlivých blokoch. Výstupy z nich sú akési míľniky. Hlavných míľnikov môže byť v projekte len toľko, koľko je jednotlivých blokov aktivít, a sú pre zákazníka dobre viditeľné. Vlastne v týchto bodoch zákazník aktívne vstupuje do projektu tým, že si prečíta nejaký výstupný dokument, prezrie a na základe vopred definovaných akceptačných kritérií overí čiastkový produkt, alebo len skontroluje čas a zdroje, odsúhlasí uzavretie etapy a povolí prechod do ďalšieho bloku.
Projekt však musí obsahovať aj interné míľniky. Pre zákazníka nie sú interné míľniky spravidla viditeľné. Slúžia hlavne projektovému manažérovi na kontrolu priebehu riešenia projektu z hľadiska času, zdrojov a financií a ako podklad pre správy nadriadeným a pre kontrolu dodržiavania stanoveného sizingu projektu.
Projekty bývajú rôznych typov: štandardné, inovatívne, komplexné, riskantné a pod (pozri aj obr. xx na strane xx). Každý projekt je jedinečný. Jeho životný cyklus závisí od typu projektu a odzrkadľuje jeho veľkosť a ostatné faktory, ktoré vstupujú do hry. V rámci životného cyklu poznáme štyri zjednodušené modely priebehu projektu, ktoré zoraďujú určité aktivity do vopred definovaných projektových fáz (pozri nižšie). Každému typu projektu vyhovuje lepšie iný model životného cyklu. Ak v prvopočiatku zvolíme nesprávny model, máme len malú pravdepodobnosť úspechu.
Aký je však úspešný projekt? Definícia “úspechu” je veľmi individuálna. Je splnený predmet dodávky, ale prekročíme personálne zdroje alebo rozpočet, ktoré máme vyčlenené na projekt? Ak áno, do akej miery prekročenia zdrojov môžeme projekt ešte považovať za úspešný? Väčšinou to býva stanovené v zmluve medzi zadávateľom a dodávateľom. Ak ide o projekt fixed-price , teda za pevnú cenu, zmluvy obsahujú klauzulu “… a náklady nesmú prekročiť xx% ceny projektu”. Potom aj keď prekročíme sumu určenú vo fixed price a pohybujeme sa ešte v limite (väčšinou to býva okolo 10%), je projekt ešte stále úspešný.
Životný cyklus projektu
Keď plánujeme projekt, máme k dispozícii štyri základné modely jeho životného cyklu: vodopád, inkrementálny, špirálovitý a evolučný. Výber vhodného modelu podlieha istým pravidlám, ktoré zachytáva tabuľka č. 1.
Najjednoduchším modelom je tzv. vodopád, čiže sekvenčný životný cyklus. Všetky aktivity projektu možno usporiadať do určitých po sebe idúcich sekvencií. Výstup jednej fázy je vstupom druhej fázy – preto sa musí prvá fáza úplne uzavrieť a zdokumentovať, než začne ďalšia fáza. Projekt sa prezentuje zákazníkovi až na konci a ako vykonateľný celok – a len ako celok sa implementuje do praxe. Zákazník preberá projekt na základe vopred dohodnutých akceptačných kritérií.
Analýza požiadaviek sa robí “en bloc” a takisto návrh systému, ktorý z nej vychádza, je väčšinou iba jeden.
Zákazník si, prirodzene, môže vyžiadať aj viac výstupov – napr. optimálny z funkčného hľadiska a optimálny z hľadiska finančného. Týka sa to predovšetkým výstupov z analytickej fázy. Už niekoľkokrát v svojej praxi som sa stretol s tým, že zákazník si vyhradil právo rozhodnúť sa až na základe porovnania viacerých scenárov, ktoré ste mu museli vypracovať. Pokiaľ však zákazník chce postupovať týmto spôsobom, musí to byť zakotvené v zmluve, lebo nároky na prácnosť riešenia tým značne stúpajú.
Model Vodopád nie je veľmi náročný na skúsenosť projektových tímov. Preto si naň môže trúfnuť aj menej skúsený projektový manažér. Pre svoju jednoduchosť a prehľadnosť je však rovnako obľúbený i medzi zákazníkmi, ktorí si vedia presne plánovať svoje náklady i personálne nasadenie v rámci konzultácií.
Zo sekvenčného životného cyklu sa vyvinul inkrementálny životný cyklus. S vodopádom má identické prvé fázy projektu – analýzu problému a návrh riešenia. Oboje sa urobí naraz a pre celú zákazku. Potom sa práca na systéme rozdelí do jednotlivých miniprojektov so svojimi vlastnými akceptačnými kritériami. Miniprojekty sa riešia paralelne, ale pri odovzdávaní zákazníkovi sa znova skompletizujú do jedného celku a odovzdávajú sa “en bloc”. Miniprojekty môže zákazník akceptovať aj skôr (pre miniprojekty možno stanoviť čiastkové akceptačné testy), ale so zavedením do prevádzky sa čaká na dokončenie všetkých miniprojektov.
Keď zákazník na začiatku ešte nevie presne zadefinovať svoje požiadavky, je vhodný špirálovitý životný cyklus. Zvýrazňuje úvodné fázy projektu – analýzu požiadaviek a návrh systému. Zákazník tuší, ako by asi malo vyzerať to, čo chce, ale nevie svoje požiadavky špecifikovať – lenže nepresná počiatočná špecifikácia požiadaviek v sebe skrýva veľké riziká pre celý projekt! Preto sa v špirálovitom modeli v počiatočných fázach zbierajú údaje a s ohľadom na obchodné prostredie zákazníka (jeho business needs ) sa robia návrhy pilotných projektov, ktoré majú za úlohu ukázať všetky možné riešenia. Až na základe týchto poznatkov sa definuje predmet dodávky projektu. Toto všetko sa koná v úzkej konzultácii so zákazníkom, ktorý najlepšie pozná svoje obchodné prostredie. Krok po kroku schvaľuje s dodávateľom jednotlivé fázy analýzy a konečný výstup analýzy sa postupne mení na základe požiadaviek, ktoré sa v priebehu analýzy môžu vynoriť. Až na základe výsledkov úvodných fáz sa potom zákazník i dodávateľ zaviažu pokračovať v riešení projektu.
Návrh projektu, implementácia, dodávka a rozšírenie do prostredia potom prebiehajú podobne ako v sekvenčnom modeli.
Takéto projekty sa vyskytujú vo veľkých organizáciách, tam, kde sa rýchlo mení obchodné prostredie a zákazník len ťažko vie záväzne stanoviť požiadavky na dlhšie obdobie.
Ešte vhodnejším životným cyklom pre veľmi turbulentnú situáciu je tzv. evolučný model. Ako jediný nám umožňuje priebežne prispôsobovať dodávku požiadavkám zákazníka. Tím na základe dôkladnej analýzy očakávaní zákazníka navrhne stratégiu rozdelenia celkového riešenia do určitých častí, z ktorých každá má pre zákazníka nejakú výpovednú hodnotu a nejaký prínos. Jednotlivé časti sa však vyvíjajú a dodávajú zákazníkovi separátne. Napr. nainštalujeme časť hardveru a spustíme do prevádzky len určitú časť siete alebo len nejaký modul. Potom k nemu pridávame vylepšenia. Spustíme ďalšiu časť, dodáme ďalší hardver. Alebo nejaká funkčná vetva sa spustí do prevádzky skôr, než sa akceptuje aj zvyšok dodávky.
Môže sa nám stať, že prvé dodané časti projektu sa nám spätne premietnu do zmeny v obchodnom prostredí zákazníka a modifikujú nám zadanie ostatných častí projektu.
Samozrejme, vo všetkých štyroch prípadoch ide o základné modely, ktoré ešte treba prispôsobiť konkrétnemu projektu. V priebehu riešenia projektu môžeme dokonca zmeniť aj zvolený životný cyklus. Projekt vyštartujeme napríklad ako inkrementálny, ale v jeho priebehu si povieme, že nepotrebujeme dodávku “en bloc”, ale že lepšie vyhovuje dodávka po moduloch alebo častiach. Vtedy sa životný cyklus mení na evolučný – samozrejme, po patričnej zmluvnej úprave, úprave akceptačných kritérií a prekalkulovaní zdrojov…
Ako vybrať vhodný model?
Zo štyroch základných modelov si treba vybrať ten životný cyklus, ktorý najviac vyhovie našim špeciálnym podmienkam. Vhodný životný cyklus vyberáme podľa veľkosti projektu, praxe projektového tímu, zvláštností obchodného prostredia zákazníka, komplexnosti dodávky a stupňa zaangažovanosti zákazníka do projektu (tabuľka 1).
V prvom rade musíme poznať sizing, teda veľkosť projektu. Musíme vedieť, čo bude projekt vyžadovať: koľko času, koľko a akého personálu a koľko peňazí. Vo väčšine prípadov nám zákazník stanoví limity, do ktorých sa musíme vtesnať. A tu zákazník často sám sebe škodí – na Slovensku si totiž mnoho firiem osvojilo pekný zvyk, že v konkurznom konaní “podcenia” projekt z hľadiska tak času, ako aj financií. Neskôr, keď sa projekt už rozbehne a zákazník nemôže od zmluvy “odskočiť”, snaží sa dodávateľ zmenovými konaniami sizing projektu zvýšiť. Nezriedka sa stáva, že po zmenových konaniach dosiahne projekt úroveň vyššiu než boli pôvodné odhady firiem, ktoré pri konkurze neuspeli! Proti takémuto postupu sa zákazník môže brániť len tak, že si stanoví druh dodávky “fixed-price” alebo “time-and-material” . Nie každý projekt však možno robiť týmto spôsobom a nie pre každý projekt je to výhodné. Napríklad zahraniční experti sa často platia na základe pracovných výkazov formou time-and-material, analýza pilotného projektu a návrh jeho riešenia budú pravdepodobne tiež time-and-material, kým rôzne sieťové riešenia, dodávky hardveru a rozšírenie pilotných projektov do prostredia sa robievajú s pevnou cenou, teda fixed-price. Bývajú projekty, pri ktorých jedna etapa je definovaná ako fixed-price, nasledovná etapa ako time-and-material a celý projekt môže znova skončiť ako fixed-price. Neexistujú presné pravidlá, akým platobným režimom riadiť ktorú činnosť, ale existujú už spomínané štandardy. Z nich potom projektový manažér vykrýva jednotlivé etapy projektu.
Aj typ obchodného prostredia zákazníka sa premieta do výberu životného cyklu. V relatívne pokojnom obchodnom prostredí môžeme použiť hocijaký model životného cyklu, ak sa však obchodné prostredie mení prudko a v krátkych časových intervaloch, sú vhodnejšie tie modely, ktoré umožňujú zmeny “za behu” – špirálovitý alebo evolučný.
Veľmi dôležitým faktorom je stupeň zainteresovania zákazníka do samotného priebehu projektu. Zaangažovanosť zákazníka do projektu býva podchytená zmluvne v človekodňoch, ktoré zákazníkovi ľudia odpracujú na projekte ako konzultanti pre projektový tím. Väčšinou ide o fázu analýzy požiadaviek. Stupeň zaangažovanosti zákazníka sa niekedy stane koreňom sváru. Zákazník za svojich pracovníkov veľkoryso prisľúbi, že na projekte odrobia isté percento pracovného času, lenže táto informácia sa k dotyčným pracovníkom už nedostane. Keď za nimi potom príde konzultant a snaží sa z nich ťahať informácie, pracovník si nenájde potrebný čas, prípadne prácu “odfláka”. Nezriedka si všetky potrebné údaje musí potom projektový tím zháňať a overovať sám. Nečudo, že dochádza k nepredvídaným sklzom v projekte, ktoré sa potom negatívne premietajú do jeho sizingu aj v nasledovných fázach. Na záver potom dodávateľ obviňuje zákazníka, že svoju prisľúbenú kvótu neodpracoval, že ju museli odpracovať dodávateľovi ľudia, pretiahol sa čas a vzrástli náklady… Trápne scény! A tak sa často stretávame so situáciou, že dva tímy, ktoré by mali na projekte spolupracovať, už v jeho úvodných fázach pracujú vlastne jeden proti druhému. (Mimochodom, nie je to čisto slovenská “bolesť”.)
Preto by sa zákazník mal vo vlastnom záujme postarať o to, že keď už raz prisľúbi svoju účasť v projekte, budú o tom vedieť a budú to akceptovať všetci pracovníci, o ktorých pôjde. Je to jeden z kritických bodov, ktorý nám ešte pred štartom projektu pomôže udržať sizing v patričných mierach. A súčasne je to aj jedna z priorít projektového manažéra – poznať možné riziká projektu a hneď spočiatku na tieto riziká zákazníka upozorniť.
Príprava projektu
Takže projektový manažér už vybral vhodný model životného cyklu projektu. Ale ešte musí urobiť ďalšie kroky, než sa projekt podarí spustiť.
Musí si predovšetkým urobiť dokonalý prehľad jednotlivých aktivít životného cyklu projektu. Musí si na to nájsť čas, musí si rozvrhnúť jednotlivé bloky životného cyklu a rozpísať aktivity, z ktorých sa každý blok skladá. Potom si musí urobiť predstavu, čo sa v ktorej aktivite musí vykonať, aké vstupy si vyžaduje a aké výstupy musí dať. A navyše mu musí byť jasné, aké nástroje pri každej aktivite bude musieť použiť, aby z daných vstupov bol schopný dostať zadefinované výstupy. Všetky tieto informácie potrebuje na to, aby naplánoval zdroje – časové, personálové i finančné. Musí si vyjasniť, že dokáže dosiahnuť to-a-to v stanovenom čase, ale potrebuje na to toľko-a-toľko ľudí. Alebo že v danej etape pôjde o dodávky hardveru a preto bude potrebovať viac peňazí. Je to spätný prístup “zdola nahor” – od dodávky späť k analýze.
Zdroje si musí projektový manažér zabezpečiť vopred. Týka sa to hlavne personálu, ktorý mu musí potvrdiť, že na základe predpokladaného vstupu je schopný vygenerovať predpokladaný výstup. Hneď prvé pravidlo NASA pre projektový manažment hovorí, že projektový manažér by sa mal stretnúť s každou osobou zainteresovanou do projektu aspoň raz a mal by poznať všetkých manažérov, ktorí majú s projektom do činenia (aj zo strany zákazníka!).
Riziká projektu
Projekt ešte nezačal, ale manažér si už musí pripraviť analýzu rizík. Len na základe analýzy rizík totiž môže pristúpiť k prispôsobeniu modelového životného cyklu podmienkam svojho konkrétneho projektu.
Pri analýze rizík sa projektový manažér snaží odhadnúť, aké nepredvídané okolnosti môžu nastať, ako sa môže zmeniť situácia a podobne – a s ohľadom na to si musí naplánovať časové “nárazníky”. Projektoví manažéri však majú tendenciu zabúdať na Murphyho zákony . Pôsobil som ako projektový manažér Digitalu aj na projektoch, kde som mal napr. za 70 dní odviesť prácu v hodnote 2,3 milióna USD. Denne to vychádzalo na milión korún – či už v zdrojoch, v hardveri, aplikačnom softveri a pod. Pri takýchto denných sadzbách si dokonale rozmyslíte, aké časové nárazníky zaplánujete! Ale nemôžete ani len náhodou predvídať, že časť zahraničnej dodávky hardveru vám pošlú omylom na opačný koniec sveta, kde ho Lufthansa strčí omylom do svojho interného skladu a tvári sa, že patrí jej. Nemôžete predpokladať, že keď po mnohom doťahovaní nakoniec presvedčíte Lufthansu, že zásielka je predsa len vaša, tak vám ju pošle – a že lietadlo miesto do Viedne odletí na druhý koniec sveta. A navyše, že na druhý koniec sveta lietajú také veľké lietadlá len raz za čas, a ten bol rozhodne dlhší než to, čo sme v katastrofických scenároch predpokladali. Nakoniec sme museli použiť klasickú cestnú dopravu – žiaľ, týždeň po termíne a v posledný deň naplánovaného “nárazníka”… Murphy by sa tešil.
Ďalšou oblasťou zvýšeného rizika sú ľudia. Z projektu vám odíde plánovaný človek a s ním aj unikátne know-how… Švédsky expert príde presne na konzultáciu, ale cez hranicu sa nedostane – vzal si omylom manželkin pas a Slováci mu neuveria, že je žena, ale ani Rakúšania (ktorí mimochodom na jeho omyl neprišli) ho nemôžu vziať späť… Alebo zákazník a jeho organizácia reagujú menej pružne, než vám sľubovali, a miesto dvoch dní schvaľujú vaše návrhy dva mesiace… Vo všetkých prípadoch sa predĺži alokácia zdrojov, dochádza ku kolíziám – hladký priebeh projektu je ohrozený.
Konkretizovanie plánu
Až keď si ujasníme, s akými rizikami by sme mali pri projekte počítať (hoci všetky ich tak-či-tak predvídať nedokážeme), môžeme modelový životný cyklus “našiť” na náš projekt, pomenovať etapy, aktivity a výstupy. Hovorí sa tomu prispôsobenie vybraného životného cyklu skutočnému projektu. Len vhodne zvolený model životného cyklu nás privedie k úspechu! Na jeho základe vypracujeme harmonogramy a priraďujeme zdroje k jednotlivým fázam projektu. Pre túto prácu existuje viacero nástrojov: PERT diagram, metóda kritickej cesty (CPM), metóda uzlov (bodov), metóda hrán a pod. Harmonogram musí byť skutočne podrobný, nesmie zostať na úrovni hlavných míľnikov.
Organizovanie projektu
Projektový manažment je vynikajúci nástroj, ktorý vás prinúti postupovať systematicky aj na pôde, ktorá vám je cudzia. Veľmi často sa ma zákazníci pýtajú, prečo sa projekty musia držať takých podrobných pravidiel. V mnohých prípadoch sme počas projektu “vychovali” nášho zákazníka k väčšej samostatnosti a zodpovednosti. Projekt má totiž svoju vlastnú organizačnú štruktúru. Najvyšším orgánom projektu je riadiaci výbor , zložený z “vysokých šarží”, zástupcov zákazníka a dodávateľa. Jeho úlohou nie je riešenie problémov, ale dozor nad pokrokom projektu a kultivácia dobrých dodávateľsko-odberateľských vzťahov. Práca sa odohráva vo výkonných skupinách, ktorých môže byť viac. Tieto podávajú správy o priebehu riešenia projektovému alebo programovému vedeniu. V tomto vedení tiež sedia zástupcovia zákazníka i dodávateľa (za dodávateľa napr. projektový manažér), ale ich úlohou je riešiť všetky sporné otázky a zabezpečovať projektovému tímu optimálne prostredie. Lenže v tom prípade, o ktorom hovorím, bola zákazníkom silne hierarchicky štruktúrovaná slovenská firma a jej manažéri, ktorí sedeli v projektovom vedení, sa necítili dostatočne kompetentní na to, aby rozhodovali. Prenášali všetky problémy do riadiaceho výboru, ktorý na ne nemal ani čas, ani potrebné informácie – a hlavne, ani z hľadiska obsadenia nepredstavoval výkonnú zložku s povinnosťou riešiť problémy. Keď už riadiaci výbor patrične znervóznel, museli sme si so zákazníkom sadnúť a pozhovárať sa o tom, na akom type porady treba riešiť ktoré otázky a že nie všetky problémy musí riešiť náš nadriadený. Efekt bol ohromujúci. Nielenže sa zlepšila naša výkonnosť ako celku, ale ich ochota predkladať nadriadeným už vopred pripravené rozhodnutia posilnila aj ich právomoc a status na pracovisku… Odrazu o veciach začali rozhodovať ľudia, ktorí ich skutočne robili, čím sa zrýchlili vnútropodnikové procesy a zlepšila sa kvalita rozhodnutí.
A ešte jedno pozorovanie na záver: žiadne dva životné cykly nie sú rovnaké. Ak máte prax s modelom vodopád a idete robiť iný projekt pomocou životného cyklu vodopád, môžu sa oba hodne odlišovať. Môžu mať iné vnútorné členenie, inú náročnosť. A preto sa často stáva, že zákazník so svojimi bodovými skúsenosťami má pocit, že rozumie tomu, čo mu predkladá dodávateľ v úvodných fázach – a pritom neodhadne náročnosť. Tu pomôže len komunikácia. Bez komunikácie sa projekty robiť jednoducho nedajú!
Autor: Ivan Golian
12,927 total views, 21 views today
