16.2.2003Osnova přednášek: Výběr IS/IT

Část: Řízení projektů vývoje IS

Zpracoval: RNDr. Dušan KajzarUrčeno: studentům informatiky FPF SU v Opavě,

V. ročník, 2002/2003

Literatura: Rosenau, M.D.: Řízení projektů, Computer press, 2000 Zonková, Z.: Projektové řízení, VŠB-TU Ostrava, Ekonomická fakulta, 1997 Zonková, Z.: Rozhodování managera, VŠB-TU Ostrava, Ekonomická fakulta, 1997 f. Sybase: Project Management, materiály ze školení

1. Úvod - základní pojmy........................................................................................................12. Fáze životního cyklu projektu.............................................................................................53. Organizace řízení projektu vývoje IS, pracovní funkce......................................................84. Rozhodovací analýza..........................................................................................................95. Dekompozice projektových činností.................................................................................116. Síťová analýza...................................................................................................................127. Plánování rozpočtu............................................................................................................168. Řízení rozsahu projektu....................................................................................................169. Dokumentace řízení projektu IS.......................................................................................1810. Dokument "Definice projektu".........................................................................................2011. Dokument "Plán kvality"..................................................................................................2212. Dokument "Plán projektu"................................................................................................2513. Řízení rizik........................................................................................................................2814. Dokončení projektu...........................................................................................................29

1. Úvod - základní pojmy

Návaznost tématu III.r.: Informační systémy

(informace, systém a systémové přístupy, IT a IS, klasifikace IS) IV.r.: Projektování IS

(objektově orientované metody, strukturované metody) další předměty : Databázové systémy, Počítačové sítě, Vývojové trendy IS/IT, .... řízení projektů IS

(srovnání - režisér a producent ... hl. analytik a proj. manažer)

Co je to projekt ? Projekt je výsledek materiální nebo nemateriální povahy, založený na strategickém

plánu, navržený, organizovaný a realizovaný pod řízením někoho (projektového manažera) v zájmu zadavatele.

např. budovy, zařízení, výrobky, organizační akce, výzkumné a vývojové úkoly. množina vzájemně souvisejících činností

-- mají přiděleny zdroje (čas, finance, personál, materiál)

1

-- jsou definované požadavky na projekt (cíl projektu), vstupy a výstupy

Rozdíl mezi projektem a běžnou podnikatelskou rutinou definován začátek a konec neopakovatelnost projektu hodnota projektu .... i více než roční příjem firmy riziko projektu .... značné odklad v projektu .... kritický dopad know-how .... zkušenosti z projektu až po jeho ukončení struktura týmu .... dočasná doba výcviku k projektovému řízení .... měří se počtem projektů

Řízení dosahování výsledků prostřednictvím jiných

Chápání pojmu projektové řízení řízení projektů řízení pomocí projektů

Projektové řízení jako řízení projektů způsob řízení složitých, diskrétních, plánovaných úkolů s vysokou mírou neurčitosti, s

vysokou mírou komplexnosti, který zahrnuje -- řízení tvorby projektů-- řízení realizace projektů-- řízení oživování projektů

Projektové řízení jako řízení pomocí projektů souhrn činností řídícího subjektu, směřující k dosažení plánovaných cílů v plánovaném

čase a nákladech činnosti mají řadu specifik

-- neopakovatelnost cílů a způsobů realizace-- variantnost cest realizace-- značný počet a různorodost účastníků-- radikální změny rozhodování problémů v průběhu projektu-- značný výskyt nejasně definovaných problémů, změn s vysokou mírou nejistot a rizik

Základní rysy projektového řízení projekt má přesně definovaný začátek a konec činnosti se neopakují

-- snížená možnost nápravy omylů proměnlivost účastníků projektu vysoká neurčitost

-- spojená s definováním cílů-- spojená s realizací-- z toho vyplývající riziko

relativně slabá zpětná vazba v průběhu projektu-- v porovnání se zpětnou vazbou na konci projektu

Zdroje

2

čas .... definice začátku a konce projektu finance .... je dán rozpočet lidské zdroje .... role, odpovědnosti, řídící struktura materiál .... technické vybavení, kanceláře, auta, telefony, ....

Vstupy dokumentace současného stavu požadavky na projekt akceptační kritéria

Výstupy produkty odpovídající akceptačním kritériím

"Trojimperativ" projekt je definován trojimperativem

kvalita (rozsah, specifikace provedení)

čas náklady (cena)

Srovnání k motivaci projekt jako cesta letadlem (viz materiály Sybase)

každý let má letový plán a povolení ke startu-- každý let má své vyšší řízení-- odpovědní lidé verifikují letový plán z hlediska správnosti, přesnosti, úplnosti

Projekt IS-- PDD (Project Definition Document) je letový plán projektu-- musí být schválen před "startem"

každý let má cílové letiště-- letadla mají stanoven cíl .... před odletem (!)-- pouze když je známo, kam se má letět, lze stanovit čas přistání

Projekt IS-- doba trvání projektu je určená cílem projektu-- neznáme-li cíl, nelze určit čas, náklady, specifikovat kvalitu

let má klienty, o které je nutno po celou dobu pečovat-- klienti chtějí mnoho věcí (doletět k cíli, levné letenky, bezpečný let, pohodlný let, doletět včas)

Projekt IS-- zákazníci projektů chtějí totéž-- vybrali si nás, protože jsme jejich nejbezpečnější varianta-- jsme nejkompetentnější dodávat kvalitu, včas, v rámci rozpočtu-- bez nepříjemných překvapení

3

každý let vyžaduje nějaké zdroje-- let bude trvat určitou bobu-- spotřebuje se určité množství paliva, jídla apod.

Projekt IS-- zákazníci často chtějí servis na úrovni 1. třídy Concorde za cenu letenky turistickou třídou

každý let musí mít řízená rizika-- silný protivítr může způsobit zpoždění-- turbulence jsou nepříjemné pro cestující, mohou způsobit zranění-- jídlo může být zkažené-- technické problémy letadla

Projekt IS-- projekty IS mají známá i neznámá rizika s různým dopadem na projekt

každý let musí sledovat svůj postup podle letového plánu-- letadla jsou plná měřících přístrojů-- vnější zařízení také sledují postup letu (radary, řízení letového provozu)

Projekt IS-- projekt bez dostatečných nástrojů sledování může být mimo plán a nikdo se to včas

nedoví

každý let používá nějaké prostředky -- letadlo, cisterny s palivem, tahače, ....

Projekt IS-- projekty IS používají metodiky a metody řízení projektů IS-- jde o to, aby se projekt co nejefektivněji dostal z bodu A do bodu B

má pilota a druhého pilota-- palubní inženýr neřídí letadlo-- letuška ani cestující rovněž neřídí letadlo-- letadlo řídí pilot, i ten je někdy postradatelný

Projekt IS-- projekt řídí projektový manažer-- nedělá to administrátor databáze, analytik, programátor ani uživatel

let je většinu času je řízen autopilotem-- dobře naplánované lety vyžadují lidský zásah pouze v kritických fázích letu (start, přistání, špatné počasí, problémy apod.)

Projekt IS-- pomocí správných nástrojů může projekt běžet bez řídících zásahů-- pokud ne .... prověřte své nástroje

Co znamená být pilotem ? komunikovat

-- s posádkou, řídící věží, cestujícími-- být informován a informovat

neprodávat letenky-- úkolem je řídit tento let

4

-- nikoliv prodávat letenky na let příští-- budoucí business si zajistíme tím, že budeme mít spokojené cestující

řídit letadlo-- pilot musí být na plný úvazek-- pilot, který je současně letuškou, cestovní kanceláří apod. .... nedělá ani jedno dobře-- každá práce během letu je důležitá .... nejdůležitější je ovšem práce pilota

řídit z kabiny-- letadlo se řídí z kabiny, ne ze zavazadlového prostoru apod.-- v kabině jsou všechny řídící a měřící přístroje-- jsou-li přístroje dostupné na jednom místě, je jednodušší je sledovat-- možno využít autopilota .... není účelem držet řídící páku po celou dobu letu

"Autopilot" projektu dopravní prostředek .... metodika řízení projektu nástroje řízení .... MS projekt (použití síťové analýzy)

-- vytváření plánu projektu na základě metodiky-- monitoring a reporting postupu projektových prací-- sdílení informací s ostatními-- sledování a řízení požadavků na změny-- hlášení chyb a problémů

pilot .... projektový manažer kabina .... Project Status Report (Zpráva o stavu projektu) Project Status Report .... bude blíže vysvětlen později

Závěrem k této podkapitole víme, co je to projekt projekt musí být řízen (z hlediska kvality, času, nákladů) existují různé pracovní funkce při řízení projektu existují nástroje k řízení projektu

2. Fáze životního cyklu projektu

Základní fáze projektu: definice a zahájení --> realizace --> ukončení

Zahájení projektu: před zahájením

-- již obchodní jednání ovlivňuje budoucí projekt-- pozor na nereálná očekávání-- nutno dobře porozumět požadavkům klienta

jak dojde k zahájení projektu-- formální výběrové řízení (poměrně přesné zadání)-- klient formálně požádá o vypracování návrhu (méně přesné zadání)-- předložení projektu je iniciativou dodavatele

zpracování dokumentu Definice projektu-- základní dokument projektu-- určen: projektovému týmu i klientovi

5

-- součást (příloha) kontraktu-- živý dokument - použití k průběžnému řízení po celou dobu běhu projektu

Realizace projektu porady projektového týmu porady kontrolních komisí vydávání zpráv o stavu projektu sledování a evidence požadavků na změny hodnocení kvality řízení rizik

Ukončení projektu předávací protokoly předání výstupů akceptační protokoly závěrečné porady

-- s klientem-- s projektovým týmem

uzavření rozpočtu-- přehled o čase, nákladech, pracnosti

Podrobnější členění fází fáze iniciace fáze koncepce fáze návrhu fáze prováděcí (realizace) fáze kompletace fáze likvidace

Fáze iniciace představuje zrod projektu formulovány základní cíle projektu představy o možných cestách k dosažení cílů

-- náměty řešení, které budou dále rozpracovány ve varianty koncepce rozhodujícím subjektem je zadavatel

-- definuje cíle a jejich kvantitativní a kvalitativní charakteristiky-- parametry kvality-- požadovaný čas řešení-- odhad nákladů

úkoly projektového řízení-- efektivní formulace problému-- uspořádání námětů řešení-- odhad finanční, časové a technické proveditelnosti-- pomáhat při přípravě finančního zajištění projektu-- definovat autoritu a odpovědnost v projektu (ujasnění kompetencí)-- definovat systém vztahů zadavatel-řešitel-- linky komunikace-- ujasnění odsouhlasovacích procedur-- vytvoření účinného systému kontroly

6

Fáze koncepce studie proveditelnosti jednotlivých variant řešení důležitá - variantnost řešení stanovení prahů nevratnosti systémovost řešení - interakce mezi projektem a jednotlivými řešenými subsystémy časový harmonogram jednotlivých variant (síťový graf) odhad potřebných zdrojů a nákladů pro jednotlivé varianty rizika jednotlivých variant řešení stanovení kriterií pro hodnocení variant výběr nejlepší varianty zdůvodnění výběru a prezentace managementu podniku

Fáze návrhu rozpracování řešení do podrobnosti nezbytné pro vlastní realizaci projektu dekompozice projektových činností návaznost činností - síťový graf termínová listina potřeby zdrojů analýza nákladů optimalizace sporu mezi kvalitou, časem, náklady stanovení milníků - důležitých bodů v plánu projektu stanovení pravidel akceptace dílčích řešení zadavatel - rozhodnutí, kteří dodavatelé budou spolupracovat uzavírání smluv s dodavateli upřesnění organizace projektového řízení požadavky na součinnost se zákazníkem vybudování informačního systému pro účely projektového řízení

-- sledování rozsahu řešení, kvality, času, potřeby zdrojů, nákladů řízení rizik možné chyby

-- nevyjasněná koncepce z předchozí fáze-- malá variantnost koncepce projektu-- nevhodná organizační struktura projektového řízení

Fáze prováděcí (realizace) dominantní úloha projektového řízení sledování síťového grafu sledování kvality, času, nákladů sledování hlediska bezpečnosti identifikace a eliminace rizik dokumentace průběhu projektového řízení

Fáze kompletace systémové zavedení výsledku projektového řízení do života dominantní role - zadavatel, uživatel výsledku vyhodnocení úspěšnosti projektu kontrola dokumentací a manuálů dohlížení v době zkušebního provozu kontrola plateb

Fáze likvidace

7

systémové ukončení spolupráce projektového týmu archivace dokumentů zhodnocení práce lidí projektového týmu (odměny) převedení lidí na řešení jiných úkolů

3. Organizace řízení projektu vývoje IS, pracovní funkce

Hierarchie projektu skupina lidí zahrnutých do projektu, vztahy mezi nimi

Ředitel projektu osoba s pravomocí projekt založit je "vlastníkem" projektu řízení projektu na strategické úrovni

Projektový manažer osoba odpovědná za projekt na taktické a operativní úrovni

Vedoucí projektu (vedoucí řešitel) osoba vedoucí subprojekt

Projektový tým osoby vybrané pro provádění prací na projektu pod vedením ved. projektu resp. proj. manažera jádrový tým

Podpůrné týmy specialisté řešící dílčí podúkoly pod vedením svých liniových vedoucích

Gestor projektu (sponzor) člověk zplnomocněný organizací zákazníka k přijímání výstupů projektu mluvčí zákazníka reprezentuje zájmy všech skupin uživatelů (zákazníka) je primárním kontaktem projektového manažera pro řešení problémů nemůže-li (nebo nechce) gestor rozhodnout, je problém eskalován k CCB

Change Control Board (CCB) Komise pro řízení změn malá komise zplnomocněná k rozhodování o projektu složení např.

-- projektový manažer-- gestor projektu-- zástupci uživatelů-- vedoucí řešitelé

nemůže-li (nebo nechce) CCB rozhodnout, je problém eskalován k ESC

Executive Steering Committee (ESC) Řídící komise projektu

8

nejvyšší instance projektu top management zákazníka (ředitel projektu) top management dodavatelů rozhoduje o věcech, které přísluší top managementu

4. Rozhodovací analýza

Rozhodovací analýza technika řešení problému rozhodování

Problém rozhodování problém s variantní možností řešení

Rozhodovací proces logický sled funkčně vymezených a časově oddělených fází, které probíhají při řešení

problému

Struktura rozhodovacího procesu identifikace

-- 1) vymezení problému, stanovení cíle-- 2) analýza faktorů rozhodování, určení kriterií a pravidel-- 3) rozpoznání a tvorba variant

komputace-- 4) prognóza důsledků volby variant, experimentování s variantami-- 5) hodnocení variant-- 6) přijetí rozhodnutí, volba nejvhodnější varianty

interpretace-- 7) formulace rozhodnutí, prostředky realizace a kontroly

Poznámka možné cyklické návraty do předchozích fází

Rozhodovací analýza heuristická metoda vhodná pro řešení složitých rozhodovacích procesů univerzální metoda lze ji použít všude tam, kde je nutno učinit kvalifikované rozhodnutí její fáze se blíží struktuře rozhodovacího procesu

1) Vymezení problému, stanovení cílů

základní krok rozhodovací analýzy cíl nutno vymezit co nejpřesněji

-- někdy je to možné jen rámcově písemně vymezit rozsah

-- co je a co již není cílem řešení

2) Rozbor informací a podkladů

9

dokonalé poznání problému příprava podkladů pro rozhodování soustředit a utřídit informace informace pro

-- pro stanovení variant řešení-- pro stanovení kriterií hodnocení variant-- pro určení rizik jednotlivých variant

3) Stanovení variant řešení

variantní řešení zvyšuje pravděpodobnost nalezení kvalitního rozhodnutí varianty se stanovují metodou odborného posouzení nutno vyhnout se pokušení předem preferovat jednu variantu

4) Stanovení kriterií pro výběr variant

stanovení kriterií je úzce spjato s vymezenými cíli při podrobném vymezení cílů můžeme kriteria ztotožnit s těmito dílčími cíli kritéria absolutní (nezbytná), relativní (žádoucí) množství kriterií - únosný, ale výstižný počet měřitelnost naplnění kriterií - stupnice

-- číselné škály-- poměrná čísla-- hodnotové parametry

např. 0 .... nevyhovuje2 .... vyhovuje málo4 .... vyhovuje6 .... plně vyhovuje

vážená kriteria-- váha určuje význam kriteria-- použijeme číselnou stupnici

5) Hodnocení a srovnávání variant

srovnávání variant řešení-- na základě rozborů řešitelnosti jednotlivých variant provedeme jejich srovnání dle stanovených kriterií a doporučíme konečnou variantu řešení.

Rozhodovací maticekritérium váha var. V1

součinvar. V2

součinvar. V3

součinK1 3 2 6 5 15 1 3K2 1 5 5 5 5 5 5K3 4 3 12 1 4 3 12K4 5 1 5 3 15 5 25K5 3 5 15 2 6 3 9

užitnost 43 45 54

10

6) Zjištění nepříznivých důsledků variant řešení (odhad rizik)

neposuzujeme jen přednosti varianty, uvědomujeme si i její nedostatky některá rizika uvažujeme již při hodnocení užitnosti variant podle kriterií zde jde o vytypování dalších rizikových faktorů, slabin řešení

-- stanovení pravděpodobnosti výskytu nepříznivých jevů-- stanovení závažnosti důsledků těchto jevů

sestavíme rozhodovací matici pro hodnocení rizik-- varianty-- rizika-- váhy rizik (odborným odhadem)

stanovení celkového stupně ohrožení každé varianty

7) Volba nejvhodnější varianty

varianta, která nejlépe a s nejmenším rizikem splňuje daný cíl nejpříznivější poměr užitnost / riziko racionální rozhodovací strategie

-- volba varianty s největší převahou užitku nad rizikem riziko varianty

-- malé-- značné, ale při vhodných opatřeních zvládnutelné (únosné)-- neúnosné

návrh rozhodnutí zdůvodnění rozhodnutí

5. Dekompozice projektových činností

Úkoly řešené projektovým řízením rozsáhlé - zřídka řešitelné vcelku nezbytné - provést dekompozici původního úkolu na dílčí podúkoly hovoříme o problémově orientované dekompozici

Cíl dekompozice projektových činností rozčlenění projektu na plánovatelné a kontrolovatelné balíky práce

Postup dekompozice rozdělení projektu (problému) na dílčí problémy vznikne hierarchická struktura dílčích problémů atd. až na jednotlivé balíky práce popis jednotlivých prací

Výsledek problémově orientované dekompozice seznam balíků práce

Přístup k dekompozici objektový

-- podle hmatatelných aspektů výsledku projektu

11

funkční-- podle funkcí, které má výsledek plnit

oba přístupy musí vést k témuž výsledku (stroj, stavba, IS) uplatnění obou současně - úplnost a vyváženost balíků práce

Ke každému balíku práce určení pracovních funkcí nutných pro tyto práce odpovědnost výběr konkrétních osob určení

-- času řešení (termín od-do)-- potřeby zdrojů (kdy, kolik, kde)-- odhad nákladů

6. Síťová analýza

Síťová analýza jedna z metod operačního výzkumu použití v situacích, kdy se snažíme činnosti uspořádat, organizovat oblasti použití

-- investiční akce-- organizační akce-- opravy velkých zařízení apod.

graficky znázorňuje návaznost činností přehled o rozsahu projektu, podmíněnost činností, .... umožňuje určit tzv. kritické činnosti (kritická cesta) dnes je základem projektového řízení umožňuje hledat kompromis mezi časem, kvalitou a náklady nelze použít v případech

-- nevyjasněná koncepce-- změny v koncepci-- nedostatečné informace o projektu-- nedodržování termínů dílčích činností (subdodávek)

Základní metody založené na síťové analýze CPM (Critical Path Method) PERT (zdokonalení CPM, stochastický model, rozhodování za rizika) LESS, PERTCOST (zaměřené na minimalizaci nákladů)

Postup aplikace vytvoření souboru činností sestavení síťového grafu časová analýza projektu určení časových rezerv analýza kritické cesty posouzení realizovatelnosti (z hlediska času, poté další zdroje) případné úpravy a opět analýza krit. cesty, .... analýza zdrojů

12

1) Vytvoření souboru činností

viz dekompozice projektových činností zadávací tabulkaOzn. činnosti Název činnosti Následné činnosti Doba trvání

A ..... D, E 2 dnyB ..... H, I, J 5 dní

..... atd.

doba trvání - odhad časuti,j = (2aij + 3bij) / 5 .... aij - pesimistický odhad (vliv rizik)

.... bij - optimistický odhad

ti,j = (aij + 4mi,j + bij) / 6 .... mij - nejpravděpodobnější odhad

2) Vytvoření síťového grafu

činnosti v uzlech činnosti na hranách příklad (zde pouze ilustrační, v rámci možností MS Word)

U4 U6O O C1.2 C1.3

U5 C4.1 C1.1 C3.1 O

A1 A2 O O O O U8U1 U2 U3 C2.1 C2.2

C2.3A3

O O U9 (M2)U7 C3.2 C4.2(M1) C3.3

O O U10 C4.3 U11

(M3)

3) Časová analýza

u každé činnosti určit, kdy může začít a kdy skončit termíny

-- nejdříve možného začátku činnosti-- nejdříve možného ukončení činnosti-- nejpozději přípustného začátku činnosti-- nejpozději přípustného ukončení činnosti

termíny u jednotlivých uzlů-- nejdříve možná aktivace uzlu (u koncového uzlu = nejdříve možný konec projektu)-- nejpozději přípustná aktivace uzlu

13

4) Určení časových rezerv

kritická rezerva uzlu .... Ri = Tiu - ti

u

rezerva celková (j-tý uzel)-- Tj - tj

rezerva volná (j-tý uzel)-- tj

u - tj

rezerva nezávislá (j-tý uzel)-- max (0, tj

u - Tiu - tij)

nečerpat rezervu celkovou-- nejdříve volnou .... neohrozíme termíny nejdříve možné aktivace uzlů-- nezávislou

5) Analýza kritické cesty

kritická cesta-- uzly, pro něž Ri = 0-- činnosti, pro něž Ti = ti

posouzení, kolik % tvoří podíl kritických činností-- nad 30% .... projekt pravděp. nerealizovatelný

snažíme se o snížení podílu kritických činností-- pokrytí kritických činností z vlastních (resp. cizích) zdrojů

6) Analýza zdrojů optimalizace doby trvání projektu při omezených zdrojích Ganntův lineární diagram

-- úsečkový diagram činností-- průběh činností v čase-- jde o jiný úhel pohledu na projektové činnosti

histogram spotřeby zdrojů-- podklad pro plán rozpočtu, termínů plateb

Ganntův lineární diagram (uvažujme počty lidí)

dny/úkol

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

A 2-- ---B 3-- --- --- r rC 2-- --- --- --- --- --- rD 4-- --- --- --- ---E 2-- --- r rF 3-- --- --- --- r r r rG 2-- --- ---H 2-- --- --- r r r r rI 3-- --- --- --- r r r r r rJ 2-- --- --- --- --- --- --- r r r

14

K 4-- --- --- --- --- --- --- ---L 2-- r r r r r r

r .... rezerva volná

Histogram spotřeby zdrojů

počtylidíden: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.1413121110 * * * * * * * * * * * * * * * * * *987654321

0 (*) ....... máme limit 10 lidí

Např.: 3. den musíme 2 lidi ušetřit --> posunout činnosti ? Mají rezervy ? Lze činnosti přerušit ?

Softwarová podpora síťové analýzy MS Project .... viz literatura k tomuto SW

7. Plánování rozpočtu

Složení nákladů: mzdové náklady lidí vlastního oddělení mzdové náklady lidí jiných oddělení organizace režijní náklady (všeobecná a správní režie) nákupy materiálu subdodávky jiných dodavatelů cestovné náklady na výpočetní techniku

Plánování rozpočtu náklady se plánují do takové podrobnosti, v jaké budeme získávat výkazy jejich

čerpání opět nutno počítat s jistou nepřesností

15

nejprve nutno naplánovat činnosti, materiál, ..., pak teprve náklady náklady projektu = součet nákladů jednotlivých úkolů odhady nákladů - metody obdobné jako u plánování času

8. Řízení rozsahu projektu

Kdo všechno je klient ? paní v kanceláři - používá náš produkt IT oddělení zákazníka - řídí zavádění a provoz IS/IT v podniku finanční ředitel - proplácí naše faktury odbory - nechtějí propouštět nadbytečné zaměstnance generální ředitel - podepisuje smlouvy

Kdo je hlavní osoba - gestor projektu u zákazníka kdo řekne finančnímu řediteli, aby proplatil faktury kdo řekne vedení, že projekt splňuje požadavky a je ukončen kdo se bude starat, aby se nezvětšoval rozsah projektu bez odpovídajících úprav

rozpočtu kdo bude sdílet náš pocit naléhavosti, aby byl projekt dokončen včas kdo bude eskalovat problémy, aby bylo dosaženo úspěchu ten je pro nás hlavní osobou zákazníka - gestor projektu

Gestor (sponzor) projektu je mluvčím zákazníka, reprezentuje zájmy všech skupin je primárním kontaktem projektového manažera pro řešení problémů je zplnomocněn organizací zákazníka k přejímání výstupů projektu

Komise pro řízení změn (Change Control Board - CCB) zplnomocněná k rozhodování o projektu tato komise je nepostradatelná pro úspěšnost projektu

Řídící komise projektu (Executive Steering Commitee - ESC) nejvyšší instance projektu složená z managementu zákazníka a dodavatele

Nutno pochopit problémy zákazníka právní oddělení chce perfektní smlouvu finanční ředitel chce nízkou cenu IT manager požaduje soulad s IT strategií uživatel chce rychle funkční systém dodavatel HW chce prodat co nejnovější techniku všichni mají svoji pravdu

Nutno vytvořit tým neexistuje my a oni nutno sdílet radosti i starosti zákazníka, jeho úspěch a vizi informovat a komunikovat v celém týmu - budovat důvěru zaměřit se na vizi zákazníka - strategii vývoje IS/IT v souladu s globální strategií firmy

16

Nutno stanovit pravidla jednání nelze uspokojit protichůdná očekávání nutno dojít k dohodě identifikovat jednotlivá očekávání přeformulovat je do měřitelných požadavků identifikovat a kvantifikovat omezení nechat tým (řídící komisi projektu, komisi pro řízení změn) aby pravidla odsouhlasil

(explicitní písemný souhlas všech stran) zaznamenávat si všechna pravidla, zahrnout je do dokumentace projektu (Definice

projektu, Plánu kvality) při nejasnostech - okamžitě eskalovat situaci, na nic nečekat

(prevence proti selhání projektu)

Požadavky na změnu používat formální změnové řízení, tj.

-- požadavky na změnu evidovat-- musí být jasné, kdo požadavek vydal a kdo o něm rozhodl-- rozhodnutí musí být zdůvodněno-- pro změnové řízení musí existovat formální zápis

Doporučení vytvořit jednotnou projektovou kulturu oslovit potřeby všech pracovat pro úspěch gestora projektu neshody řešit konsensem eskalovat problémy včas udržovat profesionální prostředí poměřování požadavků - kolik za kolik (nikoliv ano-ne) komunikovat a budovat si důvěru

9. Dokumentace řízení projektu IS

Obecná pravidla pro řízení projektu vývoje IS zaměřit se na cíle projektu (vize) zplnomocnit tým a mít schopnou a kompetentní komisi pro řízení změn používat správně SW nástroje pro řízení projektu řídit projekt, ne procesy každý si musí denně evidovat svůj postup a zasílat zprávy v určených termínech a

formátech trvat na explicitních písemných schváleních řídit náklady + čas + rozsah (všechny tři) komunikovat - stále se všemi vysvětlovat, školit revidovat plány, přeplánovávat vést o všem záznamy (porady, telefony, e-maily,...)

"Pilotní kabina" projektu

17

Požadavky na změny(Change Requests)

Plán kvality(QP)

Položky k provedení(Action Items)

Ověřování kvality(Quality Assurance)

Rozpočet projektu(Čerpání rozpočtu)

Nezávislé posouzení kvality (PQ Review)

Plán plnění požadavků(RTM)

Definice projektu(PDD)

Plán projektu

jednotlivé dokumenty tvoří podklad pro "Zprávu o stavu projektu" (Project Status Report)

jde o důležité nástroje pro sledování cíle a průběhu projektu IS i nejlépe naplánované projekty selhávají, selhává-li jejich řízení

Jednotlivé dokumenty Definice projektu Plán kvality Plán projektu

Ověřování kvality (Quality Assurance)-- stanovený systém prověřování a přebírání dílčích výsledků práce-- inspekce kódu-- skupinové zhodnocení-- formální zhodnocení-- oponentura řešení

Nezávislé posouzení kvality (Project Quality Review)-- externí posouzení úspěšnosti projektu-- pohled zvenku

Požadavky na změny (Change Requests)-- podané přes komisi pro řízení změn

Položky k provedení (Action Items)-- poznámky o možných doplněních projektu

Plán plnění požadavků (RTM - Requirements Tracebility Matrix)-- mapa požadavků (činností), plán jejich návazností a termínů plnění

Zpráva o stavu projektu tzv. Project Status Report poskytuje "tvrdá" data (měřitelná) z různých zdrojů nástroj ke sledování průběhu projektu

K čemu slouží Zpráva o stavu projektu ? pro měření postupu projektu

-- kde jsme, jdeme správnou cestou ? monitoring "zdraví" projektu

-- problémy kvality, spokojenost zákazníka-- informace pro ostatní o projektu (pro projektový tým, sponzora projektu, komisi pro řízení změn, řídící komisi projektu)

18

získávání souhlasu na všech stranách-- projektový manažer, sponzor projektu, projektový tým, komise

pro vytváření historických záznamů-- zachycení vývoje projektu-- poučení pro příště-- porozumění projektu-- sdílení informací

Části Zprávy o stavu projektu shrnutí pro management

-- sumarizuje kapitolu "Detaily"-- vždy psáno projektovým manažerem

detaily-- získávány z jednotlivých reportů členů týmu

Shrnutí pro management shrnutí stavu čerpání rozpočtu postup proti milníkům plánu projektu problémy a rizika, navrhovaná opatření, požadavky na změny

Detaily provedené plánované činnosti

-- zdroj .... Plán projektu neplánované činnosti

-- zdroj .... Plán projektu, Položky k provedení plánované neprovedené činnosti

-- zdroj .... Plán projektu, Ověřování kvality plánované činnosti do dalšího Status Reportu

-- zdroj .... Plán projektu, Požadavky na změny požadavky na změny

-- zdroj .... Plán projektu, Požadavky na změny, Položky k provedení, Nezávislé posouzení kvality

stav rozpočtu, pracnost-- zdroj .... Plán projektu, Čerpání rozpočtu

sledování milníků-- zdroj .... Plán projektu, Ověřování kvality

10. Dokument "Definice projektu"

Dokument "Definice projektu"

Project Definition Document (PDD) je "strategií" projektu - odpovídá na otázky typu "co" specifikuje:

-- požadavky a cíle projektu-- hlavní výstupy-- náklady-- plán projektu-- organizační strukturu týmu

19

-- metody řízení projektu a kvality-- akceptační kritéria

je to živý dokument (!)

komu je určen ?-- pro management dodavatele

... slouží k pochopení požadavků klienta a ujasnění potřebných zdrojů pro realizaci projektu

-- management zákazníka... slouží k vybudování důvěry managementu klienta ve schopnosti dodavatele řídit projekt... pomáhá vytvořit pracovní prostředí ještě před zahájením projektu

kdo dokument vypracuje ?-- napsán společně dodavatelem a zákazníkem

kapitoly dokumentu1. Úvod2. Východiska a současný stav3. Rozsah projektu4. Organizace projektu5. Řízení projektu a řízení změn6. Plán projektu7. Akceptační kritéria8. Požadavky na součinnost

kapitola 1. Úvod-- vysvětluje samotný dokument, nikoliv projekt-- účel dokumentu, jakou roli hraje v projektu-- rozsah - co je a co není obsahem dokumentu-- rozdělovník - komu je dokument distribuován (zákazník, dodavatel, případně další)-- odkazy - z čeho dokument vychází (dokumenty výběrového řízení, zápisy z porady,...)

kapitola 2. Východiska a současný stav-- stručné shrnutí informací o důvodech realizace projektu, souvislostech, historii, požadavcích, omezeních,...

kapitola 3. Rozsah projektu-- jde o definici hranic projektu-- požadavky - specifikace cílového stavu,

co se má změnit proti stavu popsanému v kap. 2-- hlavní výstupy

.... seznam jasně definovaných výstupů, které slouží ke splnění výše uvedených požadavků (dokumenty, kód, plány testů,...)

kapitola 4. Organizace projektu-- tato kapitola se může odkazovat na plán kvality-- personální složení

.... seznam všech účastníků projektu (funkce, telef. čísla, e-mail,...)

20

-- role v projektu.... identifikace rolí v projektu (manažer projektu, ...., komise pro řízení změn, sponzor projektu,...)

-- řídící a komunikační struktura.... definuje kdo, kdy, jak a komu co reportuje

-- místo práce .... kde se bude na projektu pracovat (pro odhad cestovních nákladů)

kapitola 5. Řízení projektu a řízení změn-- popisuje, jak bude projekt řízen a jak budou zpracovávány požadavky na změnu-- může se odkazovat na plán kvality-- řídící komise (Executive Steering Commitee)

.... kontrolně konzultační komise (dohledová a schvalovací funkce)-- komise (prac. skupina) pro řízení změn (Change Control Board)

.... zpracovává denní problémy, požadavky na změny-- změnové řízení

.... popis procesu, šablona požadavků na změnu (úpravu)-- řízení kvality

.... jak bude řízena kvalita výstupů-- konfigurační řízení

.... popis procesu

kapitola 6. Plán projektu-- zahrnuje rozklad činností (work breakdown structure) -- hierarchická dekompozice na dílčí činnosti-- přiřazení personálu a identifikované výstupy činností-- hlavní milníky projektu-- detailnější plán je vhodné udržovat jako samostatný materiál (z důvodu pravděpodobných častějších změn)

kapitola 7. Akceptační kritéria-- definuje procesy, kterými bude projekt ukončen-- cílem je definovat, jak se zjistí, že jsme s projektem hotovi-- dokumenty se ukončují jejich zhodnocením, software testováním, ...-- odpovědi na otázky akceptačních kritérií musí být jednoduché (pokud možno ano-ne, číselná hodnota, ...)

kapitola 8. Požadavky na součinnost-- externí součinnost s klientem-- musí být schváleny klientem-- jak reagovat, nebudou-li včas splněny-- jsou zdrojem rizika

možné přílohy dokumentu-- dokumentace řízení kvality-- rozpis pracnosti jednotlivých činností-- formulář požadavků na změny-- šablona pro zprávu o stavu projektu (Project Status Report)-- apod.

21

shrnutí-- první draft dokumentu vytvořit před zahájením nabídky-- dokument musí být autorizován klientem-- může být součástí smluvního vztahu-- jde o živý dokument, řízený řídící komisí projektu a komisí pro řízení změn-- tento dokument je srdcem projektu, -- pokud projekt umírá - podívejte se na dokument Def. projektu

11. Dokument "Plán kvality"

Dokument "Plán kvality"

Quality Plan (QP) je "taktikou" projektu - odpovídá na otázky typu "jak"

definuje -- pravidla realizace konkrétního projektu-- normy chování a pracovní postupy-- standardy, předpisy-- jak bude projekt řízen, sledován (monitorován), modifikován,...

komu je určen ?-- projektovému týmu

kapitola 1. Úvod-- účel dokumentu, rozsah, rozdělovník-- odkazy na jiné dokumenty, ze kterých vychází (dokument Def. projektu)

kapitola 2. Organizace kvality projektu-- definuje organizační strukturu projektu počínaje výkonnými rolemi až po vrcholné orgány (komise pro řízení změn, řídící komise projektu)-- definice jednotlivých rolí-- popis odpovědností (kdo má schvalovací pravomoc za stranu klienta)

kapitola 3. Plánování a řízení projektu-- definuje procesy v projektu-- popis používání a udržování plánu projektu-- jak se bude provádět reportování stavu projektu (jak často, komu, v jakém formátu)-- četnost schůzek řídící komise projektu a komise pro řízení změn-- definice eskalačních procedur pro řešení problémů v projektu

kapitola 4. Standardy-- popisuje normy chování-- definice standardů pro dokumentace

.... které dokumentace, v jaké struktuře (rozsahu) - Def. projektu, Plán kvality, Zpráva o stavu projektu, řízení změn

-- normy pro programování .... názvové konvence

22

.... použité nástroje (CASE)

.... standardy uživatelského rozhraní

.... je vhodné odkazovat se na samostatné, předem vypracované dokumenty (!)

kapitola 5. Konfigurační řízení-- řízení distribucí verzí dokumentací a programových modulů-- je nutné vést tak, aby chybné moduly a verze nemohly být omylem znovu použity-- musí umožňovat rollback k předchozí verzi

kapitola 6. Řízení kvality-- aktivní proces zajišťující, že všechny výstupy odpovídají odsouhlaseným požadavkům a standardům-- vysvětluje, jak bude každý z výstupů verifikován

.... testy software, odsouhlasení dokumentací-- specifikuje, jak nakládat se zjištěnými defekty-- popis způsobů sledování a identifikace defektů až po jejich korekci-- popis verifikačních procesů

.... inspekce kódů, vzorkování

.... prototypování

.... formální přezkoumání-- specifikace, které výstupy budou verifikovány formálním přezkoumáním

.... tj. vyžaduje se explicitní schválení (Definice požadavků, Design, Test Report)

-- které výstupy budou verifikovány inspekcí, vzorkováním, prototypováním .... např. programový modul, datový model, GUI

-- které výstupy budou verifikovány skupinovým přezkoumáním (Design)

-- Quality Control Matrix - matice řízení kvality (nechat si ji schválit)

Typ Název Metoda verifikace

Úroveň schválení

dokument logický design

formální zhodnocení

sponzor projektu

dokument fyzický design

formální zhodnocení

IT manager

kód uložené procedury

inspekce tým řešitelů

.... apod.

kapitola 7. Hodnocení kvality projektu (Project Quality Review)-- jde o hodnocení projektu, nikoliv výstupů-- definice plánu PQR (např. jednou za 1/4 roku)-- lze provádět externími organizacemi

kapitola 8. Integrita informací-- zahrnuje plán backupů projektových dat (kartotéky projektu - kódy, dokumenty)-- minimalizuje ztrátu práce na projektu v důsledku zcizení dat, chyb hardware a

23

software, katastrof (oheň, voda)

kapitola 9. Řízení klientem dodaného výrobku-- postupy, jak pracovat s klientem dodanými částmi (části software, hardware)

kapitola 10. Nakupování-- postupy pro nakupování částí projektu od třetích stran (hardware, části software)-- ověření způsobilosti takových částí

kapitola 11. Testování-- definuje způsoby testování (neobsahuje vlastní testy)-- jak a jak dlouho uchovávat záznamy o testování-- může obsahovat části

strategie testováníplány testůpopis hardware pro testynástroje pro testováníhodnocení testovacího softwarepopis testování jednotlivých modulůpopis integračních testůpopis systémových testůpopis funkčních testůtestování výkonuakceptační testy

-- plán testů .... rozdělit testy do různých úrovnítesty modulů (programových jednotek)integrační testy (spolupráce modulů)systémové testyfunkční testyvýkonové a zátěžové testy

-- jasně definovat, jak proběhne přejímací testování-- definovat procesy hlášení chyb

věnovat pozornost - testovacím postupům (testovacím procedurám)-- obsahují detailní popis, jak se bude testovat software-- musí obsahovat minimálně

popis testůposloupnost testovacích krokůdatové vstupyočekávané výsledkyodkazy na požadavky, které jsou tímto splněny

-- výsledky testovacích procedur se zaznamenávají-- nutno testovat i testovací software

věnovat pozornost - testovacím datům-- dostupnost správných testovacích dat - klíčový faktor úspěšného testování (neponechávat vytvoření testovacích dat náhodě)-- zahrnout vytvoření a certifikaci testovacích dat do plánu projektu

(součást kritické cesty)

24

-- certifikace testovacích dat na přesnost a úplnost(provede uživatel)

-- pečovat o testovací data konfiguračním řízením(schopnost obnovit data po každém testu)

-- požadavky na změnu projektu - mají vliv i na testovací data

věnovat pozornost - testovacímu prostředí-- musí umožňovat prokázání správnosti a efektivity systému-- musí se co nejvíce podobat provoznímu prostředí

(rozdíly jsou rizikem)-- nutno testovat i testovací software a další nástroje-- zdokumentovat testovací prostředí

(výrobce, modely, verze - hardware, software, sítě)

věnovat pozornost - zprávě o testování (test report)-- obsahuje záznamy o testování-- je hmatatelným důkazem, že obchodní požadavky byly úspěšně implementovány

.... odkaz na testovací proceduru

.... datum testování

.... verze testovaného software

.... jméno testera, podpis

.... seznam chyb hlášených během testování

12. Dokument "Plán projektu"

Plánování projektu

proč a jak plánovat ? .... zvážení 3 faktorů:-- kde jsme nyní ?-- kam se chceme dostat ? (nutno stanovit cíl)-- jakým způsobem se tam dostaneme ?

stanovení plánu-- plány jsou simulací toho, jak se věci v budoucnu budou odehrávat-- požadavky na zdroje (lidé, finance, materiál)-- termíny, milníky, kontrolní body (kontrolní dny) - hodnocení plnění trojimperativu-- rezerva

vlastnosti efektivního projektového plánu:-- identifikuje vše, co je zapotřebí k úspěšnému dokončení projektu-- obsahuje harmonogram načasování úkolů a souvisejících milníků-- definuje potřebné zdroje se zárukou jejich dostupnosti v době potřeby-- má rozpočet nákladů pro každý úkol-- obsahuje odpovídající rezervu pro nepředvídané události-- je věrohodný pro realizátory i management

nejistoty při plánování

25

-- rizika - seznam rizik a možnosti jejich eliminace-- několik možných alternativ postupu k cíli

(výběr dle délky prací, možnosti paralelismu, náklady)

pravidla-- zapojte osoby, které budou na projektu pracovat, do plánování prací

(práce se může zdát lehká pro toho, kdo ji nemusí dělat,větší pravděpodobnost, že lidé budou plán dodržovat,lepší motivace lidí - naplánují si vlastní práci)

-- plány se dělají pro všechny 3 dimenze trojimperativu-- neustále každého informovat o změnách (projektový tým, strana klienta)-- nevěnovat plánování více času, než byste potřebovali k řešení problémů v důsledku neexistence dostatečného plánu

využití vhodného softwaru pro plánování-- např. MS Project

Dokument "Plán projektu"

živý dokument, mění se s časem-- přeplánování může usnadnit vhodný software

měl by obsahovat i činnosti, které mají nulovou pracnost-- rozhodovací procesy na straně klienta, schvalovací procedury

.... spotřebovávají vymezený čas

.... nelze je ignorovat v časovém harmonogramu nutno respektovat dostupnost zdrojů

-- zdroje nejsou většinou dostupné 100% času-- dostupnost může být snížena:

.... účastí na jiných projektech

.... dovolenou, nemocí

.... sníženou produktivitou neplánované činnosti spotřebovávající čas

-- diskuse, telefonování, zpracování e-mailů-- nutno plánovat i papírování

.... vyplňování dotazníků, reportů, formulářů

.... plánovat činnosti pro řízení kvality-- uvedené činnosti zahrnout do časového plánu a do rozpočtu

odhady času-- metoda Top Down

... projekt rozdělen na části (celý projekt 100%)

.... odhad celkové doby trvání projektu

.... odhady jednotlivých částí

.... časová korekce

-- metoda Bottom Up.... projekt rozdělen na části (celý projekt 100%).... odhady časů na nejnižší úrovni rozkladu.... celkový odhad = součet časů jednotlivých částí.... použití pro zjemnění časového plánu projektu

26

-- analogické metody.... založeny na analogii s jiným projektem.... vycházejí ze skutečných údajů ale nekopírují již realizovaný projekt.... založeny na expertních odhadech zkušených lidí

-- finální odhad.... použitím všech metod.... analogie + rychlý TopDown.... zpřesňování pomocí analogie, BottomUp

časová rezerva-- nutno s ní počítat-- plánovat pracovní den na 6 hodin nebo týden na 4 dny-- použití rezervy

.... pro neplánované činnosti

.... vykrytí rizik

využití časové rezervy - 1. způsob (nevhodný)-- rozloženě na jednotlivé činnosti-- nebezpečí studentského syndromu

.... žádný spěch na začátku

.... odkládání činností na pozdější dobu

.... vždy vede k vyčerpání rezervy

.... kompromisy ve funkčnosti-- nebezpečí multitaskingu

.... práce na více projektech současně pod tlakem více lidí vede k přerušování činností, jejich střídání.... výsledek - vyšší spotřeba času (nutný čas na opětovné soustředění na danou problematiku)

využití časové rezervy - 2. způsob (správný)-- využití časových bufferů-- umístění rezervy na konec projektu a časové posílení činností kritické cesty-- buffery času - časová rezerva-- buffery zdrojů - rezerva zdrojů-- je nepraktické hromadit zdroje a nechat je čekat nevyužité-- buffer zdrojů se realizuje kontrolováním jejich připravenosti zahájit činnost

používání metody síťové analýzy -- metoda kritické cesty CPM

13. Řízení rizik

Riziko projektu stupeň vystavení cílů projektu negativním vlivům a jejich pravděpodobným následkům

z hlediska rozsahu, kvality, času a nákladů

Úspěch projektu

27

dosažení stanovených cílů ve stanovené kvalitě, času, nákladech

Trojimperativ projektu náklady, čas, kvalita

-- co se má udělat-- kdy se to má udělat-- kolik to bude stát

tyto složky musí být v rovnováze

Kvalita definována jako splnění schválených požadavků je stanovena tím, co dodáme, kdy a kolik to bude stát kvalita nesouvisí přímo s "technickou dokonalostí" produktu

Identifikace rizika periodicky přezkoumávat dokument Definice projektu

-- je řízení projektu efektivní ?-- jsou požadavky na součinnost a další předpoklady stále korektní ?-- nedochází k rozmlžení rozsahu projektu ?-- dodržuje se rozdělení rolí a odpovědností ?-- dochází k časté modifikaci dokumentů ?-- každý rozdíl dokumentace se skutečností je rizikem

rizika řešit:-- požadavky na změnu plánu a cílů projektu-- dodatky ke smlouvám-- eskalací ke komisi pro řízení změn

provádět analýzu trendů vývoje projektu provádět analýzu plánu projektu provádět analýzu požadavků na změny provádět analýzu chyb při testování rizika z chyb testování řešit:

-- revizí projektových standardů a postupů-- přeškolením členů týmu-- výběrem nových nástrojů, ...

Typy rizik rizika známá, např.

-- migrace členů projektového týmu-- nekompletní požadavky klienta (nekorektní, protichůdné)-- nevhodná kombinace hardware a software-- havárie hardware

rizika neznámá, např.-- nečekaná legislativní změna-- bankrot subdodavatele -- živelná pohroma

Řešení známých rizik známá rizika, která se spíše očekávají musí být řízena plánem projektu známá rizika, která se spíše neočekávají se řídí tzv. kontingenčním plánem

28

-- tj. plán pro řešení nouzových situací (contingency - eventualita, možnost) příklady řešení v plánu projektu:

-- konfigurace hardware a software dobře nefungujíodstoupit od projektuzměnit rozsah projektunová architektura

-- testovací prostředí není připraveno včaspřerušit práci a čekatzměnit plán testů

-- zredukování rozpočtu projektuzastavit projektzmenšit rozsah

.... nutno plánovat práce na přeplánování (aspoň každý měsíc)

Řešení neznámých (skrytých) rizik plánovat rezervy časové i nákladové vyhradit část rozpočtu (např. 10-20%) pro boj s neznámým

-- pamatovat na to ve smlouvách-- při vyčerpání rezerv - nutno řešit "trojimperativ"

např. Gen. ředitel rozhodne o strategické změně SUN/Solaris na Intel/Unix platformu 3 měsíce před instalací

-- tj. nákup nového zařízení, přeškolení týmu, ....

14. Dokončení projektu

Cíl aby zákazník výsledek projektu přijal tj. byly splněny podmínky trojimperativu projekt splňuje jasně definovaná akceptační kritéria (schválená zákazníkem)

Akceptační kritéria akceptační kritéria musí být objektivní a měřitelná formulace, které se na počátku zdají jasné a jednoznačné mohou být v době dokončování projektu zpochybněné

Fáze akceptace v podstatě začíná už od počáteční smlouvy kontrolní dny a schůzky definovaných komisí podmínky akceptace stanovit ve smlouvě, včetně platebních podmínek

Předání dokumentace příručky pro instalaci a parametrizaci systému příručky pro uživatele

-- harmonogram zpracování (technologický postup)-- popisy jednotlivých činností v technologickém postupu-- popisy vstupů -- popisy evidovaných údajů, číselníků, kmenových dat-- popisy výstupů (sestavy, soubory)

29

příručky pro systémovou podporu-- seznam chybových hlášení a popis reakcí na ně-- řešení nestandardních a havarijních situací pro systémovou údržbu

Implementace projektu zaškolení uživatelů zkušební provoz duplicitní provoz vyhodnocení

Důsledky ukončení projektu každý nemusí mít na ukončení projektu stejný zájem (to si musí manager uvědomit) zákazník může mít snahu o doplňování dalších podmínek

-- např. si uvědomí, že schválil neúplná akceptační kritéria ujasnit osud zaměstnanců pracujících na projektu důsledky překročení času nebo rozpočtu

Pokračující servis a podpora hot-line služba

-- možnost, jak získat názor zákazníka na naši práci může se rozvinout v další obchodní příležitost v budoucnu budování dobrého jména

Vyhodnocení prací nad projektem zpráva vyššímu vedení shrnutí zkušeností pro příště zhodnocení a odměnění pracovníků týmu

30