- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (48)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
Tematické sekce


















Branžové sekce
![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý 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 manažerských předpokladů. Neexistuje však univerzální stav, který by se dal obecně doporučit pro všechny projekty, a každá organizace si svou rovnováhu musí nalézt sama. Typy, velikost a množství 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říč všemi 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 zpoždě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 položit 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 (každý 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ůležitým faktorem úspěchu každé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í požadavků, 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



Ú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 manažerských předpokladů. Neexistuje však univerzální stav, který by se dal obecně doporučit pro všechny projekty, a každá organizace si svou rovnováhu musí nalézt sama. Typy, velikost a množství 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řešen 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 možné projekt implementovat. Možná to zní triviálně, nicméně drtivá většina plánů, které jsou sestavené pomocí MS Project, trpí zásadními logickými chybami. Plán pak není pro manažera 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 dosažení cíle projektu, jak dlouho přibližně budou trvat, kam je třeba zadat milníky, zda přiřazený zdroj úkol skutečně zvládne atd. Nástroje však mohou pomoci sestavit přehledný plán s vyznačenou kritickou cestou, optimálně využitý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říč všemi 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. Užitečným pomocníkem pro určení velikosti odchylky a její závažnosti 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 manažerovi 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 prodlužuje projekt). Na základě těchto informací se pak lze rozhodnout, jak s projektem dále naložit.
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 zpoždě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 položit 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 (každý 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 všech 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 manažerech 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 možnosti končí a o tom, co, jak, kdy a komu adresovat, rozhoduje lidský faktor.Důležitým faktorem úspěchu každé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í požadavků, 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 odlišná 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ě zjiště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 opožděná.Použití 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 každé 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 každé iterace je plánovací porada, kde se analyzují zjiště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í režie 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é udržovat 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 manažerský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 našeho archivu.


![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
IT Systems podporuje
Formulář pro přidání akce
Další vybrané akce
15.5. | Konference SCADA Security |
22.5. | Akce pro automobilové dodavatele "3DEXPERIENCE... |
12.6. | Konference ABIA CZ 2025: setkání zákazníků a partnerů... |
29.9. | The Massive IoT Conference |