Řízení ICT projektů jan.matula@autocont.cz Dobrý den • Jan Matula, PhD. • konzultant, analytik a lektor AUTOCONT a.s. • pedagog - Masarykova univerzita • MCP MS Project Specialist • G Suite, Microsoft Office, Adobe Trainer • EA, ITSM, BA, PM Obsah kurzu • ICT a Business a specifika ICT projektů • Základní koncepty projektového řízení • Role a odpovědnosti na projektu • Cíle projektu • Business Case a Charta projektu • Identifikace zainteresovaných stran • Životní cyklus projektu, vodopád, iterativní a agilní přístup • Sběr požadavků • Design Software a Hardware • Servisní smlouva • Rozpad prací projektů (WBS) Obsah kurzu • Harmonogram • Rozpočet • Složení týmu • Identifikace a řízení rizik • Kick off (zahájení projektu) • Monitoring a kontrola • Komunikace • Reportování stavu projektu • Rozvoj týmu a motivace • Řízení změn • Testování, příprava uvolnění do provozu • Předání ICT do provozu • Akceptace Poučení z projektu - Lessons Learned 10 projektových pravidel 1) Jeden zodpovědný a kvalifikovaný manažer projektu. 2) Jasně definovaný zadavatel a dobrá spolupráce s ním. 3) Přesně formulované cíle a očekávání od projektu. 4) Přesně definované zadání produktu. 5) Dostatečně podrobný a realistický plán a jeho dodržování. 6) Nastavení a důslední využívání kontrolních mechanismů. 7) Dokumentace projektu při nastavení a během realizace. 8) Řízení rizik, jejich předvídání a předcházení jejich dopadům. 9) Dobře fungující komunikace v celé organizační struktuře. 10) Znalost know- how projektového řízení u klíčových lidí. Co je to projekt? • Projekt = dokument (anglicky „Documentation“); pokud někdo přinese dokumentaci stavby, může říci „…tady nesu ten projekt…“; myslí tím stoh papíru. • Projekt = návrh (anglicky „Design“); pokud je stavěn dům, je k tomu potřeba projekt; tím se myslí popis toho, jak bude dům vypadat a jak se bude stavět. • Projekt = (anglicky „Project“); pokud se bude stavět dům, je to natolik jedinečná, složitá a riziková činnost, že je nutné ji řídit jako proces a tak vznikne projekt. Vlastnosti projektů IS/ICT • Unikátnost • Přesné určení cílů a výstupů projektu • Dané termíny (realizace projektu ve stanoveném čase) • Daná cena a omezené zdroje • Interdisciplinární charakter a dynamické projektové týmy • Projekty se musí vyrovnávat s faktorem neznámého a riziky Co není projekt? • projekty nejsou rutinní aktivita • projekty nejsou opakovaná činnost • projekty nejsou standardní pracovní postup • projekty nejsou běžná práce • projekty nejsou popis práce • projekty nejsou provoz Společné charakteristiky projektu a provozu • definované cíle • definovaná kvalita • organizovaná činnost • určité výsledky • kontrolní mechanismy • dokumentace Hlavní činnosti řízení projektů • Plánování • Organizování • Delegování a motivování • Řízení času, zdrojů, financí a nákladů, komunikace, kvality, změn, rizik a rezerv • Hodnocení a kontrolování Podněty pro vznik projektů IS/ICT • z existující a udržované Informační strategie, • ze zhodnocení průběhu vykonávaných hlavních, podpůrných a řídících procesů podniku, • z podnětů a požadavků uživatelů IS/ICT. Oddělení řídicího a věcného postupu projektů IS/ICT • V průběhu vývoje jednotlivých metodik a standardů specifikujících metody, techniky a nástroje řízení projektu, postupy (fáze, kroky) projektu, kategorie a typy projektů a s nimi spojené specifické postupy došlo k oddělení řídícího postupu projektu od věcných (produktově orientovaných) postupů. Řídící postup projektu • Příprava projektu – zahrnuje činnosti spojené se zadáním a přípravou projektového záměru, ve kterém jsou popsány všechny hlavní charakteristiky projektu (důvody, cíle a rizika projektu, výstupy, rozsah, cena, zdroje projektu). Příprava projektu končí projednáním projektového záměru a přijetím rozhodnutí o dalším osudu projektu. Řídící postup projektu • Naplánování projektu – obsahuje činnosti spojené s přípravou plánu projektu. Vstupem je odsouhlasený projektový záměr. V průběhu naplánování projektu jsou realizovány činnosti spojené nejenom s vytvořením diagramu rozkladu prací (WBS – Work Breakdown Structure), provedením časových odhadů a stanovením rezerv, ale i s přiřazením zdrojů projektu, přípravou a ustavením projektových týmů. Řídící postup projektu • Provedení projektu – v průběhu tohoto stadia jsou realizovány naplánované činnosti, řízeny změny projektu a vytvářeny a akceptovány výstupy projektu. • Ukončení projektu – obsahuje činnosti zabývající se závěrečným vyhodnocením projektu, zobecněním a zapracováním zkušeností a poznatků do používané metodiky řízení projektů (postupů, šablon a vzorů). Rozložení fází projektu Věcné postupy Věcné postupy obsahují vzorový rozklad prací členěný do etap a činnosti konkretizovaných pro příslušný věcný typ projektu. Například pro typ projektu „Vývoj IS“ mohou být definovány etapy: • Úvodní studie, • Globální analýza a návrh, • Detailní analýza a návrh, • Implementace, • Zavedení IS. Kompetence - řízení a koordinace projektů IS/ICT Frameworky pro řízení projektů • Certifikace projektového manažera dle IPMA (International Project Management Association), • Certifikace projektového manažera dle PMI (Project Management Institute) – Standard PMBOK (A Guide to the Project Management Body of Knowledge), • Certifikace projektového manažera dle PRINCE2 (Projects IN Controlled Environment), • Managing Successful Programmes (MSP), • ČSN ISO 10 006. International Project Management Association (IPMA) • International Project Management Association (IPMA) je nadnárodní sdružení národních asociací projektových manažerů. Prvořadou funkcí je prosazovat porozumění řízení projektů jako profesi, která má svou globální působnost, standardy, znalosti a schopnosti. Sdružuje projektové manažery napříč všemi obory lidské činnosti. • Certifikace je určena pro projektové manažery, členy týmů řízení projektů, program manažery a manažery portfolia. Cílem je vylepšení kvality řízení projektů, programů, portfolia a také zlepšení dosahování cílů projektů, programů a portfolií. IPMA nabízí 4 certifikační stupně, tzv. 4-L-C. IPMA 4 certifikační stupně • A – Certifikovaný ředitel projektů (IPMA Level A, Certified Projects Director) - je schopen komplexně řídit portfolio nebo program s vazbou na strategii a byznys organizace s odpovídajícími zdroji, metodologií a nástroji, řídit manažery projektů, s podporou expertů projektového řízení, • B – Certifikovaný projektový senior manažer (IPMA Level B, Certified Senior Project Manager) - je schopen řídit komplexní projekty, často rozložené na dílčí projekty a to včetně řízení manažerů dílčích projektů. Rovněž je schopen úspěšně používat elementy kompetencí ve složitých situacích s vysokou komplexitou řízení. Vede manažery projektů v rámci jejich profesního rozvoje. • C – Certifikovaný projektový manažer (IPMA Level C, Certified Project Manager) je schopen řídit projekty s omezenou komplexitou. Je schopen úspěšně používat elementy kompetencí v situacích s omezenou komplexitou řízení, • D – Certifikovaný projektový praktikant (IPMA Level D, Certified Project Management Associate) je schopen pracovat v týmu s cílem splnit úkol. Je schopen používat všechny elementy kompetencí. Project Management Body of Knowledge (PMBOK) • PMBOK je mezinárodně uznávaný standard řízení projektů, který vydává institut PMI (Project Management Institute). Institut kromě toho vydává také další standardy zaměřené na řízení projektů a nabízí certifikační program vedoucích projektů. • PMBOK byl v roce 1996 změněn na průvodce s názvem A Guide to the Project Management Body of Knowledge, zkráceně PMBOK Guide. Běžně se však stále používá zkrácený výraz PMBOK. Standard je nejvíce rozšířen v USA. PMBOK • PMBOK je mezi ostatními standardy a metodikami nejstarší a nejobecnější. Svojí šířkou se snaží popsat všechny aspekty projektového řízení. PMBOK se dělí na 10 základních znalostních oblastí, které dohromady tvoří model projektového řízení. PMBOK je primárně zaměřen na firmy dodávající svoje výrobky nebo služby prostřednictvím projektů. • PMBOK Guide je procesně orientovaná metodika. Cíle je dosahováno pomocí definovaných procesů. Každý proces má určeny své vstupy a výstupy a techniky a návody, jak by měl být prováděn. V edici 2008 je každý proces doplněn diagramem datových toků tak, aby byla jasná provázanost jednotlivých procesů. Skupiny procesů PMBOK • Iniciační procesy, • Plánovací procesy, • Realizační procesy, • Monitorovací a ovládací procesy, • Ukončovací procesy Znalostní oblasti PMBOK • Řízení integrace projektu, • Řízení rozsahu projektu, • Řízení času projektu, • Řízení nákladů projektu, • Řízení kvality projektu, • Řízení lidských zdrojů projektu, • Řízení komunikace projektu, • Řízení rizik projektu, • Řízení obstarávání projektu, • Řízení zainteresovaných stran projektu. PMI typy certifikací • Project Management Professional (PMP), • Portfolio Management Professional (PfMP), • PMI Agile Certified Practitioner (PMI-ACP), • PMI Professional in Business Analysis (PMI-PBA), • Program Management Professional (PgMP), • Certified Associate in Project Management (CAPM), • PMI Risk Management Professional (PMI-RMP), • PMI Scheduling Professional (PMI-SP). Projects IN Controlled Environment (PRINCE2) • PRINCE2 je metodika vlastněná a spravovaná Office of Government Commerce (OGC). V současnosti se jedná o nejrozšířenější metodiku řízení projektů v Evropě. • Metodika PRINCE2 se opírá o sedm principů, tvoří ji sedm procesů a popisuje sedm témat. V rámci konkrétního projektu je nutné metodiku PRINCE2 přizpůsobit, což znamená, že je nutné porozumět principům, které jsou páteří celé metodiky. Jednotlivé procesy mohou být velmi zjednodušeny a každý z nich má mnoho možností použití podle specifik projektu. Principy však zůstávají a zaručují, že projekt je projektem v kontrolovaném prostředí. PRINCE2 • Podpora přizpůsobení metodiky zahrnutá přímo v manuálu je významnou předností PRINCE2 oproti PMBOK. Naopak PRINCE2 nepokrývá např. oblasti vedení lidí, manažerské dovednosti, podrobné pokrytí nástrojů pro řízení projektů, které jsou podrobně popsány již existujícími a osvědčenými metodami. Byl také vytvořen systém certifikace pro projektové manažery dle PRINCE2. PRINCE2 typy certifikací: • PRINCE2 Foundation, • PRINCE2 Practitioner, • PRINCE2 Agile. Managing Successful Programmes (MSP) • Publikace Managing Successful Programmes od společnosti Axelos předkládá v podobě dobré praxe návody na řízení transformačních změn v organizacích. Program management je vnímán jako standard v ziskovém i neziskovém sektoru. Využívají jej zejména společnosti, které realizují několik paralelních projektů se společným cílem. • Standard MSP umožňuje naplnění systematické a konzistentní posloupnosti všech dílčích projektů a efektivní koordinaci cílů na strategické úrovni. Je rovněž využitelný v oblasti inovací produktů, služeb, zvýšení efektivnosti a zvýšení procesní vyspělosti manažerského řízení. 3 klíčové koncepty MSP • Principy (Principles): Jsou založené na pozitivních i negativních zkušenostech získaných z programového řízení. Tyto zásady mají v obou případech společné základy úspěšného řízení změn, • Řídící témata (Governance Theme): Pomáhají s definicí toho, co organizace potřebuje k efektivnímu řízení programů od nejvyššího managementu až po transformaci do dílčích projektů. MSP Řídící Témata pomáhají s nastavením programových cílů, k řízení týmů, k nastavení funkční organizační struktury a ke stanovení kontrolních mechanismů tak, aby zvýšili šanci realizace programu, • Transformační tok (Transformational Flow): Zabývá se celým životním cyklem programu, od stanovení strategických cílů, přes jejich realizaci až po výsledek - benefity programu. MSP typy certifikací: • MSP Foundation Examination, • MSP Practitioner Examination, • MSP Advanced Practitioner Examination. Směrnice ISO 10006 pro management jakosti projektů • ISO 10006 není metoda řízení ani kvalifikační systém, je to standard, který slouží jako referenční model pro nastavení řízení projektů v organizaci. Norma obsahuje obecné zásady či postupy a je určena pro projekty všech typů. • Model má doporučující povahu a proto nebyl původně zamýšlen k certifikaci. Norma není návodem pro řízení konkrétního projektu. Mnohem více je pozornost zaměřena na procesy, jejich strohý popis a v neposlední řadě na mechanismus neustálého vylepšování procesů při řízení projektů. Základní principy projektového řízení Předpoklady pro řízení projektu • Kvalitní projektovou dokumentaci. • Efektivní spolupráci v týmu. • Znalost principů projektového řízení. • Efektivní alokaci všech zdrojů včetně personálních. • Efektivní projektový controlling Výhody projektového managementu • Jasně definované základní parametry a cíle. • Synergický efekt systému řízení pro další projekty. • Určení odpovědností bez vlivu na stálé organizační struktury. • Efektivní přidělení všech zdrojů po dobu projektu. • Možnost nastavení optimálního controllingu. Projektové zásady • Po celou dobu projektu se důsledně orientovat na cíl. • Pracovat jen s informacemi, které jsou ověřeny relevantními zdroji. • Nastavit systém včasné identifikace rizik. • Nastavit systém řízení s důsledným a srozumitelným rozhodováním. • Nastavit otevřenou informační strukturu v projektovém týmu. Předprojektová fáze • Každý projekt začíná nějakým záměrem (vizí, nápadem apod.), který má být zrealizován. Zdaleka to neznamená, že každý takový záměr bude realizován a pokud ano, tak že to bude s využitím projektového řízení. • Nejdříve někdo musí rozhodnout, zda vůbec bude záměr realizován, a pokud ano, dát jeho realizaci nějaký rámec. Tím, kdo o realizaci záměru rozhodne, je management organizace, v čele s osobou nejvyšší v hierarchii dané organizace nebo její jednotky, která je za ni zodpovědná. Předprojektová studie • Předprojektová studie by měla popsat potenciální projekt zejména z hlediska příležitosti (opportunity study) a proveditelnosti (feasibility study). • Předprojektová studie je analogie dokumentu v metodice PRINCE2 označovaného jako „Předběžný Obchodní případ“. • Na základě posouzení předprojektové studie rozhodne management organizace nebo programu o tom, zda bude projekt realizován. V případě kladného postoje projekt získá mandát k realizaci (Mandát projektu) a následuje Fáze nastavení projektu. Náležitosti předprojektové studie • účel projektu (proč má být projekt realizován, rozbor příležitosti k realizaci projektu a vize která stojí za záměrem ho realizovat; reakce na příležitost, ohrožení), • analýza současného stavu ve vazbě na projekt (popis situace, ze které projekt vychází a kterou řeší, případně doplněnou o odhad trendů vývoje), • přínosy projektu (co jeho úspěšná realizace organizaci přinese), • oportunitní pohled na řešení situace (jak by mohlo být dosaženo přínosů projektu jiným způsobem; srovnání náročnosti, nákladů, rizik apod., včetně případné nulové varianty, tedy co by se stalo, pokud by projekt realizován nebyl, zda má smysl ho realizovat; relevantní kritérium je i vhodné načasování projektu s ohledem na další aspekty (finanční, projektového portfolia apod.) Náležitosti předprojektové studie • oportunitní pohled na využití organizačních zdrojů (pokud bude projekt realizován, a tak vytíženy zdroje, co jiného nebude možné realizovat (jiné projekty a aktivity), • dopady projektu na celkovou strategii organizace; možné synergie s jinými aktivitami v organizaci, dalšími projekty apod.; pozitivní i negativní, • jaké jsou dosavadní zkušenosti v řešené oblasti (zkušenosti s ohledem na řešení podobných situací a projektů), • návrh rámcového rozsahu projektu (jaké hlavní subdodávky bude projekt zahrnovat), Náležitosti předprojektové studie • předpoklad časového horizontu přípravy a realizace projektu, • předpoklad nákladů na realizaci projektu a ekonomického zatížení organizace (CF ad.), předpoklad ekonomických přínosů a související ukazatele návratnosti, • jaké jsou hlavní předpoklady a omezení úspěšné realizace projektu, • jaká jsou hlavní rizika realizace projektu, • kdo by měl být do projektu zapojený (role a jejich případné personální obsazení včetně ověření, že jsou tyto osoby disponibilní), Náležitosti předprojektové studie • sumarizující SWOT analýzu projektu, • přehled případných variant řešení s ohledem na dosažení přínosů projektu, času, nákladů, vazbám na jiné projekty a další relevantní zkušenost; pokud to odpovídá situaci, může být součástí této části posouzení sekvenčního rozdělení projektu na více dílčích projektů (s ohledem na snížení nákladů, rizik, flexibilnější reakci na potřeby apod.); pokud je hledání varianty řešení podstatnou neznámou, zařazuje se se tato část jako samostatná analýza před předprojektovou studií (Pre-feasibility study), • celkové doporučení, zda projekt realizovat či ne, případně podpořený expertním posouzením. Fáze nastavení projektu • Prvním krokem po udělení mandátu projektu je jmenování Vlastníka projektu a Projektového manažera. • Projektový manažer ve spolupráci s Vlastníkem projektu realizují nastavení projektu, tzn., definují hlavní cíle a přínosy projektu, základní organizační strukturu, projektové plány, vč. nákladů a časového rozmezí projektu, a další důležité body, které tvoří základní kostru projektu. • Nastavení projektu vychází ze schválené Předprojektové studie a případných připomínek při udělování Mandátu projektu. Fáze nastavení projektu - dokumenty • Projektový záměr – detailně určuje, CO má projekt realizovat a vytváří rámec projektu (V metodice PRINCE2 označovaný jako aktualizovaný Obchodní případ, v metodice PMI pak Project charter) • Organizace projektu – definuje, jaké role a v jakém personálním obsazení bude projekt vyžadovat. • Strategie řízení vztahu se zájmovými skupinami – analyzuje vliv zájmových skupin a navrhuje způsob komunikace s nimi. • Strategie řízení rizik – analyzuje možná rizika projektu a navrhuje způsob, jak je řídit. • Plánování projektu – předchozí body mají charakter strategie, poslední bod na jejich základě vytváří podrobné plány, jak projekt realizovat Projektový záměr (Business Case) Projektový záměr vytváří rámec projektu, vychází ze schválené Předprojektové studie a případných připomínek k ní a vymezuje: • Účel projektu (proč je projekt realizován ve vztahu k prvotní idey, vizi, příležitosti, ohrožení apod.), • Přínosy projektu (co jeho úspěšná realizace organizaci přinese) ve vazbě k současnému stavu; přínosy změny, • Cíle projektu (explicitně vymezený stav, který bude dosažen realizací projektu); cíle jsou podkladem pro akceptační kriteria; viz dále, • Rozsah projektu (Scope) / Ne-cíle projektu / Hranice projektu – explicitní stanovení, co by projekt měl řešit a co již ne, • Očekávané negativní přínosy – předem vymezené negativní dopady, které realizace projektu může přinést. Projektový záměr • Výchozí podmínky – co musí být splněno, aby mohl být projekt realizován a dosáhnout svých cílů • Výchozí předpoklady – co se předpokládá, jaká východiska, na kterých příprava projektu staví, vč. kontextu projektu, který může ovlivňovat úspěšnost projektu • Kontext projektu – s ohledem na program a portfolio projektů, společné využívání zdrojů, možná rizika i synergie, harmonizace apod. • Zdroje financování – zdroj financování projektu a způsob a frekvence transferu prostředků, případně plán CF. • Projektový přístup Cíle projektu • Kritéria úspěchu, daná jasně definovanými cíli projektu jsou měřítkem pro posouzení výsledku projektu (zejména pro jeho závěrečné posouzení). Měla by být proto co nejjednoznačnější a nejsrozumitelněji definována a měla by být reálná a měřitelná; ideálně formou SMART. • V projektu vždy existuje rovnováha mezi základními vzájemně se omezujícími zájmy. Upřesnění jednoho je vždy na úkor jiného. Tento vztah se nazývá trojimperativ projektu. Trojimperativ projektu • Trojimperativ projektu znamená, že nelze zvyšovat kvalitu výstupů (CO), aniž by to mělo dopad na cenu (ZA KOLIK) nebo čas (KDY) a analogicky to platí i opačnými směry. • Proto je v projektu nutné vymezit i tzv. určující osu, která vymezuje jedinou hlavní prioritu v rámci cílů projektu (kvalita/cena/čas). Metoda logického rámce Organizační struktura projektu Role – organizace projektu • Projektový výbor, nejvyšší orgán v projektu, který zodpovídá za směřování (v metodice IPMA se používá označení „Řídící komise“) • Vlastník projektu, nejvýše postavená role v projektu s největšími pravomocemi (v metodice PRINCE2 „Sponzor projektu“) • Manažer projektu, nejvyšší exekutivní pozice v projektu zodpovědná za jeho realizaci. Projektový výbor • Projektový výbor je vlastníkem projektu. Schvaluje významné plány a každou zásadní odchylku od schváleného Plánu etapy, schvaluje dokončení/splnění jednotlivých etap a schvaluje start následující etapy, odsouhlasuje/projednává tolerance projektu s Managementem společnosti nebo Programu. Projektový výbor není demokratický – Vlastník/Sponzor rozhoduje. • Projektový výbor odpovídá za soulad strategie společnosti s cíli projektu (napojení na společnost nebo program, působí jako arbitr při konfliktech v rámci projektu, autorizuje a schvaluje globální plány, autorizuje a zajišťuje dostupnost schválených požadovaných zdrojů a odsouhlasuje a stanovuje tolerance pro etapy s Projektovým manažerem. Vlastník projektu • Vlastník projektu je obvykle členem výkonného managementu. Je zodpovědný za tvorbu a údržbu Projektového záměru, schvalování organizační struktury, schvalování Plánu projektu a Plánů etap, řešení problémů a formální ukončení projektu. Vlastník je celkově odpovědný za projekt (celková odpovědnost za projekt nemůže být delegována). Vlastník je podporován Hlavním uživatelem a Hlavním dodavatelem. • Vlastník projektu odpovídá za Projektový záměr v průběhu celého projektu. Zajišťuje, že projekt má hodnotu do něj vložených peněz a je realizován efektivně z hlediska nákladů. Jeho hlavním zájmem je ziskovost. Může přehlasovat ostatní členy Projektového výboru. Projektový manažer • Projektový manažer má odpovědnost za realizaci každodenní práce projektu tak, jak je vedena Projektovým výborem v rámci limitů stanovených Projektovým výborem. • Hlavní odpovědností projektového manažera je zajistit, že projekt vytvoří požadovaný produkt dle definovaných standardů kvality a v rámci předdefinovaných časových a nákladových limitů. V případě odchylky reaguje, koriguje či eskaluje. Je odpovědný i za změny/rizika v rámci projektu. Základní povinnosti projektového manažera • Řídí klíčové organizační procesy projektu. • Zodpovídá za realizaci projektu po manažerské linii. • Řídí podřízené týmové manažery. • Přiřazuje zdroje v souladu s plánem. • Rozhoduje o odměňování členů týmu. • Vede jednání s dodavateli a odběrateli. • Předkládá reporting projektovému výboru. • Předkládá řídícímu výboru požadavky nad své kompetence. Pojetí zodpovědnosti a odpovědnosti dle Kerznera • autorita (angl. Authority) – moc, která je přidělena jednotlivci tak, aby tento mohl uskutečňovat určitá rozhodnutí, která jsou respektována ostatními jedinci, • zodpovědnost (angl. Responsibility) – morální povinnost přijatá jednotlivcem spočívající v efektivním splnění uloženého úkolu, • odpovědnost (angl. Accountability) – schopnost plnění pověření – stav, kdy jednotlivec dokáže naplnit očekávání a uspokojujícím způsobem završit určité pověření tím, že má současně dostatek autority i schopností a zodpovědnosti ke splnění tohoto očekávání, Další role - Hlavní uživatel • Hlavní uživatel reprezentuje ty, kteří získají přínosy z užívání produktů. V případě více uživatelů, koordinuje hlavní uživatel zástupce dalších skupin uživatelů. Slouží jako spojka mezi uživateli a projektovým týmem. Je silně zainteresovaný na udržení specifikace produktu týkající se kvality, funkcionality a uživatelské přátelskosti. • Hlavní uživatel odpovídá za specifikaci požadavků všech budoucích uživatelů finálního produktu, definuje přínosy, musí demonstrovat, že dodané produkty budou mít očekávané přínosy (a to i po ukončení projektu), obvykle odpovídá za provedení posouzení přínosů, schvaluje Popisy produktů nezbytné jako vstup nebo výstup pro dodavatele, zajišťuje dostupnost požadovaných zdrojů uživatelů a řeší konflikty mezi požadavky uživatelů a prioritami. Další role – Hlavní dodavatel • Hlavní dodavatel reprezentuje zájmy těch, kteří vyvíjejí, oživují, připravují a vyrábějí produkty projektu pro jejich nasazení (tvůrci produktů projektu). • Hlavní dodavatel je odpovědný za kvalitu produktů dodaných dodavatelem, zajišťuje, že přístup k řešení projektu je proveditelný a koordinuje ostatní participující dodavatele. Musí být oprávněn užívat nebo schvalovat nezbytné zdroje dodavatele (především lidské zdroje). Další role - Týmový manažer • Týmový manažer zajišťuje tvorbu produktů dle instrukcí Projektového manažera. Projektový manažer přenáší autoritu a odpovědnost za tvorbu produktů na týmy specialistů/odborníků. Tato úroveň řízení projektu je dobrovolná a její využití je závislé na velikosti projektu. Zásady pro sestavení projektového týmu • Dostatečná kvalifikace • Odpovídající časový fond pro potřeby projektu. • Přidělení přesného časového fondu pro účely projektu. • Jasné stanovení vazeb podřízenosti. • Jednoznačně stanoven systém odměňování s motivačním prvkem Možnosti redukce rolí v organizaci projektu Problematika zainteresovaných stran • Projekt není realizován izolovaně, ale dotýká se řady lidí, ať v projektovém týmu nebo mimo něj (v organizaci). Zainteresovaná strana, či anglicky „Stakeholders“ je jedinec nebo skupina, která může ovlivnit nebo být ovlivněna, nebo se považují za ovlivněné realizací programu/projektu/činnosti/aktivitou/rizikem. • Zainteresované strany nemají formální rozhodovací pravomoci v projektu, ale mohou být zásadní pro jeho úspěšnost a přijetí. Často realizací projektu něco získají nebo ztratí. Procesy, změny či vynaložená energie, která s projektem souvisí, tak může namísto podpory vyvolat odpor proti projektu. Často za odmítáním projektu stojí prostý strach z nového, pocity ohrožení apod. Zainteresované strany - přístup ke změnám Přístup ke změnám, a ty projekt obvykle přináší, může být obecně dvojí: • Chápání změny jako příležitosti, což vyvolává aktivitu a pozitivních hledání řešení (hledání způsobů, jak problémy vyřešit). • Chápání změny jako nepříležitosti či ohrožení, což vyvolává pasivitu resp. aktivní obranu a hledání negativních řešení (důvodů, proč to nejde). Zainteresované strany – řízení vztahu • Způsob komunikace se zainteresovanými stranami (frekvence, způsoby, odpovědnost) definuje strategie řízení komunikace. • provést analýzu zainteresovaných stran • vytvořit strategii zapojení zainteresovaných stran • naplánovat zapojení zainteresovaných stran a komunikaci s nimi • aktivně zapojit zainteresované skupiny do průběhu projektu • měřit efektivitu Zainteresované strany – řízení vztahu Řízení rizik projektu • Koncept Řízení rizik popisuje systematické využití metod pro identifikaci a vyhodnocení potenciálních rizik a pro plánování odpovídajících opatření. Tím je kontrolováno řízení projektu a v maximální možné míře zamezeno neočekávanému vývoji, který může ohrozit úspěšnost projektu. • Řízení rizik Identifikuje, vyhodnocuje a řídí nejistotu a ve výsledku zvyšuje schopnost projektu uspět. Řízení rizik - Základní pojmy • Riziko je nejistá událost, která v případě, že nastane, má negativní (nebo i pozitivní) vliv na dosažení cílů projektu. • Nebezpečí – možný výskyt nepříznivé události. • Hrozba – nejistá událost s negativním dopadem na cíle projektu (konkrétní projevy této události) • Příležitost – nejistá událost s pozitivním dopadem na cíle projektu (riziko má tedy nejen negativní význam) • Scénář / Dopad – Nepříznivý děj, který událost způsobí • Pravděpodobnost – Pravděpodobnost výskytu dvojice: hrozba × dopad (projeví se konkrétní projev události a způsobí konkrétní dopad) • Škoda – Újma vzniklá v důsledku nepříznivé události • Riziko – Riziko je kvantifikovaná dvojice: hrozba × dopad. Vyjádření pravděpodobnosti s jakou utrpíme konkrétní škodu. Řízení rizik Efektivní řízení rizik • nahlížení na projekt v širším kontextu, • stanovení jasných cílů projektu, • zapojení zainteresovaných stran, • aktivní vytipování a sledování varovných signálů, • posuzování rizik v pravidelných cyklech, • pravidelný reporting rizik, • jasné definování rolí a odpovědností, • tvorba konkrétního systémového přístupu k Řízení rizik, • podpora Řízení rizik v organizaci, • ukotvení Řízení rizik ve firemní kultuře, • podpora kontinuálního zlepšování v organizaci. Postup řízení rizik 1. Identifikace 2. Kvantifikace 3. Eliminace 4. Monitoring Identifikace rizik • Identifikace rizik vychází z předchozích analýz (předprojektová studie), předchozích zkušeností, expertních znalostí a může být podpořena podpůrnými nástroji (brainstorming, analogie, analýzy s využitím diagramu rybí kosti, SWOT analýzou ad. • Identifikace rizik zjišťuje, co se může stát nepříznivého ve vazbě hrozba -> následek, přičemž jedna hrozba může mít více následků a více hrozeb může mít jeden společný následek. Kromě pravděpodobnosti a dopadu by měl být posuzován i aspekt blízkosti (kdy mohou hrozby nastat a jejich vývoj během projektu). Kvantifikace rizik -> Eliminace rizik • Jaká je pravděpodobnost výskytu dvojice: hrozba × dopad? • Jakou škodu způsobí? • Z analýzy rizik pak vychází strategie eliminace rizik. Jejím cílem je vyhnout se nebo redukovat hrozby a jejich dopad a maximalizovat příležitosti a jejich dopady. Eliminace rizik Pravidla pro eliminace rizik • náklady na eliminaci rizika by měly být úměrné pravděpodobnosti a dopadu, • náklady na eliminaci rizik by neměly překročit rozpočet na rizika, • mělo by být zváženo výhodnost řešení ex ante (prevence) i ex post (reakce), • vedle úsilí vyhnout se riziku by se nemělo zapomínat na možnost je sdílet a přijmout, • mělo by se počítat s riziky sekundárními (vyplývajícími z implementovaného řešení), • mělo by se počítat s riziky reziduálními (zbytkové riziko pop implementaci řešení). Eliminace rizik Monitoring rizik • Monitoring rizik by měl být na programu každé projektové schůzky. Mělo by být ověřeno, v jakém stavu jsou aktivity k eliminaci rizik, jaký je jejich vývoj v matici pravděpodobnost × dopad a jaké jsou nové nebezpečí/hrozby. Relevantní výstupy jsou reportovány. Specifika rizik pro ICT projekty (Levison) • Méně než třetina, přesněji 29 procent, IT projektů bývá podle průzkumů Standish Group dokončena úspěšně. Softwarové společnosti a projektoví experti se opakovaně shodují na tom, že vedení IT oddělení se znovu a znovu dopouští stejných chyb. • Problém ale není jen v ignorování obecně platných pravidel, ale i v obsazování nekompetentních osob na klíčové pozice, v nedostatečné schopnosti zvážit rizika ohrožující jednotlivé projekty či ve stanovení postupů, jak taková rizika eliminovat. 13 nejčastějších chyb a rizik v IT projektech Chyby v lidských zdrojích • Chyba č. 1: Projekt nedisponuje lidským kapitálem s požadovanými znalostmi a dovednostmi. • Chyba č. 2: Projekt nedisponuje zkušenými projektovými manažery. 13 nejčastějších chyb a rizik v IT projektech Chyby v postupu • Chyba č. 3: IT oddělení neuplatňuje základní postupy projektového managementu. • Chyba č. 4: IT oddělení je zahlceno mnoha procesy. • Chyba č. 5: IT nesleduje vliv dílčích změn na rámec celého projektu. • Chyba č. 6: IT nemá aktuální přehled o stavu projektu. • Chyba č. 7: IT ignoruje problémy. 13 nejčastějších chyb a rizik v IT projektech Chyby v plánování Chyba č. 8: IT nedefinovalo rozsah rámce celého projektu. Chyba č. 9: IT nebere v úvahu vzájemnou závislost mezi projekty. Chyba č. 10: IT nebere v úvahu Murphyho zákon. Chyba č. 11: IT odbývá řízení projektových změn. 13 nejčastějších chyb a rizik v IT projektech Komunikační problémy • Chyba č. 12: IT ignoruje nesmyslně stanovovaná data ukončení dílčích aktivit • Chyba č. 13: Špatná komunikace mezi IT, stranami zainteresovanými v projektu a investory. Plánování projektu • CO – specifikace produktů projektu • JAK – cesta jejich vytvoření (výrobní postup) • S KÝM – kdo je udělá a jak bude řízen • KDY – kdy produkty vzniknou • ZA KOLIK – kolik to bude stát Plán CO • Plán CO vychází ze specifikace produktu projektu v projektovém záměru. Hlavní produkt je dekomponován na dílčí produkty ve struktuře a hierarchii (Work Breakdown Structure (WBS)). • V plánu CO není relevantní hledisko JAK, KDY, KDO apod. WBS je pak východiskem pro ostatní plány. • WBS by měla být zpracována v týmu. Výhodným nástrojem je myšlenková mapa. Plán JAK • Plán JAK vychází z plánu CO a zachycuje jeho větší podrobnost. Určuje, jak vzniknou jednotlivé výstupy z CO, jaké činnosti s tím budou spojeny a v jaké logické posloupnosti. Hledisko času opět není relevantní. Zpracovává se odzadu. • Výsledkem je síťový graf Plán S KÝM & Plán KDY • Řeší personální obsazení realizačního týmu a odpovědnost za jednotlivé dodávky. Vychází z organizace projektu s důrazem na personální zajištění plnění jednotlivých úkolů. • Určení termínů zahájení činnost a termínu ukončení činnosti. Výsledkem plánu KDY je časový plán (Ganttův diagram, diagram CPM, diagram PERT, apod.) Chování lidských zdrojů • Parkinsonův zákon – činnost trvá nejméně tak dlouho, jak dlouhý má přidělený časový rozpočet. • Studentský syndrom – rezerva je spotřebována dříve, než je nutné, protože činnost se zahajuje, až když je to nezbytně nutné. Řešení: • Průběžná kontrola plnění termínů – negativní motivace • Rezerva jako zboží – rezerva má finanční hodnotu, kterou si může pracovník vybrat – pozitivní motivace Plán ZA KOLIK • Pokud je u každé položky plánu projektu náklad na její zajištění, je možné projekt finančně plánovat. V případě přípravy projektu je tak zřejmé, kolik budou celkové náklady na realizaci projektu a jak se budou vyvíjet v čase (Cashflow projektu). Při realizaci projektu pak lze podle těchto podkladů kontrolovat, že se projekt drží plánu. Základní zásady plánování • Plán musí být dosažitelný a motivující. • Všechny informace, které vstupují do plánovacího procesu, musí být po stránce správnosti přezkoušené. • Pokud pro účely plánu nepostačuje číselné vyjádření, je nutné doložit údaj komentářem. • Hodnoty uvedené v plánu musí být objektivně doložitelné a zdůvodnitelné. • Vlastní plánování musí být vysledovatelné, tj. porovnatelné se skutečností a minulostí Pravidla plánování • Kontinuita – umožňuje porovnání s předchozím obdobím. • Laditelnost – parametry plánu musí být sladěny od části k celku. • Stálost – stejné parametry plánujeme stejně, odlišné odlišně; věcná i časová plánovací diferenciace je nepřípustná. • Úplnost – do plánu vstupují všechny aktuálně známé informace rozhodné pro plánovací období a to jak interní tak externí. • Dokumentace – všechny zásadní kroky plánovacího procesu musí být zdokumentovány, aby mohly být jasně identifikovány příčiny odchylek. Dokumenty využívané pro operativní řízení projektu • Deník projektového manažera • Přehled získaných poznatků • Registr otevřených bodů • Registr rizik • Registr kvality Rozdělení realizační fáze projektu na etapy a balíky práce Výhody etap: • umožňuje uvolňovat rozpočet po částech dle etap, • uvolňování peněz a zdrojů v etapách redukuje rizika, • plánování je komplexnější a přesnější • větší kontrola (kontrolní body) – čím komplexnější projekt a více rizik, tím více etap • více rozhodovacích bodů v rámci projektu (-> pokračovat?) • možnost volby více malých nebo méně velkých etap Další operativní dokumenty • Zpráva o stavu etapy • Zpráva o ukončení etapy • Zpráva o stavu úlohy • Výkaz stavu produktů • Zpráva o výjimce • Plán realizace výjimky • Zpráva o otevřeném bodu Princip eskalování • Realizační fázi projektu mohou zjednodušit předem definované tolerance na všech úrovních řízení. Pokud se projekt pohybuje v jejích mezích, není nutné změny řešit, což snižuje administrativní zátěž řízení projektu. Změny a odchylky • Změnové požadavky – změna od zadání ex ante, tedy dopředu schválené, mají buď pozitivní vliv na kvalitu (lepší funkční vlastnosti), čas (zrychlení projektu) nebo náklady (jeho zlevnění). Mohou to být i změny s negativním vlivem na cíle projektu, u kterých je více efektivní akceptovat změnu než se pokusit předejít problému (je to nákladné, časově náročné, nebo to nemá podstatný vliv na kvalitu). Změnové požadavky musí být schváleny. Změny a odchylky • Odchylka od specifikace – změna od zadání ex post, tedy dopředu neschválené a schvalované až dodatečně/zpětně. Obvykle mají negativní vliv na kvalitu. Musí být řešeny (eliminace problému). Tam, kde to není možné nebo efektivní (je to nákladné, časově náročné, nebo to nemá podstatný vliv na kvalitu) je možné je dodatečně schválit. Mohou to být i odchylky s pozitivním vlivem zjištěné dodatečně; i ty však musí být schváleny. Kontrola rozpracovanosti projektu • Rozpracovanost projektu z hlediska času a vynaložených nákladů lze posuzovat s využitím metody EVA – Earned Value Analysis, resp. EVM – Earned Value Management. Kontrola rozpracovanosti posuzuje aktuální rozpracovanost a náklady ve vztahu k plánu a předpovídá vývoj plnění plánu. Podmínkou použití metodiky je stabilita plánu CO (WBS je stabilní s konstantním počtem úrovní) a skutečnost, že hlavním nákladem je pracnost. Kontrola rozpracovanosti projektu Metoda analyzuje tři parametry: • PV – plánovaná hodnota (planned value), • AC – aktuální náklady (actual cost), • EV – vytvořená hodnota (earned value), • PV > EV, projekt je zpožděn, • PV < EV, projekt je v předstihu • AC > PV, projekt je dražší, • AC < PV, projekt je levnější. Závěrečná fáze projektu • Akceptační dokumentace produktu – podle předem schválených akceptačních kritérií • Akceptační dokumentace projektu – podle předem schválených akceptačních kritérií • Zpráva o ukončení projektu – zpráva Projektového manažera Projektovému výboru potvrzující předání všech produktů a realizaci aktualizovaného Projektového záměru vč. vyhodnocení, jak úspěšně projekt dopadl v porovnání s Dokumentací o nastavení projektu. Závěrečná fáze projektu • Doporučení následných akcí – ukončením aktivity nekončí – po ukončení projektu se hodnotí konečné přínosy a probíhají následné akce vztahující se k nedokončené práci, trvajícím otevřeným bodům a rizikům a opatření nutná k posunutí produktu do jeho další fáze. • Zpráva o získaných poznatcích – zpráva popisující poznatky, které mohou být užitečně použity u dalších projektů, aby se organizace vyhnula opakování negativních zkušeností při dalších projektech. Příjemcem může být např. oddělení řízení kvality, manažer projektového portfolia nebo programu apod. • Oznámení o ukončení projektu – informace Projektového výboru všem zainteresovaným stranám a vlastníkům zdrojů o tom, že lze tyto zdroje i podpůrné služby uvolnit. Měl by být dále určen i termín, do kdy mohou být na projekt účtovány náklady. Projektové řízení v ČR (2015) • Šetření opakovaně ukazuje, že největší problémy, které ohrožují úspěšnost projektů v ČR, jsou spojené s lidskými zdroji. Patří mezi ně zejména nedostatečná kvalifikace a nekompetentnost členů projektového týmu či nedostatek kapacit a přetíženost členů týmů. • Mezi další zásadní problémy ohrožující úspěšnost projektů patří nejednoznačné zadání, nejasně definovaný rozsah či nedostatek plánování, nekompetentnost zákazníka projektu a nedostatečná podpora ze strany sponzora projektu. Mezi významné problémy patří neuřízené změny v průběhu realizace projektu, nedostatečná komunikace či celková kultura v organizaci. Projektové řízení v ČR (2015) • Více než polovina (59%) organizací, ve kterých respondenti působí, formálně vyhodnocuje dopady a přínosy projektů po ukončení jejich realizace. 34% je nevyhodnocuje a 7% respondentu neví, zda jsou vyhodnocovány. V této oblasti došlo oproti roku 2012 ke zlepšení. • Projektovou kanceláří celkově disponuje 58% organizací, ve kterých respondenti působí. Téměř stejný počet organizací, jen o dva respondenty méně, využívá jednotnou metodiku řízení (56%). Podíl organizací s projektovou kanceláří a jednotnou metodikou řízení projektů oproti šetření roku 2012 vzrostl. Projektové řízení v ČR (2015) • Využívání metod, technik a nástrojů doporučovaných jako dobrá praxe je v ČR stále na nízké úrovni. • Nejvíce využívanými nástroji je plánování cest s využitím kritické cesty, matice odpovědností a identifikační listina projektu. Projektoví manažeři, kteří jsou držiteli některého z mezinárodních certifikátů, využívají doporučené nástroje v průměru o 15 % více, než necertifikovaní. • Nejvýraznější rozdíl je viditelný u WBS (Work Breakdown Structure), který certifikovaní respondenti používají o 40 % více, než necertifikovaní. 5 největších problémů, které ohrožují úspěšnost projektů Faktory ovlivňující úspěšnost a posuzování úspěšnosti projektů • zkušenosti, praxe; • kompetentní a motivovaný projektový tým a dobrý manažer projektu; • silný a fungující sponzor projektu, podpora vedení organizace; • zavedená pravidla, procesy, role, vyjasnění odpovědností mezi projektovým a liniovým řízením, • otevřená komunikace, komunikace na osobní úrovni, sdělování pravdy, pravidelné schůzky týmu; • stanovení jednoznačného zadání, • řízení zainteresovaných stran, zejména aktivní komunikace se zákazníkem; • práce s riziky • důslednost, akcent na kvalitu, např. zaznamenávání důležitých rozhodnutí a dohod atp. Projektové řízení v české praxi • Z šetření vyplývá, že více, než polovina respondentů pracuje ročně na čtyřech a více projektech. Nejvíce respondentů (47 %) se ročně účastní práce na 4 - 10 projektech. 5 % respondentů dokonce pracuje ročně na více než 20 projektech. • Projektovou kanceláří celkově disponuje 58 % organizací, ve kterých respondenti působí. Téměř stejný počet organizací využívá jednotnou metodiku řízení (56 %). 41 % organizací respondentů využívá jednotnou metodiku řízení projektů a zároveň disponuje projektovou kanceláří. Nástroje a techniky projektového řízení Vliv certifikace na využívání projektových nástrojů Vliv certifikace na využívání projektových nástrojů Vliv délky praxe na využívání projektových nástrojů Metodiky, metody, techniky, nástroje Metodiky, metody, techniky, nástroje Metodika = souhrn etap, přístupů zásad. Metodika stanovuje – co, kdo, kdy a proč má dělat během procesu vývoje. Zahrnuje: - organizace práce vývojového týmu - metody práce s informacemi o vyvíjeném IS - ekonomické otázky - vedení projektové a provozní dokumentace - způsob řízení v jednotlivých fázích vývoje IS - SW a HW prvky doporučené pro vývoj IS Metodiky, metody, techniky, nástroje • Metoda – určuje, co je třeba dělat v určité etapě vývoje IS. Bývá spojená s určitým přístupem (strukturovaný, objektový). • Technika – určuje, jak se dobrat požadovaného výsledku, tj. určuje přesný postup kroků, způsob použití nástrojů apod. příklad technik: prototypování, normalizace datového modelu, transformační a transakční analýza při tvorbě struktury programového systému. Metodiky, metody, techniky, nástroje • Nástroj = prostředek k uskutečnění určité činnosti, resp. k vyjádření výsledku dané činnosti (formalizuje vyjádření výsledku). Může být svázán s konkrétní technikou, např. CASE nástroje, modely IS (datový, funkční, stavový diagram). Vazby metodika-metoda-technika-nástroj • Metodika doporučuje použití určitých metod v průběhu vývoje IS, metody pak využívají určitých technik a nástrojů. Není však možné prohlásit, že daná metoda patří jednoznačně k určité metodice. Některé metody jsou specificky využívané konkrétní metodikou. Většina metod je univerzálních, využívají různé metodiky, v různých etapách vývoje IS. • Metodologie vývoje IS = zobecňující nauka o metodikách a metodách vývoje IS. Životní cyklus IS Životní cyklus IS Životní cyklus IS Životní cyklus IS • Model „spirála“ Kombinuje prototypování s analýzou rizik. Jednotlivé etapy jsou cyklicky procházené vždy na vyšší úrovni podrobnosti analýzy, návrhu i implementace systému. Základní prostředky pro boj se složitostí vývoje IS (1) • Hierarchický rozklad problematiky rozdělení složitého systému na subsystémy a to až do potřebné úrovně podrobnosti. Hierarchické rozdělení systému na subsystémy napomáhá plánovat, organizovat a kontrolovat práci vývojového týmu. Základní prostředky pro boj se složitostí vývoje IS (2) • Etapizace a iterace postupu řešení rozdělení složitého procesu vývoje IS na dílčí etapy. Každé etapě jsou přiřazeny cíle, úkoly, vstupy, výstupy, dokumentace, rizika, dílčí činnosti, odpovědné osoby, finanční náklady, apod. Iterace znamená opakované provádění činností jednotlivých etap vždy na vyšším stupni porozumění problému. Účelem iterace je postupné zpracování problému na různých úrovních rozlišení – od hrubé představy o řešení až k podrobnému návrhu systému. Základní prostředky pro boj se složitostí vývoje IS (3) • Modelování a srovnávání modelů základní technika používaná během vývoje IS. Základní prostředky pro boj se složitostí vývoje IS (4) • Použití grafických vyjadřovacích prostředků umožňují vytvořit si názornou představu o vyvíjeném IS. Grafické vyjadřovací prostředky jsou součástí CASE (Computer Aided System Engineering) tj. nástroje pro podporu vývoje IS – automatizují rutinní činnost. Agilní metodiky a techniky Odlišnosti ICT projektů • Jejich produkty (ICT) jsou převážně nehmotné povahy, tedy obtížněji definovatelné a mentálně uchopitelné. Tato vlastnost může být i jedním z důvodů stále nepříliš velkého procenta úspěšných projektů ICT. • Nemají většinou jasně definované zadání, cíle, uživatelské požadavky, obsah jednotlivých výstupů. Tyto obsahové náležitosti projektu se objasňují až v průběhu projektu. • Podporují podnikové procesy a jsou jedním z nástrojů dosahování reálných potenciálů zlepšení podnikových procesů. Tato skutečnost ale současně významně ovlivňuje množství projektových změn, které musí být v průběhu projektu zpracovávány a integrovány do řešení. • Terminologie, metodiky, metody a techniky související s řízením projektů ICT a budováním ICT nejsou jednotné. Agile vs. Waterfall Agilní metodiky a techniky Agilní metodiky jsou skupiny metod původně určených pro vyvíjení SW založené na iterativním a inkrementálním vývoji. Umožňují rychlý vývoj softwaru a zároveň dokáží reagovat na změnu požadavků v průběhu vývojového cyklu. Podle těchto metodik se správnost systému ověří jedině pomocí rychlého vývoje, předložení zákazníkovi a následných úprav dle zpětné vazby. Historie agilních metodik Techniky užívané agilními metodikami se často používaly už dříve, ale pojem se začal používat až v únoru 2001. V Utahu se tehdy sešli odborníci z oblasti softwarového inženýrství a vývoje softwaru, aby diskutovali o odlehčených metodách vývoje. Sepsali Manifest agilního programování, kde definují přístup k vývoji nyní známý jako agilní programování. Historie agilních metodik Až do nástupu odlehčených metodik se používaly těžké, rigorózní metodiky. Ty jsou někdy kritizovány pro svůj vodopádový model vývoje a pro to, že vedoucí projektu svým blízkým dohledem omezuje vývojáře v práci. Kromě toho obtížně reagují na změny. V polovině 90. let se začaly objevovat odlehčené metodiky. Ty se podle jejich tvůrců navrací k vývojovým praktikám ze samotných počátků softwarového vývoje. Mezi tyto odlehčené metodiky patřil Scrum, Crystal Clear, Extrémní programování či Vývoj řízený vlastnostmi. Od publikování Manifestu agilního programování se tyto metodiky nazývají agilními. Agilní metodika a technika • Agilní metodika je způsob rozvržení a ověřování práce. Cílem Agilní metodiky bývá lepší organizace práce. Odlišné Agilní metodiky vedou k odlišným produktům, protože považují jiné aspekty produktu za klíčové. Liší se i přístup ke změně zadání. Možnost změny zadání je ale určující podmínkou. • Agilní technika je naproti tomu konkrétní postup, který se většinou týká samotných vývojářů. Cílem těchto technik bývá zvýšení produktivity práce, odstranění chyb, kvalitnější software nebo přesnější dodržení specifikace. Agilní techniky jsou od metodik oddělitelné. Cílem Agilní techniky bývá kvalitnější produkt. Rozdíly mezi agilní metodikou a technikou • Agilní metodika se zaměřuje na organizaci práce bez ohledu na to, zda se ve firmě vyvíjí software, nebo se jedná o jinou oblast, kde lze agilní řízení uplatnit. • V agilní metodice je kladen důraz na možnost změny, agilní technika nic takového nevyžaduje. • Agilní metodika se týká nejen vývojářů, ale i managementu. • Agilní technika je konkrétní činnost (především vývojáře, může se ale týkat i například klienta). Přínos agilní metodiky a techniky • Je předem známo, kolik práce je tým schopen udělat (v časovém rozsahu jedné iterace). To proto, že z minulosti je známo, jaká je rychlost v jednotlivých iteracích. Protože se zároveň dělají časové odhady na co nejkratší úkoly, je možné řídit rychlost týmu. • Změny zadání za běhu (což je například pro klasický Waterfall model naprosto neřešitelný problém) • Zrychlení doručování produktu od vývojáře k zákazníkovi (protože klientovi produkt doručujete po každém běhu – zákazník se navíc často účastní běhu firmy) Přínos agilní metodiky a techniky • Garance kvality (pomocí automatizovaných testů) • Odstranění třecích ploch mezi produktem a vývojáři. • Omezení rigidních procesů ve prospěch komunikace (jakkoliv Agile proti dobře nastaveným procesům nejdou – pouze omezují ty procesy, které brání efektivitě, komunikaci a agilnímu přístupu k práci) Priority agilního programování • Lidé a jejich spolupráce před procesy a nástroji • Fungující software před obsáhlou dokumentací • Spolupráce se zákazníkem před sjednáváním smluv • Reakce na změnu před dodržováním plánu Principy agilního programování 1. Nejvyšší prioritou je uspokojit zákazníka skrz rychlé a průběžné dodávání kvalitního software. 2. Změnové požadavky jsou vítány, dokonce i v průběhu vývoje. Agilní procesy je zpracují tak, aby zákazníkovi přinášely konkurenční výhody. 3. Dodávejte fungující software často, v intervalech týdnů až měsíců. Upřednostňujte kratší intervaly dodání. 4. Lidé z businessu a vývojáři musí spolupracovat každý den během celého projektu. 5. Pro práci na projektu vybírejte motivované jedince. Dejte jim prostředí a podporu, kterou potřebují, a důvěřujte jim, že práci dokončí. 6. Nejúčinnější metoda sdílení informací vývojářskému týmu (i uvnitř tohoto týmu) je osobní setkání. Principy agilního programování 7. Fungující software je hlavním měřítkem postupu vývoje. 8. Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopní dodržovat stálý výkon dokud je třeba. 9. Průběžná pozornost věnovaná technické dokonalosti a dobrému návrhu posiluje agilní přístup. 10. Základem je jednoduchost – umění co nejvíce práce vůbec nedělat. 11. Nejlepší architektury, požadavky a návrhy vznikají v týmech, které se samy organizují. 12. Tým v pravidelných intervalech vyhodnocuje svou práci a upravuje své postupy tak, aby byl co nejefektivnější. Fáze celého projektu v agilních metodikách 1. Nultá iterace – první krátká analýza a naprogramování nějaké základní činnosti. V agilním týmu nejde příliš o to, co se v této části bude implementovat. Podmínkou je, aby na konci byl hotový kousek aplikace, který se dá předvést (tedy i klientovi). 2. Analýza změny (výběr toho, co se bude implementovat, analýza a designování změn). 3. Samotná implementace požadované vlastnosti (či vlastností). Fáze celého projektu v agilních metodikách 4. Předvedení klientovi. 5. Pokud není produkt hotov, zpět na bod 2. 6. Pokud ano, následuje údržba, rozvoj (rovněž v iteracích). Body 2–4 se označují jako jedna iterace. Tyto body se opakují tak dlouho, dokud není vývoj ukončen (úspěchem, odložením projektu, proto, že dojdou peníze, změnou priorit klienta). SCRUM – metoda řízení agilního vývoje • V programování SCRUM (česky mlýn, skrumáž) je iterativní a inkrementální metodologie agilního vývoje softwaru používaná na řízení produktového vývoje. • Definuje flexibilní, holistickou strategii produktového vývoje, kde vývojový team pracuje jako jednotka na dosažení společného cíle", zpochybňuje předpoklady "tradičního, sekvenčního přístupu" k vývoji produktu, a umožňuje týmům se samoorganizovat podpořením fyzické kolokace nebo blízké online spolupráce všech členů týmu, stejně jako denní ústní komunikaci všech členů týmu a disciplín v projektu. SCRUM – metoda řízení agilního vývoje • Klíčový princip SCRUMU je jeho pochopení, že během projektu mohou zákazníci změnit názor o tom, co chtějí a potřebují (často zvané "souhrn požadavků") a že nepředvídané úkoly nelze jednoduše řešit tradičním předvídáním a plánováním. • Scrum používá empirický přístup, podle kterého problém nelze zcela pochopit nebo definovat a proto se soustředí na maximální schopnost týmu rychle dodat a reagovat na nové požadavky. SCRUM – metoda řízení agilního vývoje • Základem SCRUMU je Sprint - periodická činnost (s periodou obvykle uváděnou v týdnech), která je neustále kontrolována (např. každých 24 hod, 48 hod). • Vstupními parametry Sprintu jsou tzv. Backlog itemy (seznam návrhů na vylepšení stávajícího produktu, příp. chyby) a výstupním parametrem je Produkt s novou funkcionalitou, příp. bez zjištěných chyb. SCRUM proces Role v SCRUM • Product Owner - osoba zodpovědná za výsledný produkt, přiřazuje priority jednotlivým backlog itemům (vytváří Selected Backlog) • Scrum Master - osoba, jejíž úkolem je zajistit hladký průběh sprintu, organizovat schůzky, řešit případné administrativní problémy • Team - programátoři • Stakeholder(s) – uživatelé produktu, manažeři, osoby, kterých se problém dotýká, ale produkt (systém či SW) nevytvářejí Vlastník produktu (product owner) • Vlastník produktu reprezentuje zainteresované subjekty a je hlasem zákazníka. Je odpovědný za ujištění, že team do byznysu přidá hodnotu. Vlastník produktu píše články pro zákazníky (typicky zkušenosti uživatelů), hodnotí a přiřazuje jim priority, a přidává je do produktového backlogu. • Scrum týmy mají mít jednoho vlastníka produktu, tato role se nemá spojit se scrum masterem. Product owner má být na obchodní straně projektu, a nikdy nemá interagovat s členy týmu o technických aspektech vývoje. Tato role je stejná jako role customer representative (reprezentant klientů) v jiných agilních frameworcích. Role product ownera • demonstrovat řešeni pro klíčové stakeholdery, kteří nebyly na iteračním demu • ohlašovat uvedení nových verzí • komunikovat stav týmu • organizovat milníkové přehledy • vzdělávat v procesu vývoje • dohadovat priority, rozsah, financování a rozvrh • ujistit se, že produktové testy jsou viditelné, transparentní a jasné Vývojový team • Je odpovědný za dodání potenciálně použitelných inkrementů (potentially shippable increments - PSIs) produktu na konci každého sprintu (cíl sprintu). • Team je složen z 3-9 jednotlivců, kteří dělají aktuální práci (analýza, design, vývoj, test, technická komunikace, dokument, atd.). Vývojové týmy jsou vícefunkční, se všemi dovednostmi vytvořit produktový inkrement. • Vývojový team v skrumu je sebeorganizující, i když tady může být nějaký stupeň interakce s projektovým managementem (project management offices - PMOs). Scrum master • Scrum je usnadněný scrum masterem (mistrem), který je odpovědný za odstranění překážek teamu na dodání produktových cílů. • Scrum master není tradiční team leader nebo projektový manažer, ale koná jako prostředník mezi teamem a jakýmikoli negativními vlivy. • Scrum master zajišťuje, že scrum proces je použit jako bylo plánováno a členové týmu dodržují dohodnuté procesy. Často organizuje schůzky a povzbuzuje tým k zlepšení. Tato role se někdy označuje jako "team facilitator" na zdůraznění duální funkce. Eventy (události) • Sprint (nebo iterace) je základní jednotka vývoje ve scrumu. Sprint je časově omezená snaha, tedy je omezen na specifický čas. Doba je určena dopředu pro každý sprint a obvykle je to jeden týden až jeden měsíc, nejčastěji 2 týdny. • Každý sprint začíná eventem plánování sprintu, cílem kterého je definovat úkoly sprintu, kde je definována práce sprintu a odhadnut závazek pro cíl sprintu. • Každý sprint končí recenzí sprintu (sprint review) a retrospektivou, kde je reportován progres pro stakeholdery a definují se úlohy na zlepšení pro další sprinty. • Scrum zdůrazňuje zpracovaný produkt na konci sprintu, který je opravdu hotový, v případě software to může znamenat, že software byl integrován, kompletně testován, zdokumentován a potenciálně může být dodán. Plánováni sprintu Na začátku sprintu, tým organizuje sprint planning event - plánovací událost: • vybrat jaká práce se udělá • připravit úkoly sprintu, které určí čas na úkoly pro celý tým • definovat a diskutovat kolik práce je třeba udělat během sprintu • 4-hodinový limit pro 2-týdenní sprint, poměrně pro jinou délku • v první půli se celý tým (vývojový tým, scrum master a product owner) dohodnou, které produktové položky (backlog) budou v daném sprintu uvažovat • v druhé půli vývojový team urči práci (úlohy) potřebné na dodání položek backlogu, co rezultuje do sprintového backlogu Denní scrum Každý den během sprintu team organizuje denní scrum (nebo stand-up) se specifickými zásadami: • Všichni členové softwarového týmu přijdou připraveni. • Denní scrum začne přesně načas i když někteří členové chybí. • Denní scrum má proběhnout každý den na stejném místě a ve stejný čas. • Délka denního scrumu je omezena na 15 minut. • Každý je vítán, i když obvykle mluví jen teamové role scrumu. SCRUM in under 10 minutes • https://www.youtube.com/v/Q5k7a9YEoUI%26hl=en%26fs=1%26 Rational Unified Process (RUP) • Za počátek metodiky je možné považovat Ericssonův model z roku 1967, který rozděluje složité systémy z pohledu vzájemné komunikace do menších propojených bloků. • Model byl postupně upravován a rozšiřován tím způsobem, že byl iterativní vývoj uspořádán do po sobě jdoucích fází a výsledkem těchto inovací byla metodika Rational Objectory Process, která byla v roce 1998 přejmenována na Rational Unified Process Rational Unified Process (RUP) • Metodika je procesním rámcem pro vytvoření vhodné kombinace modelů a procesů v konkrétním projektu. Je variabilní, zobecňuje řadu procesů, lze ji přizpůsobit jakémukoliv projektu a konfigurovat na míru potřebám konkrétní organizace. Metodika vychází z praxí ověřených postupů a zkušeností, které vedou k úspěchu projektu. 6 nejlepších praktik RUP • Iterativní vývoj softwaru (Develop software iteratively), který umožňuje předví-dat rizika v každé fázi životního cyklu a reagovat na ně, usnadňuje správu změn, spolupráci se zákazníkem, testování aj. • Správa požadavků (Manage requirements), která znamená udržovat kontakt se zákazníkem, získávat, organizovat a dokumentovat požadavky a dynamicky reagovat na jejich změny tak, jak k tomu dochází v průběhu vývoje. • Použití komponentové architektury (Use component-based architectures), kdy komponenty jsou netriviální části systému, zajišťují určitou funkcionalitu, jsou nezávislé a nahraditelné jinými komponentami. Opakované použití hotové komponenty zvyšuje efektivitu vývoje a úsporu zdrojů. 6 nejlepších praktik RUP • Vizuální modelování softwaru (Visually model software), které zjednodušuje pohled na systém, umožňuje lépe systému porozumět: graficky znázornit procesy, závislosti, strukturu, chování komponent, zlepšit komunikaci. • Kontrolování kvality softwaru (Continously verify software quality), které předpokládá průběžné hodnocení požadavků na kvalitu, jakými jsou např. funkcionalita, spolehlivost a výkon v rámci každé iterace. • Řízení změn (Control changes to software), které nabízí postup změnového řízení pro optimální vývoj. Zajišťuje, aby změny byly přijatelné, aby proběhlo je-jich otestování a v případě problému byla možnost vrátit se k původní verzi softwaru. RUP – Dynamický pohled Životní cyklus RUP se skládá ze čtyř na sebe navazujících fází, kdy každá fáze je zakončena milníkem, tj. byly splněny cíle, které umožnily zahájit další fázi. Ke čtyřem fázím patří fáze: • Zahájení (Inception), • Rozpracování (Elaboration), • Konstrukce (Con-struction), • Nasazení (Transition). Součástí každé fáze jsou iterace, počet iterací závisí na velikosti projektu. Životní cyklus produktu v metodice RUP RUP - Zahájení • Ve fázi zahájení je vytvořen obchodní případ a vymezen rozsah projektu. Musí být podchyceny všechny externí entity, se kterými systém komunikuje, identifikovány případy užití, vyčísleny náklady, odhadnuta rizika. • Výstupem této fáze je vize projektu, klíčových vlastností a rozsah požadavků, počáteční model případů užití, počáteční obchodní případ, projektový plán a odhad rizik. RUP - Rozpracování • Ve fázi rozpracování je během jedné nebo více iterací vytvořený spustitelný prototyp. Jedná se o kritickou fázi, která je jako základ v dalších fázích rozpracována do definitivního a plnohodnotného systému. • Výstupem fáze jsou: spustitelný architektonický prototyp, popis architektury softwaru, use case model, revidovaný seznam rizik a obchodní případ, plán projektu včetně iterací aj. RUP – Konstrukční fáze, Nasazení • Cílem konstrukční fáze je vyvinou konečnou verzi systému a otestovat ji. Důležité je zachovat integritu systému a rovnováhu mezi náklady, časovým harmonogramem a kvalitou systému. • Výstupem konstrukční fáze je produkt, který je provozně způsobilý, otestovaný a připravený k předání zákazníkovi společně s manuálem. • Cílem fáze nasazení je předat produkt uživatelům. Současný produkt je pouze betaverzí, kterou je třeba ještě vyladit a dále testovat, přizpůsobit software pracovišti uživatele, školit uživatele a poskytovat podporu a údržbu produktu. RUP - Statický pohled • Metodika popisuje proces pomocí čtyř základních elementů, které odpovídají na násle-dující otázky: Role – „Kdo?“, Aktivity – „Jak?“, Artefakty – „Co?“, Pracovní procesy – „Kdy?“ • Při srovnání metodik je RUP objektově orientovanou iterativní metodikou, dodávanou jako sada HTML stránek. Tato robustní, rozsáhlá a propracovaná metodika, provázaná s UML notací, vychází z potřeb praxe. Detailně instruuje celý tým, jak má postupovat v průběhu realizace projektu. Pro potřeby řízení a vývoje obsahuje množství kvalitních a podrobných návodů včetně podpůrných prostředků. Srovnání metodik z pohledu životního cyklu SW Příklady dalších agilních metodik Extrémní programování (XP) XP je pravděpodobně nejznámější agilní metodikou. Propaguje časté dodávky software v krátkých vývojových cyklech. Kromě toho navrhuje párové programování, jednotkové testování celého kódu (nejdříve se vytvoří test, až pak samotný kód), programovat jen to, co je v danou chvíli nezbytné, jednoduchý a jasný kód. Mezi další praktiky patří společné vlastnictví kódu a neustálý refaktoring. Vývojáři by měli počítat se změnami požadavků v průběhu času. Důležitá je častá komunikace se zákazníkem i mezi programátory. Příklady dalších agilních metodik Vývoj řízený vlastnostmi (FDD – Feature Driven Development) FDD začíná vytvořením doménového modelu popisujícího celý systém. Ten se převede do seznamu vlastností (elementární funkcionality, které přináší hodnotu uživateli). Vývoj má celkem pět fází (první tři sekvenční, další dvě iterativní). Iterace trvá většinou dva týdny. Během každé iterace se implementují konkrétní užitné vlastnosti systému. Zákazník průběžně dostává mezivýsledky a nové verze produktu. Na rozdíl od XP nebo SCRUM je jednotlivým programátorům práce přidělena – nevybírají si ji sami. Příklady dalších agilních metodik Vývoj řízený testy (TDD – Test Driven Development) TDD navrhuje psaní testů před samotným kódem a následně naprogramovat samotný kód. Implementuje se přesně takové množství kódu, jaké dokáže projít testem. TDD navrhuje psaní testů před samotným kódem a následně naprogramovat samotný kód. Implementuje se přesně takové množství kódu, jaké dokáže projít testem. Příklady dalších agilních metodik Crystal metodiky Nejde jen o jednu metodiku. Hlavní myšlenkou je to, že je lepší metodiku přizpůsobit danému projektu, žádná metodika nebude vyhovovat každému projektu. Vytvoření individuální a účelové metodiky pro konkrétní projekt je první fází vývoje. Pro vytvořenou metodiku je rozhodující například velikost projektu a vývojového týmu. Příklady dalších agilních metodik Lean development Lean development je spíš než metodikou souhrnem pravidel, jejichž používání by mělo zefektivnit a zrychlit vývojový proces. Tato pravidla zní: eliminovat zbytečné (to, co nepřináší zákazníkovi žádnou hodnotu), zdůraznit proces učení, rozhodovat se tak rychle a pozdě, jak je možné, posílit odpovědnost týmu, zabudovat integritu a vidět systém jako celek. SLA (Service Level Agreement) • SLA (Service Level Agreement), používá se zkratka SLA, překládá se jako dohoda o úrovni poskytovaných služeb. SLA představuje formalizovaný popis služby, kterou poskytuje dodavatel zákazníkovi. SLA definuje rozsah, úroveň a kvalitu služby. • SLA v praxi: SLA především definuje klíčové parametry sjednané služby - kvalitu a rozsah. Dále popisuje způsob řešení podpory zákazníků, komunikační kanály mezi zákazníkem a poskytovatelem, způsob řešení výjimečných nebo havarijních stavů, rychlost reakce a odstranění poruchy, stanovení odpovědností za škody, řešení duševních a autorských práv a další. • SLA na míru třeba zde: https://www.legito.cz/servisni-smlouva-sla SLA – OLA - UC Rozdíly v certifikacích PM • PRINCE2 je jako "kuchařská kniha" - řekne Vám, kdo má dělat co a kdy při řízení projektů. • PMI je jako "kuchyňské náčiní" - soubor nástrojů a technik, které Vám pomohou dobře řídit projekty. • IPMA definuje "dobrého šéfkuchaře" - tedy jaké způsobilosti má mít odborník na projektové řízení. Pokud Vaše organizace začíná s PM • PRINCE2 lze využít jako základní standard vzhledem k jeho praktičnosti a přímočarosti • podle potřeby ho doplňovat o nástroje a techniky projektového řízení poskytované standardy PMI nebo IPMA. 7 Principů metodiky PRINCE2 1) Zaměření se na produkt (focus on products) Co má být výstupem projektu a v jaké kvalitě? Ať již jde o produkt, nebo službu – metodika pomáhá realizovat jen takové kroky, které jednoznačně vedou k cíli projektu. 2) Učení se ze zkušeností (learn from experience) Metodika vám pomáhá stále se zlepšovat v dovednostech projektového řízení na základě uplatňování zkušeností z předešlých projektů. 3) Řízení dle výjímek (manage by exception) Definuje tolerance a povolené odchylky projektu od plánovaného cíle. V praxi vás tato zásada ochrání před nekvalitně realizovaným projektem. 7 Principů metodiky PRINCE2 4) Přizpůsobení se projektovému prostředí (tailored to suit the project environment) Pravděpodobně nejsilnější argument, proč využívat flexibilní metodiku PRINCE2. Vyhovuje velkým i malým projektům, v různých prostředích, různé komplexnosti a důležitosti. 5) Kontinuální obchodní zdůvodnění projektu (continued business justification) Každý projekt řízený podle metodiky PRINCE2 má mít své opodstatnění v businessu. Pokud neexistuje opodstatnění, projekt je ukončen. 7 Principů metodiky PRINCE2 6) Řízení dle etap (manage by stages): Životní cyklus projektu má své etapy. Metodika PRINCE2 nejlépe definuje jak projekt plánovat, monitorovat a kontrolovat na základě těchto etap. 7) Definice rolí a odpovědností (defined roles and responsibilities) Úspěch projektu závisí na tom, že každý má jasno o své roli. Jedině tak můžete propojovat obchodní zájmy, cíle projektu s uživateli, dodavateli a dalšími zainteresovanými stranami. S metodikou PRINCE2 máte vždy jasně definovanou organizační strukturu, role i odpovědnosti. 7 Procesů metodiky PRINCE2 1) Zahájení projektu (starting up project) 60 % chyb v rámci projektu má příčinu v přípravě. Naučíte se správně vyhodnotit, zda je projekt životaschopný a realizovatelný. Existují 2 hlavní produkty, které jsou výstupem: Project Brief a Plan. 2) Nastavení projektu (initiating a project) PRINCE2® projekt definuje kritéria pro zvládnutí 6 základních aspektů projektové výkonnosti: čas, náklady, kvalita, rozsah, rizika a přínosy. 3) Směřování projektu (directing a project) Jak na projektové řízení v celém životním cyklu projektu? Směřování projektu se soustředí na rozhodování, odpovědnosti a delegování. 7 Procesů metodiky PRINCE2 4) Kontrola Etapy (controlling stage) Jak úspěšně zvládnout realizaci etapy projektu, reportovat a revidovat odchylky od plánu. Proces popisuje aktivity Project Managera v každá fázi projektu včetně autorizace, revize a reportingu. 5) Řízení přechodu mezi Etapami (managing stage boundaries) profesionální manažer poskytuje nadřízeným relevantní informace o projektu, dosavadní úspěšnosti a dalších plánů, vč. řízení rizik. 7 Procesů metodiky PRINCE2 6) Řízení dodávky produktu (managing product delivery) propojuje role v rámci projektu a definuje jednotlivé činnosti, které jsou podstatné pro realizaci. Proces popisuje úkoly, povinnosti a cíle Team Managera. 7) Ukončení projektu (Closing a Project) jak na předávací, či akceptační protokoly před ukončením? CP zahrnuje veškeré aktivity potřebné k řádnému ukončení a předání projektu. Tento sedmý proces není jen o tom, jak ukončit a předat splněný cíl projektu (popsaných v Project Initiation dokumentaci). Projektový manažer také reportuje budoucí benefity, rizika a požadavky na správu. 7 Témat metodiky PRINCE2 1) Obchodní případ (business case) Argumenty, proč projekt realizovat. Zaměřuje se na náklady, přínosy, rizika a časový plán. Také je posuzována realizovatelnost projektu. Obchodní případ je klíčovým dokumentem, který umožňuje řídit náklady, rizika a očekávané přínosy projektu. 2) Organizace (organisation) napomáhá projektovému manažerovi definovat a nastavit ideální strukturu rolí a odpovědností s jasnou definicí delegování a eskalace. To zahrnuje nejen projektový tým, resp. manažery projektu, ale také dodavatele a uživatele. 7 Témat metodiky PRINCE2 3) Kvalita (quality) Souhrn vlastností, nebo stanovených charakteristik produktu, osoby, procesů, služby a/nebo systému, které mají společně schopnost prokázat, že produkt splňuje očekávání, uspokojuje dané potřeby, požadavky a specifikaci. 4) Plán (plans) Je páteří každého projektu. Obsahuje podrobný návrh pro vytvoření plánu, definuje co, kdy, jak a kým bude realizováno. Metodika PRINCE2 uplatňuje 5 druhů plánů: Projektový Plán, Plán Etapy, Týmový Plán, Plán Realizace Výjimky a Plán Revize Přínosů. 7 Témat metodiky PRINCE2 5) Rizika (risk) Riziko lze definovat jako nejistou událost nebo soubor událostí, které pokud nastanou, budou mít dopad na dosažené cílů projektu. Riziko je měřeno kombinací pravděpodobnosti uvědomění si hrozby nebo příležitosti a závažnosti jeho dopadu na cíle. 6) Změna (change) V každému projektu může nastat požadavek na změnu: uživatel si přeje změnit / upravit požadavky. Neočekávané změny znamenají úpravy. PRINCE2 obsahuje metodický postup řízení změn při zachování stability a bezpečnosti projektu. 7) Vývoj (progress) Téma Progress usnadňuje projektovým manažerům vyhodnocení skutečného průběhu projektu proti tomu, co bylo plánováno. PRINCE2 k tomu využívá Plány (které definují očekávání) vs. zdroje, náklady, čas a další reporty z etap projektu. Monitorováním informací zachycených ve zprávách proti očekávání je projekt manager schopen minimalizovat rozdíly mezi předpokládaným a skutečným pokrokem. Role a odpovědnosti podle PRINCE2 • Projektový manažer (Project Manager) je klíčovou rolí i autoritou v rámci projektu, přestože nemá nejvyšší postavení. • Zodpovídá, deleguje a reportuje aktivity i úkoly v takovém rozsahu pravomocí, které získá od Projektového výboru (Project Board). • Projektový dohled (Project Support) je volitelná funkce, která v rámci projektu nemusí nutně být, ale v některých případech je cenným pomocníkem. • Tuto funkci lze delegovat na projektového manažera. Vždy závisí na odbornosti, velikosti a požadavcích projektu. Role a odpovědnosti podle PRINCE2 • Projektový dohled (Project Assurance) řeší a garantuje závazky dodavatelů, uživatelů a managementu. • Project Assurance musí být nezávislý na roli Projektového manažera. Proč? Projektový dohled nemůže z podstaty své funkce delegovat aktivity na projektového manažera. • Projektový výbor (Project Board) je odpovědný za exekutivní, nebo programové řízení, které je důležité pro strategický rozhodnutí na úrovni cílů projektů. Komunikuje s projektovým týmem a klientem (stakeholderem) projektu. Role a odpovědnosti podle PRINCE2 • Sponzor projektu (Executive) je zodpovědný za projekt v celém životním cyklu. Garantuje, že projekt bude realizován podle schváleného finančního plánu, propojuje požadavky uživatelů, investorů a dodavatelů. • Týmový manažer (Team Manager) garantuje výrobu – dodání produktů v takové kvalitě, harmonogramu a rozpočtu v jakém to požaduje Projektový manažer (kterému se mj. zodpovídá a reportuje). Role a odpovědnosti podle PRINCE2 • Hlavní dodavatel (Senior Supplier) zastupuje zainteresované strany zodpovědné za návrh, vývoj a implementaci projektu / produktu. Zopovídá za kvalitu ze strany dodavatelů a za technickou integritu / kompatibilitu projektu. • Čím je projekt komplexnější, tím více může být Senior Suppliers v rámci jednoho projektu. Vzhledem ke specializacím, požadovaným odborným znalostem s ohledem na rozmanitost dodavatelů.. Role a odpovědnosti podle PRINCE2 • Hlavní uživatel (Senior User) je zodpovědný za specifikaci uživatelských požadavků v rámci realizovaného projektu. Kontroluje zda finální řešení splňuje uživatelské nároky a požadavky odpovídají zadání z pohledu kvality, funkcionalit a uživatelské přístupnosti. • Větší a komplexnější projekty mohou mít v roli Senior Usera i více manažerů. Hlavní uživatel i po ukončení projektu dál zastupuje požadavky na úrovni, programového či uživatelského rozhraní. Role a odpovědnosti podle PRINCE2 • Změnová komise (Change Autority). Projektový výbor může delegovat pravomoc potřebné pro změnové plány, žádosti o změnu a další výjimky na samostatnou skupinu, nebo jednotlivce, kterým je Change Autority. • Projektový manažer může převzít některé pravomoc a kompetence od Změnové komise, což může usnadnit realizaci projektu (např. například Work Packages). Lessons Learned • Lessons Learned (LL) je účinný nástroj, jak zabránit (opakujícím se) chybám pomocí efektivního a cíleného předávání informací a zkušeností nejen ve výrobních oblastech průmyslových podniků. • Proces vychází z principu učit se z vlastních chyb a z vlastních zkušeností. LL je vstupem pro zlepšení a standardizaci, pro další vývoj procesů, metod a předpisů, jako např. analýza možných vad a jejich následků (FMEA), pracovní postupy, proces návrhu výrobků atd. Lessons Learned • Metodika LL je často využívána pro předání informací o příčinách a ověřených a úspěšných nápravných opatření ke známým chybám tak, aby nedocházelo k jejich opakování nejen v rámci daného výrobku, ale také u obdobných pracovních procesů, případně v rámci velkých nadnárodních společností mezi jednotlivými výrobními závody. Použití LL by se nemělo zaměřovat pouze na „negativní" hlediska, je smysluplné zahrnovat také pozitivní případy a příklady. Princip Lessons Learned • Metoda Lessons Learned je založena na principu sdílení znalostí a jejich cíleném předávání. Je důležité uvědomit si, že někdo někde už udělal to, co se snažíme udělat i my. • Znalost lze definovat jako strukturovaný souhrn vzájemně souvisejících poznatků a zkušeností z určité oblasti nebo k nějakému účelu. Získávají se zejména praxí nebo studiem. • Základní kámen pro LL je založen na fungující spolupráci mezi jednotlivými odděleními, resp. závody u nadnárodních společností. Je důležité spolupráci navázat, podporovat a rozvíjet ji. Služby spadající do oblasti podpory spolupráce se zaměřují na zajištění vzájemné komunikace, koordinace a spolupráce. Použití Lessons Learned • Metodika Lessons Learned se neomezuje pouze na výrobní úseky, ale je aplikovatelná na všechna oddělení společnosti. Podstatné je rozhodnout se, o jakou chybu se podělit. Hlavním kritériem pro výběr je poučný potenciál předávané informace pro druhou stranu. Praktické příklady použití LL: • zvláštní případy z pole, zákaznické reklamace, • interní výpadky, • výstupy z analýz/testování vývojových vzorků, • první vzorkování a zprávy z prvního vzorkování. Použití Lessons Learned • Použití LL by se nemělo omezovat pouze na „negativní" případy a hlediska. Je smysluplné zahrnout pozitivní případy (Good Practise), jako jsou například: • trvale nízké (nebo žádné) zákaznické reklamace, • úspěšné projekty snižování nákladů, • hladké náběhy výroby.