Projektování informačních systémů 2 Týmový management projektů Doc. Mgr. Petr Suchánek, Ph.D. Doc. RNDr. Ing. Roman Šperka, Ph.D. Převzato od: Ing. Dominik Vymětal, DrSc. Pojem informační společnost a informace oInformační společnost: n použití technologií zpracování informací ve všech oblastech společenského života oInformace: nV informační společnosti nabývá pojem informace nejvyšší důležitosti, jedná se prakticky o stejnou důležitost jakou mají pojmy čas, prostor, hmota. http://nb.vse.cz/kfil/elogos/miscellany/slapa103.pdf > Řízení procesů a projektů oŘízení procesů: nsnaha o optimalizaci průběhu vnitropodnikových činností npoužití nejlepších praktik nučení se ze zkušenosti na projektech oProjekt: proces plánování a řízení rozsáhlých operací. Projekt NENÍ „projektová dokumentace“ oObecně jej lze charakterizovat: nmá počátek a konec nmá jasně stanovený cíl nZpravidla se vyznačuje omezenými zdroji a určitým stupněm rizika nprojekt není periodicky se opakující práce, nemívá vzor v minulosti o > Projektové organizační struktury oProjektový management má za cíl zabezpečení realizace projektu – tedy řízení jedinečných, zpravidla neopakovatelných , časově i zdrojově limitovaných činností, které vedou k dosažení stanovených cílů. o > Typy projektových organizačních struktur oČistý o > Typy projektových organizačních struktur oÚtvarový o > Typy projektových organizačních struktur oMaticový o > Zvláštnosti projektů IS oBez ohledu na rozsah jsou vždy komplexní oVždy obsahují složku Hardware a Software –projektový tým musí mít rozsáhlé znalosti z IT oVždy obsahují organizační složku – v projektovém týmu musí být i koneční uživatelé oMá vždy tendenci se zpožďovat oZnamená změnu pro uživatele – je vždy po zavedení kritizován oNáklady mají tendenci nekontrolovaně růst oDodavatelé mají tendenci zmenšovat dohodnutý obsah dodávky, odběratelé mají tendenci měnit své požadavky oPro dodavatele i odběratele obsahují rizika, se kterými je nutno předem počítat Metody tvorby a projektování IS oVodopád nÚplná projektová dokumentace na začátku, přesně daný postup oSpirála nZavedení určitých iteračních cyklů oPrototypování nPříprava prototypů, jejich úprava po diskuzi s uživatelem oAgilní metodiky n > Vodopád a spirála oVodopád nVýhody – přesné stanovení projektového plánu vede k jasné smlouvě s dodavatelem nNevýhody – údržba projektové dokumentace velmi náročná, při změnách degraduje, vícenáklady oSpirála nVýhody –určité iterace umožňují lepší komunikaci s uživateli i dodavatelem oJednodušší cenové jednání oVýsledný produkt se blíží představám odběratele nNevýhody – podobné jako u vodopádu n > Fáze vývoje systému oStanovení informační strategie a architektury oAnalýza potřeb (procesy, objekty,data) oNávrh (Cílový koncept řešení) oRealizace modulů, prototypová fáze, agilní fáze (závisí od přijaté strategie zavedení) IS) oStanovení zásad migrace dat oLadění modulů, prototypů, orchestrace oTechnická realizace oSouhrnný test a příprava dokumentace oŠkolení uživatelů oInstalace, akceptační test > Psychologické aspekty a management IS projektů oNový IS = změna opostoj uživatele: nco mi to přinese njak to ohrozí moji práci nstrach ze změny a vícepráce na začátku njaké mi to dá šance oÚloha managera projektu: nrozptýlit obavy a ukázat pozitiva a šance oJak: nefektivní komunikace ndobrá organizace školení nvyužití Power Users > Zajištění kvality projektu okvalita je jedním z rizikových faktorů (viz trojúhelník náklady – termíny – kvalita) ozákladním prvkem je smlouva s dodavatelem npožadované funkce a jejich specifikace ntermíny nzáruky nproces řízení změn v projektu nkriteria kontroly kvality > Metody řízení kvality projektu opravidelný sběr informací o stavu projektu o„ruční“ vyhodnocování je možné jen pro malé projekty oautomatizované sledování (např. MS Project) ntermíny a funkce nsledování kritické cesty nsledování vytíženosti zdrojů otaktiky jednání při zjištění problémů nkonsensuální : je vždy výhodné pro udržení týmu nkonfliktní : v případě opakovaných problémů n > Týmový management – základní pojmy oProjektová hierarchie – postavení jednotlivých členů v projektové organizační struktuře oDozor – (projektový dozor, steering board) – má dohled nad projektem a provádí stěžejní rozhodnutí oExpertní tým – často externí poradci, poradní orgán vrcholového managementu, vyhodnocuje efektivnost a kvalitu projektu oManažér projektu – je plně zodpovědný za management projektu a dosažení cílů oVedoucí projektové skupiny ( dílčího projektu) oKmenový projektový tým – podílí se na formulaci výchozích požadavků a cílů ( u IS projektů zpravidla zástupci uživatelů) Hierarchie v projektu oUrčuje vzájemné vztahy nadřízenosti a podřízenosti pracovníků podílejících se na projektových pracích oStruktura hierarchie je vždy ovlivněna potřebou a charakterem požadovaných znalostí oU IS je to vždy smíšená struktura a hierarchie pracovníků IT a uživatelů, kdy zejména na počátku mají převažovat odborné znalosti v oblastech zavedení (změn) IS Typické organizační schéma IS projektu > Hlavní role v projektu IS Odběratel Dodavatel Vlastník projektu (vedoucí organizace, nebo člen vedení) Vedoucí projektu Řídící výbor Konzultant Vedoucí projektu Programátor Vedoucí dílčího projektu Technický specialista systémového software Člen projektového týmu Technický specialista hardware Případný externí expert Technický specialista sítí Případný asistent vedoucího projektu aj. Popřípadě specialista pro školení uživatele > Řídící výbor ( dozor) oDefinuje: nStrategii vedoucí k dosažení cílů projektu nPriority nPravomoci oSleduje: nPostup prací na projektu nPrůběh nákladů oRozhoduje o: nAlokaci zdrojů požadovaných manažérem projektu nZměnách oproti definici funkcí a prací na projektu Vedoucí projektu oPlánovač, koordinátor, organizátor, kontrolor , vyjednavač a Vůdce oJe zodpovědný za výběr členů projektového týmu oŘídí a koordinuje dílčí projekty oZodpovídá zejména za: nŘízení realizace postupu prací nIdentifikaci odchylek od plánů a realizaci nápravných opatření nPoskytování informací o průběhu projektu nFormulování a předkládání požadavků nad rámec jeho povinností (u IS kritická úloha) nSledování a vyhodnocování nákladů vzhledem k rozpočtu nVytváření potřebných pracovních kontaktů na všech úrovních řízení nMarketing projektu Vedoucí projektu Cíle role Splnit cíle projektu a jeho souvislosti Kompetence Schopnost vést projekty, znalost organizace podniku, znalost řešené problematiky, znalost IT Osobnostní typ Komunikátor a vůdce Počet osob Jedna až dvě Co není cílem Zdroj, odkud jej vzít Podnikový manažerský tým, případně externista Zdroj: Gareis Práce na obsahu projektu nebo jeho části Účinnost týmové komunikace oJe úlohou vedoucího projektu oPotřebné vlastnosti vedoucího projektu: nSchopný komunikátor nAktivní komunikátor nTvůrce komunikačního prostředí nEfektivní koordinátor (moderátor) pracovních porad a diskuzí oKomunikační past u IS projektů: informatici versus uživatelé / vedení oOsvědčené postupy: nNaslouchání, zpracování, třídění a filtrování informací nÚčinná motivace (pochvala, osobní pozornost, provokace profesionální pýchy členů týmu…) nOtevřené a neutrální řízení konfliktů o Zodpovědnosti vedoucího projektu IS oU odběratele nProjednávání souladu cílů projektu IS s vrcholovým vedením nKoordinaci a alokaci klíčových uživatelů v etapě návrhu systému nKoordinaci posouzení návrhu nového systému ve firmě nKoordinaci dílčích projektových týmů s IT týmem v období realizace nNávrh a dodržení časového harmonogramu přechodu na nový systém nEfektivní řízení požadavků na změny dodatečné funkce IS nCenová vyjednávání s dodavatelem v etapě realizace projektu a jeho změn oU dodavatele nOrganizaci analýzy a návrhu systému včetně dokumentace nAlokaci zdrojů dodavatele dle etap a potřeb realizace IS nKoordinaci subdodavatelů nVýkaznictví o provedených pracích nOdhady spotřeby času a důsledků při požadovaných změnách nTermíny a náklady dodávek dílčích částí dle projektového časového plánu a rozpočtu o n Styly vedení týmu v IT projektech oVliv na styl vedení má: nvnitrofiremní kultura nosobnostní charakteristika vedoucího projektu ntyp projektu oStyly: nautoritativní (častěji u dodavatelů než u odběratelů) oPři kratších projektech s časovým rizikem oPři problémech v projektu (zpravidla po výměně vedoucího) ndemokratický s výraznou delegací pravomocí oPři projektech s výraznou potřebou inovace a motivace ntechnokratický oZpravidla u obnov HW nebo sítí, vytváří problémy u koncových uživatelů Vyjednávání oKlíčová schopnost vedoucího IT projektu oProblém: každá organizace má tendenci odmítat změny oZástupné problémy: nVícepráce po zavedení, nové funkce dávají méně než staré, chyby, „s tím nedosáhneme plánované ukazatele …“ oPožadované vlastnosti: nRozhodnost, otevřenost, schopnost formulovat požadavky nebo jejich shrnutí, schopnost dosažení konsensu oTypy manažérů IT projektů z hlediska odborných kompetencí nOdborník na IT - vhodný zpravidla pro menší projekty s výraznou převahou techniky ( zavedení LAN, WAN, úpravy existujících programů …) nPlánovač a koordinátor – vhodný zpravidla pro větší projekty s výraznou potřebou komunikace. Nemusí mít specializované znalosti IT oV poslední době se spíše prosazují koordinátoři a komunikátoři Zdroje síly vedoucího dle Svozilové oZákladní síla nMoc z titulu pozice oOprávnění k udělení odměny nMoc podpořená možností přidělit pozitivní finanční nebo nefinanční zvýhodnění oOprávnění k uložení pokuty oSíla experta nČlenové týmu respektují úroveň znalostí, zkušeností a schopností oSíla společenského uznání nJe založena na přirozené autoritě (charizma), obdivu a respektu Nastavení řídících procesů v projektu opravidelné porady nvedení projektu nprojektového týmu ovytvoření a vedení informační základny projektu nplán realizace (funkce termíny, zdroje) nvedení dokonalé dokumentace průběhu projektu je základem řízení projektu okomunikace nkomunikační strategie a taktika (kdy a proč, s kým a o čem) nstanovení komunikačních prostředků a cest (dopisy, maily, memoranda, intranet, ….) njak reagovat na informace zpětné vazby ovolba správného manažerského stylu řízení projektu Projektový tým oDočasná organizační struktura, která má tvar dle cíle projektu oOptimální velikost – co nejmenší oJednoznačné chápání cílů oZávazek (commitment) a spoluzodpovědnost za dosahované výsledky oPast špičkových odborníků – nemají zpravidla čas oVhodná kombinace IT pracovníků a uživatelů – vysoká heterogennost znalostí a časových možností oPast „strategických členů“ (jsou v týmu aby neškodili při zavádění – častý problém v IS projektech) o Projektový tým Cíle role Dosáhnout koordinace a synergické efekty v projektu, řešit konflikty mezi dílčími týmy, připravit, projednat a schválit celkový koncept a prováděcí projekt IS, organizovat školení uživatelů, zajistit komplexní testy Důležitost pro projekt Zásadní, jen správně fungující projektový tým zajistí úspěch projektu Osobnostní typy Týmoví hráči, individualisté jsou spíše překážkou Počet osob Podle počtu dílčích týmů Co není cílem Řešit obsah řešení jednotlivých problémových oblastí Zdroj, odkud vzít členy týmu Budoucí klíčoví uživatelé jednotlivých problémových oblastí, jeden až dva specialisté IT, vedoucí projektového týmu dodavatele Zdroj: Gareis > NAVISION: Projektorganisation Lenkungsausschuss J. Bischof - KM K. Orthaber - KM W. Abel - stratCON R. Weitersberger - MBS Projektleitung R. Kaltenberger-Löffler - KM D. Vymetal (Stv.) - KM H. Lahodny - MBS Quality Assurance W. Abel – stratCON W. Bartholner - stratCON H. Schuecker - KM Direct Sales R. Zierler (TPL) - KM M. Aichhorn (Stv.) - KM M. Dvoracek - KM C. Körber (IT) – KM M. Heindl (IT) - KM W. Abel - stratCON R. Mayr - MBS Service E. Herney (TPL) - KM J. Sturm (Stv.) – KM E. Krigovsky – KM G. Burgstaller - KM K. Wriessnegger - KM R. Zierler - KM M. Fettinger (IT) - KM W. Abel - stratCON D. Schuch - MBS Logistics & Material Management/Purchase T. Novak (TPL) - KM M. Steffen (Stv.) - KM H. Pfaller - KM M. Fettinger (IT) - KM W. Bartholner - stratCON R. Mayr - MBS Finance Ch. Resch (TPL) - KM M. Dvoracek (Stv.) - KM J. Durna (IT) - KM W. Bartholner - stratCON R. Gegenhuber – MBS Controlling Ch. Resch (TPL) - KM H. Schuecker (Stv.) - KM S. Aman - KM J. Durna (IT) - KM W. Bartholner - stratCON R. Gegenhuber - MBS Infrastructure & Interfaces J. Durna (TPL) - KM C. Körber (Stv.) – KM W. Mazanec - KM W. Abel - stratCON T. Wachmann - MBS Projektsekretariat E. Riebel - KM Dealer Sales G. Brunner (TPL) - KM D. Obmann (Stv.) – KM M. Dvoracek – KM J. Durna (IT) – KM W. Abel – stratCON R. Mayr - MBS Human Resources A. Berger (TPL) - KM B. Mazanec (Stv.) – KM Ch. Resch – KM E. Distl (IT) - KM W. Bartholner – stratCon R. Gegenhuber - MBS Version 5 Stand: 1. 6. 2005 Erstellt: R. Kaltenberger-Löffler Data Warehouse D. Vymetal (TPL) – KM H. Schuecker (Stv.) - KM Ch. Resch – KM J. Sturm - KM J. Durna – KM W. Abel - stratCON H. Lahodny - MBS Člen projektového týmu Cíle role Splnit cíle projektu v zadané problémové oblasti, zajistit transfer svých znalostí do projektu. Kompetence Kompetence a zkušenost v řešené problémové oblasti., vhodná je alespoň základní znalost IT Osobnostní typ Týmový hráč Počet osob Více osob může plnit tuto roli pro danou problémovou oblast a vytvořit tak dílčí projektový tým. Co není cílem Vyprofilovat se u ostatních jako jediný expert na danou problematiku Zdroj, odkud jej vzít Interní podnikové útvary Zdroj: Gareis > Projektová jednání (typy a charakteristiky) oKick-off meeting nCíle projektu, commitment vedení, základní pravidla komunikace, hlavní milníky projektu oJednání projektového týmu nVarianty řešení, změnová řízení, nIntegrace dílčích částí nKoordinace pro příští období nKontrola stavu projektu oKontrola stavu projektu (Steering board meeting) nStav postupu prací nStav nákladů nNávrhy na závažná rozhodnutí pro kompenzaci odchylek, nNávrhy změn mající dopad na rozpočet nebo termín projektu Projektová jednání II oJednání dílčích týmů nPráce na řešení dílčích problémů oTypicky: otázky Hardware, příprava testovacích variant, řešení návrhů z jiných dílčích týmů …. nBrainstorming, varianty řešení nNávrhy změn v dílčích oblastech oPast schůzek jako žroutů času při: nPodcenění přípravy jednání nAbsenci podkladů nNedodržení programu nNedostatečné moderaci a kázni členů týmu nMíchání témat, která mají být řešena od témat, která mají být rozhodnuta nNedostatečné dokumentaci z minulých jednání Věcná rizika v týmech IS projektů oProjekty IS zpravidla mají v projektových týmech členy na částečný úvazek (výjimka – pracovníci IT) oRizika částečných úvazků: nSoudržnost týmu - ti co pracují částečně nebo občas v týmu se těžko sžívají se zbytkem a nedrží krok s projektem (chybí informace) nHlavní pracovní náplň je vždy v konfliktu s prací v týmu nZpravidla dva nadřízení – priority chování v neprospěch projektu oRiziko ztráty souvislostí nPokud se v rámci projektové porady začne prosazovat odborná IT hantýrka, mohou se další členové týmu „odpojit“ a ztratit kontakt s problematikou – v dalších krocích v projektu vzniká problém n„baviči“ – jasná chyba vedoucího projektu oRiziko kompetencí a zodpovědnosti IT nZařizuje úkol odborný útvar nebo IT ? ( „na co máme IT“) n Komunikace, diskuze a sdílení idejí v projektu oNástroj budování týmu nDiskuze o možnosti plnění zadání s danými zdroji a v daném čase nBudování a tvorba závazku minimálně klíčových členů týmu oMusí vycházet z jednoznačné definice očekávaných výsledků nPopis vzhledem k výsledku nikoli popis činností nNástroj budování týmového očekávání cíle oProstředek pro dobrovolné přijetí závazku k projektu nÚčast na plánování, sdílení idejí, úspěchu i neúspěchu Přijetí závazku k projektu oPřijetí rozsahu zodpovědnosti nPopis úkolu a cíle nDefinice řetězce hlášení o projektu nDefinice rozsahu delegované autority oPřijetí osobního závazku nPotvrzení, že pracovník porozuměl zadanému úkolu nSouhlas s plánovaným rozsahem a časovým obdobím projektu oForma: nPověření nPotvrzení manažérem projektu a liniovým manažérem nResp. Matice zodpovědností Skupinové chování a jeho rizika oNa skupinové chování v týmu má vliv firemní kultura a vůdčí schopnosti manažéra projektu. oChování a klima ve skupině ovlivňuje „průměrný „ výkon týmu. oRizika skupinového myšlení nAgresivnější členové prosazují své názory (klesá ochota k variantním řešením) nRiziko „osvíceného jedince“ – může mít pravdu ale neprosadí se – demotivace – často jde o IT guru nRizika dominantních členů týmu nMálo alternativ – menší identifikace členů s řešením nIluze jednomyslnosti týmu Nejistoty členů týmu oZvlášť výrazně se projevují v projektech IS oHlavní otázky / nejistoty: nPro koho budu pracovat nJaká bude moje role nJaké budu mít pravomoci a zodpovědnosti nKdo bude mým nadřízeným / vztah k současnému nadřízenému nBude to pro mne mít pozitivní přínos nJak dlouho projekt potrvá nS kým budu spolupracovat nCo bude s mým původním místem nJak se na to dívá můj současný šéf nZvládnu to , co na to rodina oChci to skutečně dělat??? Základní chyby komunikace dle Dolanského a kol. oZdroj nNepřesné vyjadřování nNepřipravenost na jednání nNejistý projev nKomplikované a dlouhé monology (specialita IT guru) nVyhýbavé odpovědi n Přehnaná kritika, odsuzování nPodceňování schopností příjemce informace nNepřipuštění vlastních chyb nNezájem o problémy druhých oPříjemce nNedostatečná soustředěnost nZaměřenost na detaily nNeochota přijmou jiný názor nNízká úroveň znalostí dané problematiky nPoužívání neověřených informací jako protiargumenty nPostranní kritika n n Řízení e-mailové komunikace oE-mail může být v projektu past nPříliš mnoho mailů – nikdo je pak nečte nRozdělovníky: informace tomu kdo je potřebuje nŠpatná formulace – demotivace týmu nebo uživatelů oNastavení a tipy ke zvýšení účinnosti nZaškolení všech členů týmu do pravidel používání nRozdělovníky dostatečně strukturovat nMaily co nejkratší nPřílohy skladovat centralizovaně nOdstupňování priorit nPotvrzení o přečtení dobře uvážit nSdělení o nepřítomnosti – bezpodmínečná nutnost nŽádné emotivní komunikace v e-mailovém provoze Časté konflikty v týmu IS projektu oUvnitř dodavatele nNedostatek času nKoordinace dílčích řešení není dostatečná nPřekročení nákladů oUvnitř odběratele nNedostatek času na projekt (další úkoly) nNeuvolnění člena týmu liniovým šéfem nCíle podniku se liší od dílčích cílů uvnitř nebo cílů projektu oMezi členy za dodavatele a odběratele nNedostatečný vzájemný soulad a spolupráce („chemie“) nCo je a co není v kontraktu (zejména u pevné ceny) nDodavatel nás nebere dostatečně vážně nSubdodavatelé nefungují – odběratel je kontaktuje přímo Konflikty po nasazení IS oKoncoví uživatelé nšpatné zaškolení – chyby a stížnosti nvýkonnost systému – vícepráce, nedodržení termínů, stížnosti nzměna stylu práce – hledání zástupných problémů oVedení firmy nchybí některé starší sestavy – „let naslepo“ ndodatečné náklady při plnění dodatečných požadavků nvýmluvy nižšího managementu (obrat, náklady, vícepráce …) n„nesplněné sliby“ – vše na stisknutí tlačítka?? oDodavatel n„toto nebylo ve smlouvě“ n„toto nepatří do záruky“ n„uživatelé si nepamatují, co jsme je školili“ n„máme hot line, nevolejte našim programátorům“ n„dodali jsme více než jste zaplatili“ n„naši subdodavatelé nám neplatí“ n„naši subdodavatelé jsou neschopní“ Hotline a její role v první fázi po nasazení oNahlášení problémů a chyb. oDispečer Hotline analyzuje tickety a přiděluje jejich řešení odpovídajícím osobám. oZodpovědný řešitel řeší problém, uvědomuje o řešení dispečera. Systém automaticky registruje datum a čas vyřešení s tím, že také uživatel dostává informaci buď přímo nebo od dispečera Hotline. oRealizací těchto základních funkcí vzniká možnost nStrukturovaného popisu problému. nJe možno sledovat statistiku podle jednotlivých uživatelů. nStatistiku je možno použít pro účely záruky a jednání s dodavatelem. nV případě konfliktů na úrovni dodavatelů nebo managementu, jsou k dispozici údaje pro statistiku vyhodnocující rychlost reakce dodavatele, rychlost reakce dispečera, statistiku slabých míst s návrhem případných změn a další účely. > Helpdesk OPF > Helpdesk OPF II > Motivace oMotivace – součást „měkkých“ metod řízení oVedoucí projektu musí být schopen vyvolat v členech týmu touhu účastnit se na úspěšném provedení projektu oMotivace na projektu v oblasti IS závisí: nna firemní kultuře a stylu řízení npostoji vedení k projektu nsprávném vedení projektu včetně kvality dodavatele nrealistickém plánu projektu a zdrojů nna stylu motivace (pozitivní a negativní motivace) nna podmínkách pro členy projektu nosobních vlastnostech vedoucího projektu (motivace a manipulace, spolehlivost …) nna schopnosti členů týmu orientovat se v problematice Riziko času a motivace týmu oVýkon týmu je dán výkonem nejslabšího článku oVýkon závisí od schopností a motivace oSama motivace se dá stimulovat oStimulace je ovlivněna osobními preferencemi oČas má vliv na úroveň motivace (dlouhý projekt, odložení termínů, nesplnění závazků dodavatele,…) a tím i na výkonnost oV určitém kritickém momentu přestává stimulace fungovat (preference odpočinku , syndrom vyhoření, předem zaplacená dovolená…) Příklad motivačních problémů v důsledku zpoždění IT projektu 1 1.11.2004 Kickoff 2 31.5.2005 Projekt IS 3 31.8.2005 Projekt přijat 4 15.10.2005 první posun termínu 5 31.12.2005 druhý posun termínu 6 31.1.2006 integrační testy 7 31.3.2006 start povolen 8 30.6.2006 1.kvartální závěrka > Děkuji za pozornost. Otázky?