Začátkem září proběhla diskuze na téma „Strategie a byznysový pohled na projekt“. V obvyklém počtu diskutujících jsme probrali praktické dopady toho, že projekt musí být vždy v souladu se strategií podniku. Ale co když není? A co když ani ta strategie není známa?
Hrubý záznam z diskuze najdete na obvyklém místě na tomto WEBu.
Mnoho projektových manažerů pracuje ve stálém pracovním poměru. Ale nedávná krize a šetření, která jednotlivé firmy zasáhla, způsobila i významný odliv projektových manažerů na „volnou nohu“. Jejich role, autorita, ale i pracovní rytmus a administrativa se liší. A to ještě někteří z nich pracují skoro jako zaměstnanci, dlouhodobě pro jednoho zaměnstavatele, jiní jako „nomádi“ putují od jednoho projektu k dalšímu. Proto byla červnová diskuze věnována tomuto tématu. A byla zajímavá. Kromě jasného propočtu ukazujícího, že práce na „volné noze“ se i při započítání provozních nákladů a rizik vyplatí, zde padla i řada dalších zajímavých informací. Vyjmenujme si některé:
Je vidět, že uvedené poznatky nahrávají spíš k tomu odejít na „volnou nohu“ až po získání zkušeností a také rezerv.
Proč jsem hrdý na to, že jsem PMP? Protože si myslím, že to představuje dvě věci. Jednak zájem a ochotu investovat do profese, jejíž kredit se stále více zneužívá: do profese projektového manažera. Druhak jsou to faktory, které odlišují projektové manažery: strukturovaný přístup k problémům a reálné zkušenosti.
Při práci jako projektový manažer jsem brzy zjistil, že pro to, aby věci probíhaly správně, potřebuji nějaký rámec. Standard PMBOK je určen právě pro tento účel: vytváří referenční rámec, který může být přizpůsoben realitě a který slouží k formování toho, jak jsou projekty vedeny.
A teď k druhému faktoru, proč je certifikace PMP tak důležitá: je založena (nebo by měla být založena) na reálné životní zkušenosti. Je známo, že aby se uchazeč mohl přihloásit na zkoušku, musí předložit souhrn zkušeností v projektovém řízení, především musí prokázat, že pracoval jako projektový manažer po dobu nejméně 4500 hodin (zhruba 4 roky).
Dokonce i když splnění této podmínky lze snadno vykázat i když neodpovídá realitě (za předpokladu, že žádost není kontrolována), ten kdo vlastní PMP ví, že samotná zkouška spočívá spíše na reálných životních situacích než na teoretických otázkách a znalosti procesů PMBOK.
V praxi jsem zjistil, že skutečná zkušenost s projektovým řízením je velmi důležitá nejen při práci jako projektový manažer, ale také při hledání manažera projektů. Jednou z mých povinností byl i výběr kandidátů do role projektových manažerů a titul PMP opět přišel vhod – sloužil totiž pro prvotní rozdělení kandiátů. Po publikování inzerátu hledajícího PM jsem byl zavalen desítkami životopisů lidí, kteří dosud zjevně neměli s řízením projektů co do činění. Ne že by tyto životopisy nestály o přečtení: některé z nich byly velmi … zajímavé a v zpestřily můj pracovním den. Ale když jsem na životopisu četl „PMP“, už jsem věděl, že se mám životopisu věnovat podrobněji – možná je to ten správný, ale přinejmenším je to něco, co stojí za to číst.
V neposlední řadě je velmi dobrou vlastností PMP to, že certifikaci po určíté době vyprší platnost – nebo konkrétněji skutečnost, že pro zachování certifikace potřebujete pracovat jako PM a pracovat i na sobě. Pro ty z vás, kteří to neznají: znamená to získat během 3 let 60 jednotek PDU (Personal Development Units), přičemž 1 PDU zhruba odpovídá 1 hodině rozvoje. Samozřejmě i zde existují triky, které by tento požadavek obejít (alespoň do určité míry), ale pokud je snaha je splnit férově, pak toěch 60 PDU nutí zlepšit se, naučit se nové věci, navštěvovat semináře a konference a dostat se k novým věcem. A mimochodem, dotaz na to, jak uchazeč před vámi obnovuje certifikaci je docela zajímavá otázka k přijímacímu pohovoru.
PMP je tedy velmi dobrý milník na vaší cestě k profesionalitě: dává pevné základy, dobrou slovní zásobu a navíc může být velmi užitečný, když hledáte práci (nebo když hledáte dobré PM).
Zpracováno dle Giovanniho Perrone PgMP, PMP
Získal jsem certifikát PMP v roce 2007. Vzpomínám, že na přípravu jsem věnoval značné množství času. Nejprve jsem vyhledal všechny požadované informace a dokumenty, které PMI požaduje pro ověření kvalifikace. Pak jsem se začal připravovat na obávaných 200 otázek ve výběrové zkoušce.
Studoval jsem hlavně PMBOK a několik dalších knih a byl jsem docela dobře připraven na procesy, definice, oblasti domén atd. Jinými slovy, dobře jsem znal teorii, stejně jako bych se připravoval na zkoušku na univerzitu.
Ale při zkoušce jsem často zjistil, že si opakuji: „Kde jsou otázky o procesech, definicích a všech těch krvavých věcech, nad kterými jsem strávil takový čas studiem ???“
O zkloušce PMP lze totiž uvést zajímavou věc: zkouška, tedy kvíz s více volbami, je provedena tak, aby zjistila, zda skutečně máte praktickou zkušenost jako projektový manažer (samozřejmě v PMI). To, že můžete zpaměti recitovat PMBOK, se jaksi předpokládá a je to nutná podmínka.
Giovanni Perrone PgMP, PMP
Společná příprava k nejvyšší projektové certifikaci PMI přinesla další ovoce. Minulý týden získal titul Pavel Lebesle, kterého známe z přednášek právě na téma řízení programů. Není to jednoduché a je k čemu gratulovat!
A můžeme být pyšní, že v naší malé zemi již máme tři nositele této certifikace.
Zde najdete rady jak postupovat v situacích, které byly uvedeny na začátku Zpravodaje.
Tato hranice je daná kulturou firmy, není obecně definována. Otázka souvisí s autoritou PM. Ta formální je dána (metodikou, zvyklostmi, atd.), neformální je třeba postupně získávat. Některé postřehy pro udržení autority:
Udržet si nezávislost v srdci. Nebýt vydíratelný.
• Nezapomenout, že každý šéf má svého šéfa.
• Jenom hloupý šéf si myslí, že si kupuje zaměstnance a dovozuje, že ho tak trochu vlastní.
• Hned na začátku kriticky zhodnotit situaci a rozhodnout se, zda tu práci berete nebo nikoli, resp. stanovit si podmínky – plná moc, právo veta, atp.
K PMO: to se snaží nezávisle hledat v projektech problémy, a to na základě běžných výkazů i dalších informací. Případně se využívá projektový audit. Snaha by v obou případech měla směřovat k tomu nezatěžovat manažera projektu – využívat veřejné zdroje a PM využít pouze pro jejich případnou interpretaci.
Typická situace, kdy se rozhoduje o předčasném ukončení projektu, je ve chvíli, kdy je požadována záchrana projektu, který má velké problémy. Terminologicky: problém je to, co komplikuje život již nyní, riziko je to, co může nastat. Atributy projektu s velkými problémy (stačí jeden z dále uvedených):
• Velká / významná zpoždění v harmonogramu,
• Velká / významná překročení nákladů,
• Vzrůstají technické obavy o realizovatelnosti projektu,
• Vzrůstají problémy se subdodavateli,
• Velké množství „překvapení“.
V této chvíli je třeba rozhodnout a vybrat jednu ze tří možností: STOP, FIX nebo CONTINUE “AS IS”. Postupuje se v následující sérii kroků:
1. Je dosud projekt ještě vůbec potřeba? Ne -> Stop, Ano – dále.
2. Je aktuálně projet ještě výhodný / rozumný? Ne -> Stop, Ano – dále.
3. Měli bychom zkusit fixovat problém nebo pokračovat jak je? “As Is” nebo Fix
4. Co je podstata problémů, co je špatně? – Problem Defined
5. Jak to lze vyřešit? – Solution Defined
6. Implementace řešení, jeho sledování
Ad 1.:
• Kontrakt – musíme pokračovat, není co řešit
• Projekt pro interní zlepšení procesů: možná jsou jiná zlepšení důležitější než tento a ukončení projektu jim pomůže? Nebo je nezbytné?
• Marketingová kampaň: možná jsou jiné marketingové metody účinnější? Nebo je tento projekt nezbytný?
• Vývojový nebo R&D projekt: Možná se trh změnil a produkt v zamýšleném tvaru není již tak atraktivní? Nebo je produkt projektu kritickým krokem strategického plánu?
Ad 2.:
• Projekt může být docela rozumný, ale třeba nebyl rozumný nikdy, nebo svoje opodstatnění mezitím ztratil
• Některé z problémů, které mohou způsobit, že projekt není realizovatelný:
◦ nezdolné technické překážky
◦ nerealistický harmonogram
◦ neadekvátní financování
◦ neadekvátní zdroje
◦ problémy s podporou podílníků
◦ …..atd………………
• Příklady:
◦ Kontrakt: zákazníkovi došly peníze
◦ Marketingová kampaň: marketingový koncept není tak, jak by byl potřeba
◦ Zlepšování: je zřejmé, že touto cestou se plánovaného zlepšení nedosáhne
◦ Vývoj nebo R&D projekt: technologie asi neposkytne požadovanou funkcionalitu nebo vede na příliš nákladný produkt
Ad 3.:
• Je třeba uvážit:
◦ Zbývající čas
◦ Aktuální problémy a potenciál úspěchu
◦ Pravděpodobnost akceptovatelného úspěchu
◦ Podpora managementu a zákazníka
◦ Přístup členů týmu a dodavatelů
◦ Zdroje k dispozici
◦ Otevřená rizika
◦ …….atd…………………………
• Doporučuje se získat informace v diskuzi s klíčovými podílníky, oni mohou znát např. i záporné dopady předčasného ukončení projektu.
Ad 4.:
• Doporučuje se využít nezávislé posouzení
• Nezapomeňte, že většina projektů má víc problémů a mnoho problémů může mít víc příčin
• Je třeba jít po příčinách a ne po symptomech, jejich léčení nezlepší stav projektu! Příklad:
◦ Projekt je zpožděn – proč?
◦ V určité oblasti jsou zpoždění – proč?
◦ V té oblasti je nízká produktivita – proč?
◦ Produktivita je negativně ovlivněna nestabilním zadáním – proč?
◦ Požadavky se nepodařilo u zákazníka stablilizovat formou potvrzení – toto je klíčový důvod problémů! Ostatní položky jsou pouze symptomy, které vedly k odhalení příčiny.
• Obvyklé příčiny:
◦ Oblast požadavků:
▪ Zákazník neví, co opravdu potřebuje
▪ Zákazník mění průběžně požadavky
▪ Zákazníkovy požadavky nejsou erálné v daném omezení časem a/nebo penězi
◦ Oblast nabídky:
▪ Připravena jen s omezenými zdroji či časem
▪ Připravena v době, když nebyly známy požadavky
◦ Oblast plánu projektu:
▪ Nevychází z adekvátních požadavků
▪ Technické řešení není dostatečně promyšlené
▪ Její přípravě nebylo věnováno dost kompetentních zdrojů
▪ Je zastaralý a neodpovídá aktuálnímu stavu projektu
◦ Organizace a orgány projektu:
▪ Nejsou kompletní nebo nejsou adekvátně implementovány
▪ Nevycházejí z dobrého plánu projektu
▪ Není dobrá stavová informace
▪ Stavová informace není analyzována tak, aby byla zjišťována skutečná příčina
▪ Korektivní akce nejsou nebo nejsou sledovány
◦ Oblast řízení rizik:
▪ Chybí
◦ Oblast obstarávání:
▪ Slabé požadavky na projekt, plán nebo organizace, která by řídila dodavatele
▪ Nevhodně definované požadavky na dodavatele
▪ Nevhodná nebo nedostatečná kontrola dodavatelů
▪ Oblast lidských zdrojů:
▪ Nezkušený projektový manažer a/nebo team leader
▪ Zdroje neodpovídají požadavkům projektu – množstvím, kvalitou, profesí
Ad 5:
• Doporučuje se postupovat v následující posloupnosti:
◦ Požadavky – vyvinout postup pro vyřešení všech existujících problémů v požadavcích, pokud zde problémy neexistují, pak ověřit, že požadavky jsou adekvátní.
◦ Definice výstupu – Začněte pracovat až budou opravdu všechny sporné požadavky vyřešeny, pak připravte adekvátní definici výstupů tak, aby ji projektový tým velice dobře chápal.
◦ Plán – Nemodifikujte plán projektu, dokud nebudou vyřešeny předchozí body. Následně přeplánujte zbytek projektu, doporučuje se využít služeb zkušeného plánovače projektů. Následně prověřte vůči problémům, že nový plán je opravdu lepší.
◦ Změna směru – Neměňte směr moc často, tým by ztratil směr a kontext. Změnu je třeba pečlivě vysvětlit a obhájit klíčovým podílníkům.
◦ Řízení projektu – používejte adekvátní techniky řízení projektu, vzhledem k fázi, v níž se nalézá (na začátku inspirativní a kolektivní, na konci rozhodovací). Uvažte, zda by se tým neměl vzdělat v základech technologie řízení projektů.
◦ Dodavatelé projektu – Je-li problém ve vztahu ke špatnému výkonu dodavatele, pak je třeba určit pravou příčinu a následně s ní musí pracovat celý projektový tým tak, aby se stav zlepšil.
◦ Zdroje – Není-li to nutné, neměňte je.
Někdy jsou však problémy nikoli v projektu, ale ve firmě, v níž probíhá! Příznaky:
• Bezva nápad jde do ztracena
• Zlepšení nevede k zamýšlené změně
• Zlepšení vydrží jen chvíli a pak se vše vrátí ke starému
• Odpor proti změnám
Známá teorie říká, že v mozku jsou 4 zóny a lidé se liší podle toho, která z nich je u nich primární (typologie MBTI vycházející z Hippokrata). Při přípravě prezentace neznáme publikum, měla by proto mířit na všechny typy a umožnit jejich ztotožnění se. Proto by měla být v této sekvenci:
1. Stav (věcné zhodnocení – pro racionála)
2. Pocit z tohoto stavu (pocitové zhodnocení – pro hráče)
3. Cíl (kam se chceme dostat – pro idealistu)
4. Harmonogram (kroky, které povedou k cíli – pro strážce)
Pokračujeme v seriálu, který čerpá a bude čerpat z ohromného rezervoáru rad a zkušeností získaných na nesčetných diskuzích, které již v rámci Projektového Undergroundu proběhly. Nejde o teoretické rozbory, ale naopak o zcela praktické situace a jejich řešení. Snažíme vybrat situace, které se na diskuzích opakovaly, a také postupy, které v praxi pomohly. Tentokrát jsme se zaměřili na rady a zkušenosti z minulé diskuze na téma motivace k rutinním činnostem v projektu.
Nejprve najdete popis situace a odpověď či doporučené řešení je až dále v textu Zpravodaje. To proto, abyste si mohl(a) vyzkoušet, jak byste takovou situaci řešil(a) sám, kdybyste se s ní setkal – a pak si porovnat svoje zkušenosti se zkušenostmi ostatních. No a vůbec nejraději budeme, pokud se popisem „strefíme“ do problému, který vás aktuálně trápí, a přispějeme tak zkušenostmi k jeho řešení.
JKde je vhodné aby končily pravomoci PM a kde by měly začínat pravomoci dalších subjektů (řídící rada, PMO, představenstvo firmy, …)?
Existuje postup jak zachránit projekt?
Existuje osvědčený trik co dát do prezentace aby motivovala k rozhodnutí?
Ve čtvrtek 11.5. proběhla v prostorách firmy Vodafone zajímavá diskuze na téma „Nakolik je potřebná znalost předmětu projektu pro PM“. Během diskuze se ukázalo, že je nutné rozlišovat, i když se to ne vždy děje, technologickou znalost od projektové zkušenosti – jsou to zcela jiné vlastnosti. Jednoznačný závěr na otázku, která vymezila předmět diskuze, jsme nenašli. Zaznělo ale řada zajímavých názolů – některé z nich lze anít v zápise z diskuze na našem WEBu.
Zároveň diskuze inspirovala k brainstormingu na téma „Co to je vlastně zkušenost PM? Jak se měří / zjišťuje?“ Tento brainstorming zkušených PM proběhne 20. září večer a bylo by krásné, kdyby z něho postupně mohla vzniknout nějaká přednáška – nevíme zatím o žádné, která by se tomuto tématu věnovala. Tak uvidíme, jestli ta ambice není přehnaná.
Jak zjistíte, kdy je nutné eskalovat rozhodnutí na projektového sponzora? Následující anketa, zpracovaná podle PM network, časopisu PMI(R), ukazuje promítání kulturních rozdílů do úvah na toto téma. A jak jste na tom vy? Položili jste si také otázku kdy eskalovat a kdy ne? Třeba Vám některé z informací a postupů v anketě pomohou najít pro Vás správnou odpověď.
DODRŽUJ PRAVIDLA
Eskaluji rozhodnutí, je-li mimo moje oblasti kontroly nebo dohodnuté tolerance. Například v nedávném projektu, který přinesl procesní změnu, jsme si uvědomili, že konkrétní řešení schválené sponzorem nebude v každé situaci fungovat. Věděli jsme, že se musíme vrátit k základu. Ale protože to znamenalo změnu přístupu k projektu a odchýlení se od schváleného řešení, bylo to rozhodnutí, které měl udělat sponzor. Jakmile sponzor přezkoumal nový postup a schválil ho, byl tým schopen pokročit v projektu.
-Elizabeth Herrin, ředitel, skupina Otobos, Horsham, Anglie
PŘIPRAVENO K ŘEŠENÍ
Nikdy nechci, aby byli sponzoři a klíčoví akcionáři překvapeni. Pokud je třeba eskalovat něco, obvykle je to riziko, a je třeba mluvit o možnostech jeho zmírnění. Pokud se objeví překvapení, budu s týmem rychle hledat možnosti řešení a naše oficiální doporučení předložím sponzorovi. Moje konverzace s ním je proto krátká a věcná a vyhýbá se hledání viny. Našim společným úkolem v tomto okamžiku je vyřešit problém.
Jason Orloske, PMP, manažer, odd. projektového managementu, Aldevron, Fargo, Severní Dakota, USA
KRITICKÁ KRITÉRIA
Především by měl projektový manažer získat důvěru sponzora a podporovat ho od začátku až do konce. Tím je zajištěno, že jakýkoliv problém může eskalovat ve správný čas. Ale nelze eskalovat na sponzora každé rozhodnutí, tím ztratíte jeho pozornost v okamžiku, když je eskalace skutečně nutná. Projektoví manažeři by měli eskalovat rozhodnutí na sponzora, když nastaly následující problémy
– Problém ovlivňuje schopnost získat financování, vynakládat zdroje nebo dosáhnout úspěchu projektu.
• V celé organizaci není podpora projektu.
• Rozhodnutí vyžaduje oprávnění ke změně rozsahu.
• Rozhodnutí vyřeší situaci typu „go / no-go“.
Ipek Sabra Ozgöler, PMP, projektový manažer, kancelář pro řízení projektu, Halkbank, Ankara, Turecko
PLÁN PRO DISKUSE
Mám setkání se sponzory na dvoutýdenní bázi, kde mluvíme pouze o rozhodnutích nebo jak řešit rizika a problémy. Tyto schůzky představují typický prostor, kde eskaluji problémy – pokud riziko není tak velké, aby nemohlo počkat na setkání. Ale eskaluji pouze takové problémy nebo rizika, která silně ovlivní časovou osu, rozpočet nebo rozsah.
Fernando Perez, PMP, regionální projektový manažer, Citi, Buenos Aires, Argentina
PODMÍNĚNÉ PROBLÉMY
Jakékoli rozhodnutí, které může mít vliv na náklady, harmonogram nebo rozsah by mělo být eskalováno na sponzora. Abyste získali okamžitou pozornost a rychlou odpověď, eskalace by měla být přímo nebo telefonicky. Následný e-mail může obsahovat požadavek na rozhodnutí a detily k předmětu rozhodnutí.
Charanjeet Singh, PMP, projektový manažer, pojišťovna Wawanesa, Winnipeg Manitoba, Kanada
NEBEZPEČNÉ RIZIKO
Eskalovat pouze tehdy, když klíčový účastník záměrně brání implementaci plánu projektu. Jedním z příkladů je klient, který odmítá formálně přijmout výsledky během procesu validace rozsahu, a to i poté, co výsledky prošly procesem kontroly kvality. Identifikoval jsem všechna rizika s tím spojená a připravil jsem rezervu na tato rizika v plánu, který jsem předal sponzorovi ke schválení.
Talal Benothman, PMP, generální ředitel, Design, inženýrství a architektura Dar At Rijádu, Rijád, Saúdská Arábie
Víme, že existuje řada projektů. Například při tvorbě metodiky je velkou otázkou, jak kategorizovat projekty – dost často se to udělá pouze na základě finančně vyjádřených nákladů, a postupně se ukáže, že to není dobré. Správné definování kategorií projektů v dané organizaci je ale užitečné z několika důvodů. Proces řízení životního cyklu projektu se v jednotlivých kategoriích značně liší a pro každý projekt je třeba aplikovat nejvhodnější postup. Rozvojem a neustálým zlepšováním procesu pro každou kategorii projektů mohou manažeři zajistit jistý stupeň standardizace, který bude použit pro řízení jejich projektů.
Existuje mnoho způsobů kategorizace projektů; například: velikost, komplexnost, zeměpis, technologie, riziko (ekonomické, technologické, politické), povaha konečného produktu nebo výsledku, podnikatelský nebo průmyslový sektor, zúčastněný hospodářský nebo politický sektor a další.
Deset doporučených základních kategorií projektů je uvedeno v následující tabulce. Projekty v rámci každé z těchto kategorií mají během svého životního cyklu velmi podobné fáze a využívají velmi podobnou autorizaci, plánování, rozpočtování, sledování a kontrolní postupy a nástroje. Ve většině z 10 základních kategorií jsou také identifikovány podkategorie, protože mezi procesem řízení životního cyklu základní kategorie a podkategorií mohou existovat rozdíly, v některých případech významné.
| Project Categories |
Examples |
|---|---|
|
1. Aerospace/Defense Projects 1.1 Defense systems 1.2 Space 1.3 Military operations |
New weapon system; major system upgrade. Satellite development/Iaunch; space station mod. Task force invasion. |
|
2. Business and Organization Change Projects 2.1 Acquisition/Merger 2.2 Management process improvement 2.3 New business venture 2.4 Organization restructuring 2.5 Legal proceeding |
Acquire and integrate competing company. Major improvement in project management. Form and launch new company. Consolidate divisions and downsize company. Major litigation case. |
|
3. Communication Systems Projects 3.1 Network communications systems 3.2 Switching communications systems |
Microwave communications network. Third generation wireless communication system. |
|
4. Event Projects 4.1 International events 4.2 National events |
2004 Summer Olympics; 2006 World Cup Match. 2005 U.S. Super Bowl; 2004 Democratic and Republican Political Conventions. |
|
5. Facilities Projects 5.1 Facility decommissioning 5.2 Facility demolition 5.3 Facility maintenance and modification 5.4 Facility design/procurement/construction
|
Closure of nuclear power station. Demolition of high rise building. Process plant maintenance turnaround.
Conversion of plant for new products/markets. Flood control darn; highway interchange. New gas-fired power generation plant; pipeline. Chemical waste cleanup. New shopping center; office building. New housing subdivision. |
|
6. Information Systems (Software) Projects |
New project management information system. (Information system hardware is considered to be in the product development category.) |
|
7. International Development Projects 7.1 Agriculture/rural development 7.2 Education 7.3 Health 7.4 Nutrition 7.5 Population 7.6 Small-scale enterprise 7.7 Infrastructure: energy (oil, gas, coal, power generation and distribution), industrial, telecommunications, transportation, urbanization, water supply and sewage, irrigation) |
People and process intensive projects in developing countries funded by The World Bank, regional development banks, US AID, UNIDO, other UN, and government agencies; and Capital/civil works intensive projects—often somewhat different from 5. Facility Projects as they may include, as part of the project, creating an organizational entity to operate and maintain the facility, and lending agencies impose their project life cycle and reporting requirements. |
|
8. Media and Entertainment Projects 8.1 Motion picture 8.2 TV segment 8.2 Live play or music event |
New motion picture (film or digital). New TV episode. New opera premiere. |
|
9. Product and Service Development Projects 9.1 Information technology hardware 9.2 Industrial product/process 9.3 Consumer product/process 9.4 Pharmaceutical product/process 9.5 Service (financial, other) |
New desk-top computer. New earth-moving machine. New automobile; new food product. New cholesterol-lowering drug. New life insurance/annuity offering. |
|
10. Research and Development Projects 10.1 Environmental 10.2 Industrial 10.3 Economic development 10.4 Medical 10.5 Scientific |
Measure changes in the ozone layer. How to reduce pollutant emission. Determine best crop for sub-Sahara Africa. Test new treatment for breast cancer. Determine the possibility of life on Mars. |
Tyto kategorie se nemusí nutně vzájemně vylučovat: mnoho projektů bude zahrnovat aspekty dvou nebo více kategorií. Například většina projektů telekomunikačních systémů zahrnuje přizpůsobení softwaru informačního systému. Mnohé staqvební projekty, jakkoliv z jiné katefgorie, rovněž zahrnují telekomunikační systémy a naopak. V takových případech by měl být projekt pravděpodobně zařazen do dominantnější kategorie nebo, pokud je to odůvodněno jejich velikostí, složitostí nebo definovaným rizikem, jako dva nebo více projektů (různých kategorií) v rámci programu.
Programy často obsahují projekty a ty jsou ze dvou nebo více základních kategorií. Mezi hlavní programy telekomunikačních systémů patří nejen projekty v kategorii telekomunikace ale například i zařízení, letectví či informačních systémů. Každý projekt musí být naplánován a řízen pomocí jeho individuálního procesu řízení, nad tím je na úrovni programu integrace, která spojuje jednotlivé projekty na příslušných bodech nebo v událostech.
V rámci jednotlivých kategorií projektů se často ve velkých organizacích vyskytuje široká škála projektů – od malých po velké. Proces řízení projektu pro každou kategorii projektů musí tak0 reflektovat dal39 aspekty a poskytnout flexibilitu při výběru správné úrovně plánování a kontroly.
Velikost projektu
Velikost projektu může být měřena v několika směrech: nejvíce hmatatelné a zřejmé je množství peněz, lze však využít i množství dalších vzácných zdrojů (lidé, dovednosti nebo zařízení), velikost rozsahu (například počedt use-case v analytickém dokumentu) či geografický záběr. Větší projekty obvykle přinášejí větší rizika – ale ne vždy.
Složitost projektu
Složitost projektu je charakterizována rozmanitostí, která je součástí cílů a rozsahu projektu, a počtem různých zúčastněných interních a externích organizací a oddělení, což je obvykle ukazatel počtu požadovaných odborných dovedností, zdrojů technologií nebo zdrojů financování. Projekt, který vyžaduje pouze dovednosti a další zdroje jedné provozní divize, je obvykle z hlediska řízení méně složitý než projekt společného podniku podporovaný dvěma samostatnými společnostmi. Složitost vzrůstá exponenciálně s počtem zúčastněných organizací. Běžným zdrojem složitosti projektu je i míra interakce s operacemi mimo projekt. Projekty, které jsou prováděny pod dohledem regulační agentury jsou obvykle složitější než projekty bez dozoru.
Externí nebo interní zákazník
Je-li projekt realizován na základě formální smlouvy s externím zákazníkem, bude řízení poněkud jinak než kdyby byl zaměřen na interního zákazníka. Smluvní podmínky mají přímý vliv na míru rizika spojeného se smluvním projektem; a pokud jsou dobře navrženy pak mohou rizika zmírnit. Interní projekty obvykle nejsou provázeny právními omezeními a postihy, což může vést k podcenění plánování a kontroly projektů. To zvyšuje riziko, že projekt nesplní požadované cíle.
Relativní význam daného zákazníka má často velký vliv na prioritu projekt a způsob jeho řízení.
Stupeň zapojení zákazníka do projektu
Na mnoha projektech se může zákazník podílet výraznou měrou. Obvykle dělá důležitá rozhodnutí a poskytuje klíčové know-how. Nesoučinnost zákazníků je častými příčinami zpoždění a zvýšených nákladů. Je proto nezbytné, aby byly zákaznické části projektu naplánovány tak, aby byly dobře integrovány se zbytkem projektu. To znamená, že projektový manažer zákazníka se aktivně účastní zasedání týmu, hodnocení projektu a že je především zodpovědný za součinnost poskytovanou do projektu.
Úrovně rizik v projektech
Rizika spojená s projekty se liší v rámci jednotlivých kategorií projektů. Některé z hlavních faktorů, které ovlivňují riziko, jsou:
Novost a neznámost (nízká míra zkušeností) daného typu projektu pro organizaci.
Velikost, jak bylo popsáno výše.
Doba trvání a naléhavost dokončení: Vyšší riziko v případě krátkého trvání s pevným datem ukončení nebo dlouhého trvání s pravděpodobnými nepředvídatelnými ekonomickými nebo politickými změnami.
Složitost, jak bylo popsáno dříve.
Technologie: stupeň inovace a nejistota ohledně technologie výrobku nebo jeho výrobního procesu (může souviset s novostí).
Externí zákazník (projekt na zakázku) nebo interní zákazník, jak bylo uvedeno výše, a jejich celkový význam pro organizaci.
Smluvní podmínky: sankce, záruky, směnky.
Potřebný regulační dohled a schválení.
Stupeň zapojení zákazníků do projektu.
Volatilita trhu.
Dostupnost omezených zdrojů: kvalifikovaní, zkušení lidé, specializovaná zařízení.
Hlavní a drobné projekty v rámci kategorie
Je vhodné identifikovat nejméně dvě třídy projektů v každé kategorii. Obvykle se nazývají jako velké a malé projekty, ale organizace může využívat i jiná jména. V některých organizacích jsou dokonce definovány tři takové třídy (např. A, B a C). Rozdíl mezi velkými a malými třídami je uveden v následujících definicích:
Velké projekty jsou ty, jejichž velikost, velká složitost a / nebo vysoké riziko vyžadují:
Nutnost formálního ustavení sponzora projektu.
Alokace manažera projektu (nebo programu) na plný úvazek.
Plné uplatnění procesu řízení projektů specifikované pro konkrétní projektovou kategorii pro velké projekty (všechny specifikované formuláře, schválení, plány, plány, rozpočty, kontroly, zpětné vyúčtování, časté schůzky pro přezkoumání projektů, se značnou mírou podrobnosti v každý).
Malé projekty jsou projekty, jejichž velikost, jednoduchost a nízké riziko umožňují:
Jeden projektový manažer může současně řídit dva nebo více projektů.
Neúplné uplatnění celého procesu řízení projektů pro ¨danou kategorii (používají se pouze vybrané základní formuláře, schválení, plány, plány, rozpočty, kontroly, zprávy, méně časté přezkoumání projektů, s menšími podrobnostmi požadovanými v každém z nich).
Někdy ani nevyžaduje formální ustavení role sponzora projektu.
Kromě těchto velkých a menších projektů se někdy můžeme potkat s tzv. mega projekty. Jedná se o mimořádně velké projekty, které obvykle zahrnují velké množství společností a / nebo agentur. Příklady takových mega projektů jsou mezinárodní společné podniky v oblasti vesmíru, dopravy, energetiky a dalších oblastí. Megaprojekty mohou být financovány z různých zdrojů: vládních, soukromých a mezinárodních rozvojových bank a obvykle překračují mezinárodní hranice. Mega projekty jsou mimo rozsah výše popsané velké klasifikace projektů, ale jsou spíše vzácné.
Zpracováno dle knihy Archibald R.D., Managing high-technology programs&projects
