facebook
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
Navisys
IT SYSTEMS 10/2006

Škola projektového řízení: Kontrola a komunikace (sedmý díl)

Petr Opletal




Další články seriálu:

Správně nastavený proces znamená minimum neklasifikovaných zpráv. To stejné platí i pro proces projektového řízení. Pouze rozsah onoho minima se liší od provozních procesů.


#

Komplexní pojetí komunikace znamená předávání všech informací, které mají co do činění s projektem a jeho řízením. Formulací „předávání informací“ je řečeno, že každá informace musí mít svého původce (zdroj), obsah (data, popřípadě nosič) a svého příjemce. Předávání informací probíhá v konkrétním čase, respektive v daných lhůtách od předem stanovených iniciálních událostí. Je pouze sporné, jestli jsou přípustné neformální informace (tzn. bez trvanlivého nosiče dat, bez potvrzení o převzetí). Klíčovou otázkou pro projektového manažera a proces projektového řízení je, co jsou komunikační povinnosti projektového týmu.

Projekt a organizace

Ať zodpovídáme za jakoukoli organizaci, musíme využívat základní činnosti procesu řízení – plánování, kontrolu, motivaci, vedení (týmů), správu dokumentace, ekonomiku, správu faktorů úspěchu atd. Komunikace je elementární náležitost každého procesu. Tradiční pojetí, kdy se projekt vyčleňuje jako samostatná organizační jednotka, či přímo subjekt, logicky považuje za „vlastní“ všechny činnosti. To znamená, že každý projekt má stanovena vlastní pravidla. Ta mohou být jiná než pro ostatní projekty. Má to určitou logiku, jelikož je nesporné, že každý projekt je jiný. Z toho plynou snahy nastavit pro fungování projektu komunikační kodex, který není v souladu se standardní podobou komunikace v některé z organizačních jednotek, které se projektu účastní. Je celkem jasné, jak takový pokus musí dopadnout. Nejhorší možný důsledek je, že projekt zkolabuje, jelikož spoléhá na dodržování pravidel.

Druhá strana téže mince se objeví v případě, že obchodním případům (zakázkám) říkáme projekty a projekty by to skutečně být měly, ale projekty zákazníků. V takovém případě se snažíme nastavit pravidla pro zpracování informací tak, aby se minimalizovala pravděpodobnost poškození vlastních zájmů. Jak je zřejmé, takovýto systém nemůže být příliš efektivní a flexibilní. V tomto případě je dobře vidět, že klíčovým problémem by při korektním pojetí nemuselo být zajistit interní komunikaci (nakonec kvalita zpracování informací uvnitř projektu by měla být zájmem projektového manažera; onen zásadní problém je vytvořit fungující komunikační rozhraní vůči okolí projektu, viz dále). Samozřejmě za předpokladu, kdy se všichni účastníci projektu budou ochotni a schopni přizpůsobit nastaveným pravidlům.

Z toho vyplývá první klíčová povinnost vedoucího projektu – seznámit všechny externí účastníky projektu (pokud jsou to reální účastníci, nikoli prostí subdodavatelé) s komunikačním kodexem, ověřit si, zda mu rozumí a jsou schopni se přizpůsobit. Pokud se z jejich strany objeví náměty či kritika, je povinen daný podnět přenést vlastníkovi procesu projektového řízení. Dodržování pravidel komunikace je nezbytné. Předem musí být nastaveny citelné sankce pro jejich porušování. Každý účastník má jasně stanovenou informační povinnost. To, jestli si ji plní, je předmětem kontroly (viz dále).

Komunikační způsobilost

Potom ale nestojí otázka tak, jaké vlastnosti či náležitosti má komunikace uvnitř projektu. Podstatné je, co musí zvládat komunikační systém organizace, aby mohl být při řízení a práci na projektu účelně využíván. Tedy zda je prostředí, ve kterém je projekt spuštěn, schopno podporovat práci organizovanou projektovým způsobem. Součástí prostředí je primárně organizace vlastníka projektu, ale také organizace externích složek projektového týmu (což je typická situace pro investiční projekty). A právě v situaci, kdy potřebujeme zapojit externí účastníky, oceníme ověřená jasná a efektivní pravidla. Vytvořená s ohledem na to, aby se jim byla naprostá většina myslitelných partnerů schopna přizpůsobit.

Pokud chceme říci, jaké komunikační předpoklady má mít projekt, musíme rozlousknout otázku, co je pro jeho fungování klíčové. Což je relativně jednoduché – zeptáme se, čím se projekty zásadně liší od rutinních činností. Popřípadě, jestli se vůbec zásadně odlišují. Bez dogmatizování toho, jak by to „správně“ mělo být, vidíme, že projekt, práce na něm, a zejména jeho řízení závisí na kvalitě plánu prací a jeho soustavné aktualizaci. Pokud tuto myšlenku přijmeme, plán prací je zcela klíčovým komunikačním prostředkem a většina úsilí se soustředí na to, aby byl efektivně publikován – aby účastníci projektu byli průběžně informováni o změnách, přednostně o těch, které se jich týkají. Plán prací by měl být nejlépe jediným komunikačním prostředkem pro práci týmu i pro dohled nad průběhem projektu.

Za aktualizaci plánu prací zodpovídá vedení projektu a samozřejmě všichni účastníci, kteří aktualizují svá očekávání plnění vlastních úkolů. Povinností samostatného člena týmu je, aby identifikoval a promyslel každou událost, která může mít vliv na projekt, pokusil se předvídat její důsledky – typicky pokud nastane (ať ve vlastním úkolu, nebo v některých souvisejících činnostech) cokoli, co má dopad na očekávanou dobu trvání, je nutno tuto informaci co nejdříve předat vedení projektu. Vyplývají z toho dvě klíčové funkce komunikace – publikování vrcholových informací a podpora jednoznačných hlášení, jejich přijetí, potvrzení a zpracování (včetně cíleného informování těch subjektů, které jsou změnou dotčeny). Podobným způsobem musí být řešeny i zprávy zvenčí, například očekávané hrozby.

Rizika a SFÚ

Typickým scénářem, kde se v rámci různých teorií projektového řízení dělá spousta zmatků, je správa rizik. Úmyslně není řečeno „řízení“ rizik. Musíme rozlišovat rizika a nejistotu. Nejistota je jednoduše řečeno doplňkovou hodnotou pravděpodobnosti úspěšného dokončení projektu, jeho částí nebo jednotlivých činností. Pravděpodobnost dokončení je údaj, kterým projektový tým či realizátor činnosti vyjadřuje spolehlivost své představy o budoucím průběhu. Každá činnost by měla být z hlediska nejistoty klasifikována. Nejistota je v podstatě vyjádření úrovně znalostí a zkušeností s klasifikovaným jevem. Co všechno zodpovědná osoba „ví, že neví“. Úplná jistota v projektových činnostech znamená, že si realizátor neuvědomuje, jak málo toho ví. Základní premisa pro řízení spolehlivosti a rizik zní, že „nikdy nevíme o všech možných komplikacích či ohroženích“.

Normativní úroveň spolehlivosti by měla být nastavena u typových činností. Pokud se realizátor ve svém odhadu odchýlí více, než je povolený rozsah, znamená to, že je nutno přezkoumat jeho chápání zadání a zamýšlený způsob realizace. To stejné platí pro časový odhad. Signální úroveň by při návrhu činnosti z typové měla být víceméně automaticky přepočítána podle stanoveného poměru k řídícím veličinám rozsahu. Může to vypadat složitě, ale jedná se o nutné zpětnovazební prvky, které jsou pro projektového manažera velmi užitečné.

Je tedy jasné, že riziko není nejistota. Nejistota je přirozenou – a na rozdíl od procesů klasifikovanou a řízenou – součástí projektu. Riziko by z hlediska obvyklého využití a významu pojmu měl být neovlivnitelný, neřiditelný a nezávislý jev – přírodní síly, změna okolního prostředí, teroristický útok apod. Do rizik by se neměla zahrnovat ani taková věc, jako je selhání či krach dodavatele. To je něco, s čím by se mělo počítat. Jistě, můžeme být například při zahájení projektu v situaci, kdy je potřeba rychle jednat a není čas na provedení všech standardních procedur, které klasifikují spolehlivost dodavatele. Opět pomohou pravidla, která řeknou, s jakou nejistotou máme v takovém případě počítat.

Proto jsou ohrožení, příležitosti, omezení a kompetence (hrozby, příležitosti, slabé a silné stránky – SWOT) souborem faktorů, kterým se říká „strategické faktory úspěchu“ (SFÚ). Monitoring těchto SFÚ stejně jako legislativy a případných dalších informačních zdrojů musí zajišťovat organizace (okolí projektu). Je nesmyslné, aby se sledováním oblastí, které se ve velké většině budou překrývat, zabývala každá část firmy či každý projektový tým samostatně (v případě projektu organizovaného například konsorciem je to otázka dohody o rozdělení práce, popřípadě integrace uvažovaných systémů pro několik partnerů). Zde jasně vyvstává pro projektového manažera povinnost schválit (tzn. navrhnout k doplnění atd.) seznam monitorovaných informačních zdrojů, k čemuž by také mělo existovat jasné rozhraní.

Kontrola

Typickou funkcí, která stojí na získávání a zpracování informací, je kontrola. Kontrola je neoddělitelnou součástí řízení – pokud má být něco prováděno, je nutno, aby existovala jasná zodpovědnost konkrétní osoby za výsledek. A tato osoba si musí zajistit, aby byla informována v případě, kdy příslušná činnost neprobíhá podle očekávání. Je zjevně nutno jasně stanovit, od koho komu mají být předávány jaké informace. Jinými slovy, co má být výsledkem a co předmětem kontroly. Zde zase budou velice užitečná standardní pravidla, vytvořená a trvale upřesňovaná zobecňováním zkušeností.

Je nutno rozlišovat, co kdo řídí. Máme dvě, popřípadě tři vrstvy. Řízení vlastního projektu a proces projektového řízení jsou dvě různé úrovně. Uvnitř projektu je kontrola záležitostí vedoucího projektu. Ověřuje, zda činnosti projektu probíhají podle pravidel, tzn. mimo jiné v přípustných kvalitativních, časových a jiných mezích stanovených plánem prací. Přesněji řečeno musí se kontrolovat minimálně tři oblasti. První je úplnost a spolehlivost plánu prací včetně zajištění zdrojů a ověření jejich způsobilosti. Druhou je soustavné ověřování, zda projekt (plán prací) odpovídá realitě. Třetí to, zda subjekty, kterých se projekt dotýká, mají dostatek informací, zda jim rozumí a zda se chovají v souladu s nimi. Kontrolujeme tedy plán a průběh prací, lidi a jejich způsobilost včetně znalostí a dodržování pravidel.

Ve vrstvě procesu projektového řízení musí být kontrolován vedoucí a v jistém smyslu všichni členové projektového týmu a partneři projektu, zda dodržují pravidla. Musí být možno ověřovat, zda projektový tým udržuje dostatečně zodpovědně a pečlivě plán prací aktuální. Zda se provádí kontrola uvnitř projektu včetně jejich personálně motivačních důsledků. Dále zda jsou dodržovány zásady pro komunikaci, vedení porad, přesnost zadávání úkolů atd. Zejména jak jsou dodržovány povinnosti umožňující efektivní správu a využití zdrojů. Nekontroluje se, jestli práce postupují rychle nebo pomalu. To je interní záležitostí projektu.

Výše uvedené kontroly z úrovně procesu projektového řízení prověřují, zda vedoucí a lidé v projektu dodržují nastavená pravidla a plní své povinnosti. Navíc zajišťují identifikaci a podněty pro řešení konfliktů s prostředím – typicky správa kapacit apod. Za to, kdo a jak provádí tuto kontrolu, zodpovídá vlastník procesu projektového řízení. Samotný výkon kontroly by to měl být pracovní náplní projektové kanceláře. Samostatně se většinou vyčleňuje informační funkce označovaná jako „reporting“, která by měla sloužit k pokrytí informačních potřeb zadavatele. Tuto roli může plnit projektová kancelář nebo příslušné automatické mechanismy pro zpřístupnění informací o projektu.

Reporting

Pod vznešeně znějícím názvem se skrývá jedna z největších deformací obvyklého pojetí projektového řízení. Formálně reporting zahrnuje hlášení stavu, odchylkách a výjimkách. Tj. popis postupu a dílčích výsledků, rozdíly mezi skutečností a plánem, případně očekávané zásadní nedodržení zadání v kterémkoli z klíčových parametrů. Obvykle se soustředí na minulost. Často se vykazuje nesmyslné množství údajů. V takovém případě většinou projektový manažer zadání projektu příliš nerozumí nebo hledá alibi. Předává zadavateli veškeré informace s přesvědčením, že se tím zbaví zodpovědnosti za korektní průběh a výsledky projektu. To, že zadavatelé tyto praktiky striktně nepotírají, jen potvrzuje, že se vykazovanými údaji nezabývají. Samozřejmě je taková situace jasná v případě, kdy není kvalitní zadání, popřípadě zadavatel již předem ví, že nemá dostatečně funkční systém projektového řízení nebo dostatečně kvalifikované vedoucí projektu.

Tady je dobrý příklad toho, jak mají být pravidla pro předávání informací nastavena. Jednoznačně je potřeba se na začátku jasně dohodnout, jaké informace kdo potřebuje. Jistě je možno namítat, že někteří zadavatelé vyžadují nekompromisně určité údaje a diskutovat nechtějí. Doporučení může znít – pokud si je projektový manažer jistý, že jsou to údaje, které nemají zadavatele zajímat, měl by jejich vykazování rozporovat, protože jejich získávání a případné vysvětlování či obhajování je plýtvání kapacitou.

Pro zadavatele jsou smysluplné dva údaje – očekávaný termín dokončení a množství zbývající práce včetně úrovně nejistoty. Nikoli pravidelně, ale při jejich změně, popřípadě při překročení signálních hranic. Nové údaje by měly být automaticky publikovány na projektovém webu. Povinná je minimální perioda aktualizace – když nic jiného, tak se musí vykazovat provedená práce. Systém upozorní na změny či nedodržení nastavených lhůt. Krom toho by zadavatel měl věnovat patřičné úsilí trvalému upřesňování informací vztahujících se k projektovému záměru, což se projektu dotýká v opačném smyslu – vedoucí projektu by měl být informován o možných důsledcích či změnovém řízení.

Příkladem rozumné dělby zodpovědnosti je například při vývoji nového produktu kvalita a cena konkurenčních substitutů. Při původním zadání mohl zadavatel vycházet z nepřesných informací o situaci u konkurentů, například že žádný ze sledovaných konkurentů nezahájil vývoj zamýšleného řešení. V průběhu prací se ovšem zjistí, že to nebyla pravda. Jak na nové skutečnosti reaguje zadavatel, je ryze jeho věcí. Pokud se ale rozhodne změnit zadání, znamená to přerušit projekt, revidovat zadání a na základě dosavadních výsledků a změny požadavků navrhnout nový projekt, který má šanci dosáhnout toho, co je potřeba.

Porady

Jednou ze zdánlivě nejjednodušších forem komunikace uvnitř projektu jsou porady či schůzky projektového týmu. Paradoxně jsou nejvíc nenáviděné a současně nejoblíbenější. Nejoblíbenější v tom smyslu, že většina lidí, kteří na nějakých projektech pracují, fanaticky věří v magickou moc osobního jednání. Je to především díky tomu, že se domnívají, že na schůzky není potřeba se připravovat a závěry jednání není nezbytně nutno formalizovat a vynucovat. Díky tomu mají pocit, že když řekli všechno, co měli na srdci, znamená to, že ostatní to vyslechli a pochopili a tím jsou jejich problémy vyřešeny. Ve skutečnosti je tomu právě naopak.

Většina posluchačů si právě díky přímé řeči vytvoří vlastní představu o tom, co se řeší, co je jejich úkolem atd. Řečník neformuluje svoji informaci nikdy zcela plnohodnotně a jednoznačně. Posluchač zachytí jenom část. Interpretuje ji dle svých vlastních schémat. Samozřejmě z logiky věci a díky vlastnostem lidské psychiky z toho vyjde něco jiného, než je faktický smysl sdělení. A následný zápis na tom z mnoha důvodů nic nezmění. Bohužel proto, že jej většinou nikdo nečte. I když jej náhodou někdo čte, automaticky převádí zapsané informace do podoby kompatibilní s původně vytvořenou představou. Potom dochází k naprosto zbytečným situacím typu „Ale já jsem si myslel(a), … Tady je to napsáno jinak, než to bylo řečeno…“.

Obvyklé porady nejen plýtvají časem, ale často dezinformují či způsobují zbytečné komplikace. U projektů jsou však porady nutné. Čím méně, tím lépe. Nesmí existovat mimořádné či naléhavé porady. Všechny podstatné informace musí být předány před konáním porady, na poradu se nezařazují nepřipravená témata, porada musí mít program, moderátora atd. Kdyby pravidla vynucovala důslednou přípravu porad, vedoucí projektů by si možná uvědomili, kolik práce a zmatků jim ušetří formalizovaná komunikace. Zejména pokud nebudou muset k respektování formálních informací své spolupracovníky nutit sami, protože to již bude standardní způsob práce.

Rozlišujeme koordinační a řešitelské schůzky. Cílem koordinačních porad je zajistit předání a ověřit přijetí společných informací. Cílem je ověřit shodné vnímání situace, vývoje, změn a jejich důsledků, interpretaci potřeb, interaktivní formulaci předběžných zadání úkolů a předběžný výběr realizátorů. Řešitelské porady se soustředí na to, aby na základě zpracovaných podkladů bylo řešeno co nejlépe definované zadání. Je nutné si uvědomit, že řešitelská porada nemá zaručený výsledek. Musí mít jediné téma a bude trvat mnohem déle než koordinační porada.

Formy komunikace

Fakticky by mělo být lhostejné, jaké formy pro předávání zpráv využijeme. Samozřejmě se dnes nabízejí nejrůznější technologie, které umožňují věci, které by nás dříve ani nenapadly. Typickým příkladem je publikování informací prostřednictvím webového serveru, který dokáže rozlišit účastníky a zpřístupní každému ty údaje, které se jej týkají. Popřípadě umožňuje zadávat ty informace, které se od projektového týmu mají sbírat. Není to ale jednoznačná záležitost.

Technologie nás svádějí k tomu, že se zahlcujeme množstvím dat, která nejsou bezprostředně nutná. Jen proto, že je tak snadné je vytisknout. Občas dokonce děláme zásadní chybu a snažíme se – někdy úmyslně – předávat tolik dat, že jsou v konečném důsledku naprosto nepoužitelná. Ale i když nebudeme technologie zneužívat, je potřeba se naučit správně publikovat i přijímat. Principem by mělo být to, že potřebné informace se nehledají, ale jsou doručovány správným lidem ve správném čase. Toto je jeden z klíčových úkolů jak systému projektového řízení, tak v konkrétní instanci – projektu – projektového manažera.

Pro řadu projektových manažerů je důležitá i technická podoba předávání informací. Zcela jistě bude pro některé týmy a situace výhodnější přímá interakce a pro některé situace je nezbytná formální komunikace. Ale nemělo by být nosným tématem projektové komunikace, zda se ten či onen typ sdělení doručuje pomocí e-mailu nebo telefonicky. Součástí pravidel by ovšem měly být konkrétní náležitosti pracovního postupu spojeného s výměnou informací – co, zda a v jakých lhůtách se bude dělat při neodpovídání na dotazy, jaké jsou lhůty pro připomínkování dokumentů nebo předání podkladů. Tyto sjednané náležitosti musí být striktně dodržovány.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.


Další články seriálu:



Inzerce

Co se děje ve světě DMS aneb Hlavní trendy zpracování dokumentů

OnlioŽijeme v digitální věku a platí to i v případě práce s dokumenty, kterému se nevyhne žádná organizace. Čistě bezpapírová kancelář je sice vizí budoucnosti, nicméně již dnes řada firem úspěšně využívá nějaký DMS systém (Document Management System), který je perfektním základem pro centrální správu dokumentů s řízením jejich oběhu.