- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (77)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
Hlavní partner sekce
Tematické sekce
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tiskBranové sekce
![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Partneři webu
IT SYSTEMS 4/2010 , AI a Business Intelligence , Projektové řízení
Existuje mnoho materiálů zaměřených na principy řízení projektů a na to, jak pracovat s nástroji, které projekty podporují. Tento článek není primárně ani o nástrojích, ani o metodikách. Jeho mottem je, jak uspět při řízení projektů a nezabřednout do bezpočtu procesních návodů nebo technologických fines.
Úspěně řídit projekt znamená nalézt rovnováhu mezi třemi světy: světem metodických návodů a doporučení, světem softwaru a světem obecných manaerských předpokladů. Neexistuje vak univerzální stav, který by se dal obecně doporučit pro vechny projekty, a kadá organizace si svou rovnováhu musí nalézt sama. Typy, velikost a mnoství projektů, schopnosti a kapacita zdrojů, počet zainteresovaných stran v projektu a dalí proměnné mohou platnost následujících odstavců v podmínkách konkrétní organizace změnit (viz box specifika řízení projektů vývoje softwaru).
Obr. 1: MS Project model projektového portfolia s vyznačenými projekty k vyřazení (červené body v grafu)
Obr. 2: MS Project přehled vytíení zdrojů napříč vemi projekty
Obr. 3: MS Project zobrazení pro sledování projektu (jak byl plánován, jak je plánován nyní, kolik práce je ji odvedeno, které úkoly mohou zpodění kompenzovat a vrátit projekt do správných kolejí)
Proces vykazování práce lze rovně automatizovat, nicméně je třeba si poloit i několik metodických otázek týkajících se formy aktualizace. Je třeba si ujasnit, zda se budou úkoly aktualizovat jako celky, nebo po časových úsecích (kadý den), zda se bude plnění sledovat průběně, nebo metodou 0/100 (úkol zahájen, úkol dokončen) a tak dále.
Důleitým faktorem úspěchu kadého projektu je zejména zadavatel, který je středobodem řízení celého projektu. Právě on rozhoduje o výsledku a proces poznání poadavků, sledování jejich vývoje a zapracování změn do projektu tak představují dalí měkkou a nedílnou součást projektu.
Obr. 4: Znalostní databáze jako Wikiweb
Více informací o softwarové podpoře řízení projektů naleznete v knize autora tohoto článku s názvem Řízení projektů: Nejlepí praktiky s ukázkami Microsoft Office.
Obr. 5: Intranetová stránka projektové kanceláře
Softwarová podpora řízení projektů
Bez metodických pravidel to ale nejde
Drahoslav Dvořák
Existuje mnoho materiálů zaměřených na principy řízení projektů a na to, jak pracovat s nástroji, které projekty podporují. Tento článek není primárně ani o nástrojích, ani o metodikách. Jeho mottem je, jak uspět při řízení projektů a nezabřednout do bezpočtu procesních návodů nebo technologických fines.
Úspěně řídit projekt znamená nalézt rovnováhu mezi třemi světy: světem metodických návodů a doporučení, světem softwaru a světem obecných manaerských předpokladů. Neexistuje vak univerzální stav, který by se dal obecně doporučit pro vechny projekty, a kadá organizace si svou rovnováhu musí nalézt sama. Typy, velikost a mnoství projektů, schopnosti a kapacita zdrojů, počet zainteresovaných stran v projektu a dalí proměnné mohou platnost následujících odstavců v podmínkách konkrétní organizace změnit (viz box specifika řízení projektů vývoje softwaru).
Iniciace projektu aneb Jak zhodnotit projekt
Výstupem první fáze ivotního cyklu projektu je předevím objektivní zhodnocení záměrů projektu a vyřazení nerealizovatelných aktivit, a to dříve, ne jim bude věnováno větí úsilí. Snaha o objektivitu se zpravidla střetává se subjektivními názory z různých stran účastníků projektu a výsledkem poté bývají projekty s vysokou, velmi vysokou, nebo kriticky vysokou prioritou. Nástroje na podporu optimalizace skladby portfolia mohou v této fázi do jisté míry pomoci například v tom, e komplexní problém, určení priority projektu, bude vyřeen jeho rozdrobením do meních a uchopitelnějích kroků. Nejprve je tedy dobré stanovit cíle organizace a jejich priority, dále určit míru příspěvku projektu k jednotlivým cílům organizace, a teprve poté stanovit prioritu celého projektu.
Obr. 1: MS Project model projektového portfolia s vyznačenými projekty k vyřazení (červené body v grafu)
Plánování aneb Jak postavit dobrý plán
Plán nevzniká pouze proto, aby existoval, ale proto, aby na jeho základě bylo moné projekt implementovat. Moná to zní triviálně, nicméně drtivá větina plánů, které jsou sestavené pomocí MS Project, trpí zásadními logickými chybami. Plán pak není pro manaera oporou, ale nepřítelem, který otravuje ivot ve formě nekonečného proudu dialogových oken, vykřičníků apod. Je třeba si uvědomit, e softwarové nástroje neznají charakteristiku projektu neví například, e dům stavíte v lokalitě, kde 360 dní v roce prí, nebo kde teplota po celý rok nepřekročí bod mrazu. Neznají také, kolik úkolů je třeba vykonat k dosaení cíle projektu, jak dlouho přiblině budou trvat, kam je třeba zadat milníky, zda přiřazený zdroj úkol skutečně zvládne atd. Nástroje vak mohou pomoci sestavit přehledný plán s vyznačenou kritickou cestou, optimálně vyuitými kapacitami zdrojů (a to i vzhledem k ostatním projektům) a se spočítanými náklady porovnanými s celkovým rozpočtem.
Obr. 2: MS Project přehled vytíení zdrojů napříč vemi projekty
Sledování aneb Jak se projekt odchýlil od plánu
Smyslem sledování projektu je zjistit, v jaké míře se projekt odchýlil od původně zamýleného plánu. Odchylky jsou standardní součástí projektu a snaha odchylkám zcela předejít se zpravidla míjí účinkem. Uitečným pomocníkem pro určení velikosti odchylky a její závanosti je směrný plán, který zpravidla představuje finální verzi plánu schválenou zadavatelem. Nástroje tak mohou v této fázi manaerovi pomoci jak při kvantifikaci odchylky (nakolik se projekt odchýlil časově, finančně nebo obsahově), tak při její kvalifikaci (zda má odchylka vliv na kritickou cestu, tedy zda prodluuje projekt). Na základě těchto informací se pak lze rozhodnout, jak s projektem dále naloit.
Obr. 3: MS Project zobrazení pro sledování projektu (jak byl plánován, jak je plánován nyní, kolik práce je ji odvedeno, které úkoly mohou zpodění kompenzovat a vrátit projekt do správných kolejí)
Proces vykazování práce lze rovně automatizovat, nicméně je třeba si poloit i několik metodických otázek týkajících se formy aktualizace. Je třeba si ujasnit, zda se budou úkoly aktualizovat jako celky, nebo po časových úsecích (kadý den), zda se bude plnění sledovat průběně, nebo metodou 0/100 (úkol zahájen, úkol dokončen) a tak dále.
Řízení aneb Jak dostat projekt zpět do správných kolejí
Zatímco u vech předchozích fází řízení projektu lze o roli podpůrných nástrojů diskutovat, při řízení je jasné, e rozhodnutí, jak projekt vrátit do správných kolejí, spočívá na manaerech projektu a ádný software je této povinnosti nezbaví. Nástroje mohou cestu naznačit a mohou také ukázat, nakolik bylo rozhodnutí pro projekt přínosné. Řízení projektu dále zahrnuje motivaci členů týmu a komunikaci s účastníky projektu, kterou nástroje opět pouze formálně podpoří. Tím ale jejich monosti končí a o tom, co, jak, kdy a komu adresovat, rozhoduje lidský faktor.Důleitým faktorem úspěchu kadého projektu je zejména zadavatel, který je středobodem řízení celého projektu. Právě on rozhoduje o výsledku a proces poznání poadavků, sledování jejich vývoje a zapracování změn do projektu tak představují dalí měkkou a nedílnou součást projektu.
Specifika projektového řízení při vývoji softwaru
Projekty vývoje softwaru jsou zatíeny značnou mírou nejistoty. Pracnost úloh je hůře odhadnutelná, řadu z nich nelze efektivně zkrátit ani navýením zdrojů, výkonnost jednotlivých pracovníků můe být velmi odliná apod. Postupovat lze v zásadě dvojím způsobem:Tradiční projektové řízení
Vysoká dynamika vývoje, která zpravidla vede k nutnosti často měnit projektový plán během vývoje na základě nově zjitěných skutečností, do jisté míry rozbíjí tradiční koncept řízení projektů. Často tak dochází k rozdělení celého projektového řízení. Zatímco na makro úrovni se postupuje podle projektového plánu, na mikro úrovni se pouívají různé pomocné nástroje pro evidenci úloh, chyb a rizik. Aby byl tento přístup efektivní, je nutné zajistit automatické propojení mezi oběma systémy, nastavit celý proces tak, aby se údaje o postupu členů týmu sbíraly automatizovaně a nebylo nutné spoléhat na manuální aktualizaci plánu a evidencí, která bývá nepřesná a opoděná.Pouití agilních metodik
Agilní metodiky v podstatě rezignují na projektové řízení a přistupují k projektu čistě statisticky. Projekt se rozdělí na desítky částí či scénářů (user stories) a kadé se přiřadí relativní pracnost v podobě bodů (tzv. story points). Práce probíhá na základě krátkých časových úseků o stejné délce nazývaných iterace nebo té sprinty. Rychlost postupu se pak měří počtem bodů, které je projektový tým schopen spálit za jednu iteraci (kapacitu týmu). Na začátku kadé iterace je plánovací porada, kde se analyzují zjitění a poznatky z poslední iterace a na základě změřené týmové kapacity se plánuje práce pro nadcházející iteraci. Výhodou tohoto postupu je minimální reie a schopnost rychlé reakce na změnu situace. Nevýhodou je vyí riziko a nejistota ohledně celkového času i pracnosti.Ukončení projektu aneb Jak neopakovat chyby
Fáze ukončení projektu má za cíl předevím předejít stejným problémům při realizaci dalích projektů. Vedle formální dokumentace je proto vhodné udrovat i znalostní databázi projektového řízení. I zde platí, e obsahová stránka věci (co se bude zaznamenávat) závisí na lidech, zatímco formální stránka (jak a kam se bude zaznamenávat) na nástrojích. Ideálními pomocníky jsou například wiki stránky tedy interní encyklopedie znalostí, které mohou být poté spojeny s projektovou metodikou organizace. Při sestavování formální dokumentace projektu (akceptační protokoly, smlouvy, zápisy, změnová řízení apod.) lze vyuít funkcionalit nástrojů pro řízení dokumentace, jako například workflow, verzování či archivace.
Obr. 4: Znalostní databáze jako Wikiweb
Projektová kancelář aneb Jak mít smysluplnou projektovou metodiku
Rovnováhu metodik, softwarových nástrojů a manaerských postupů platných pro danou organizaci popisuje projektová metodika. Starost o její obsah a formu spadá do kompetencí projektové kanceláře. Toto oddělení má za úkol neustále mapovat nové metodiky a nástroje dostupné pro řízení projektů a vybírat ty, které lze aplikovat na projekty v dané organizaci, a nahrazovat komponenty, je jsou zastaralé nebo nefunkční.Více informací o softwarové podpoře řízení projektů naleznete v knize autora tohoto článku s názvem Řízení projektů: Nejlepí praktiky s ukázkami Microsoft Office.
Obr. 5: Intranetová stránka projektové kanceláře
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 naeho archivu.




















