Úvod
projekty jsou často prostředkem k operacionalizaci strategických plánů organizace. Předpokládá se, že projekty budou vyvíjet produkty a služby a získávat provozní efektivitu. Podnikání se stále více promítá a globální výdaje na projekty se pohybují v řádu mnoha miliard dolarů ročně (Williams, 2005). Důvody jsou zřejmé. Projekty poskytují příležitost využít postupy řízení projektů, které podporují efektivní a efektivní využívání zdrojů. Navzdory pokroku v disciplíně a profesi projektového řízení však společná zkušenost naznačuje, že mnoho projektů selže (Williams, 2005), což podtrhuje význam a potřebu zlepšit procesy a výkon projektového řízení.
obecně se organizace snaží implementovat osvědčené postupy tradičního řízení projektů-založené na standardech PMI-za účelem dosažení cílů projektu a splnění očekávání zákazníků. Ne všechny doporučené postupy a postupy znalostního orgánu pro řízení projektů (PMBOK® Guide) však mohou být relevantní pro každý projekt. Selektivní přístup má často smysl při přijímání procesů a postupů řízení projektů tak, aby vyhovovaly specifickým potřebám projektu na základě jeho velikosti, typu, složitosti a odvětví, ve kterém je projekt prováděn. Taková potřeba odlišného přístupu k řízení IT projektů je dobře zdokumentována v literatuře o řízení projektů.
projekty vývoje softwaru často čelí protichůdným výzvám vývoje softwarových produktů zrychleným tempem a zároveň je vyvíjejí s robustností, aby byly spolehlivé (Boehm, 2002). IT projekty, jejichž cílem je držet krok s rychle se měnícím technologickým vývojem, často procházejí změnami rozsahu během fáze plánování a implementace. V důsledku toho mají IT projekty výzvy, které se liší od tradičních projektů. Pro IT projekty se vyvíjí a praktikuje několik úprav a úprav tradičních postupů řízení projektů, čímž se zavádějí nové metodiky řízení projektů, jako je agilní řízení projektů.
agilní metodika řízení projektů—s větší přizpůsobivostí často se měnícímu rozsahu-využívá iterativní nebo fázové plánování a kontinuální integraci. Klíčovým principem je udržet rozsah projektu měkký. Metodika podporuje spolupráci a vede ke zvýšení spokojenosti zákazníků. Agile však není kompletní řešení pro vývoj softwaru rychlým tempem a zároveň splňuje požadavky zákazníka na robustnost a spolehlivost. V této souvislosti Boehm (2002) doporučil kombinaci tradičního řízení projektů a agilní metodiky vývoje softwaru, která je proveditelná a výhodnější. Doplňkovým přístupem by bylo vyvinout přístup založený na rizicích, který je přizpůsoben tak, aby si zachoval výhody agilních i plánovaných metod a současně zmírnil mnoho jejich slabostí (Boehm & Turner, 2003).
tato výzkumná práce si klade za cíl prozkoumat výše uvedené návrhy (Boehm, 2002; Boehm & Turner, 2003)kombinovaného přístupu k řízení IT konzultačních projektů, které se liší od IT projektů. IT konzultační projekty jsou koncipovány tak, aby řídily a poskytovaly projektovou podporu IT projektům. Často jsou iniciovány ve vládním sektoru. IT konzultační projekty nejsou projekty vývoje softwaru; spíše poskytují projektovou podporu IT projektům.
v této studii se snažíme rozvíjet pochopení toho, jak agilní postupy řízení projektů jsou relevantní pro IT konzultační projekty. Cílem studie je identifikovat výhody používání agilního řízení projektů, jeho vhodnost a jaké aspekty tradičního řízení projektů lze kombinovat s agilním řízením projektů pro IT konzultační projekty ke zlepšení výkonu projektu. V další části, s využitím rozsáhlého literárního přehledu metodiky agilního řízení projektů, jsme identifikovali hlavní rysy agilní metody a jejich jedinečný přístup k řízení projektů ve srovnání s tradičním řízením projektů. Přehled literatury pomohl rozvinout pochopení klíčových konceptů a výhod používání agilního vývoje softwaru. Dále, na základě zjištění z přehledu literatury, vyvinuli jsme a představili výzkumnou metodu využívající strukturovaný dotazník k rozvoji porozumění it poradenským projektům. Analýza a diskuse dat, prezentovány následně, poskytují důležité poznatky a zjištění studie. Článek uzavíráme našimi výzkumnými poznatky a doporučeními pro IT konzultační projekty.
Přehled literatury
tradiční postupy řízení projektů, které jsou řízeny komplexním plánováním, lze použít, pokud jsou jasně definovány specifikace projektu. Na druhou stranu, pokud SPECIFIKACE podléhají častým změnám během životnosti projektu, tradiční přístup k řízení projektů nemusí fungovat efektivně. Projekty vývoje softwaru jsou často koncipovány s minimálními specifikacemi, což způsobuje časté změny těchto specifikací během implementace projektu. Dále, doba vývoje softwarových projektů je krátká. Agilní metody jsou ve srovnání s tradičními technikami řízení projektů vhodné pro projekty vývoje softwaru kvůli krátkému trvání vývoje těchto projektů (Hanakawa & Okura, 2004).
obecně platí, že různé metody vývoje softwaru, jako je agilní řízení projektů, slibují zvýšenou spokojenost zákazníků, nižší míru závad, rychlejší časy vývoje a slouží jako řešení rychle se měnících požadavků projektu (Boehm & Turner, 2003). Na rozdíl od agilního řízení projektů používá model stage-gate pracovní proces od koncepčního nápadu k produktu, který je nakonec dodán. Tento model vyvíjí fáze životního cyklu řízení projektů založené na různých fázích vývoje produktů pro řízení projektů. Důležitým rozdílem mezi modelem stage-gate a agilním řízením projektů je to, že první pokusy minimalizovat změny požadavků tak, aby byl produkt dokončen včas (Karistrom & Runeson, 2005). Další metodou pro vývoj softwaru je SCRUM, což je soubor principů řízení projektů využívajících malé mezifunkční a samosprávné týmy (Schatz & Abdelshafi, 2005). SCRUM vyžaduje, aby každý člen týmu a majitel produktu spolupracovali na začátku každé vývojové položky a metodika funguje jako obal kolem stávajících vývojových procesů. Schatz a Abdelshafi proto tvrdili, že SCRUM nebude mít základní plán pro měření úspěchu projektu. Agilní řízení projektů je však pro tuto studii zvažováno kvůli jeho větší flexibilitě a přizpůsobivosti projektům vývoje softwaru.
kromě výše uvedených výhod je agilní metodika použitelná i pro turbulentní a neustále se měnící prostředí (Highsmith & Cockburn, 2001). Agilní metoda dále zdůrazňuje přizpůsobivost trhu, technologii a procesu (Mellor, 2005). Agilní metodika je přístup, který se nejprve zaměří na důležité funkce a v důsledku toho bude hledat včasnou zpětnou vazbu na funkce (Karistrom & Runeson, 2005). Jakmile jsou identifikovány důležité funkce, projektový manažer zajistí, že nedojde ke zpoždění. Karistrom a Runeson naznačily, že agilní proces zabrání napěchování zdrojů, pevných plánů a podpory dlouhodobých plánů.
agilní metodika však není vhodná pro všechny projekty vývoje softwaru. S odvoláním na Scotta Amblera, vývojáře agilní metody, Boehm (2002) doporučil tradiční metodiku řízení projektů založenou na plánu pro zajišťovací software, jako jsou systémy kritické pro život.
agilní metoda, díky náročnému projektovému prostředí charakterizovanému chaosem a nejistotou, potřebuje projektové týmy složené z talentovaných lidí, aby uspokojily náročné potřeby a požadavky. Citovat výzkumnou studii Constantine (2001), Boehm (2002) navrhl, že agilní metody vyžadují vysoce schopné lidi. Agile není dále vhodný pro větší týmy (Highsmith & Cockburn, 2001), protože k úspěchu vyžaduje úzce koordinovanou týmovou práci a týmy s více než 15 nebo 20 vývojáři zvyšují obtížnost řízení projektu (Constantine, 2001).
je zřejmé, že agilní metoda využívá koherentní týmy (Karistrom & Runeson, 2005). Karistrom a Runeson identifikovaly další agilní funkce, jako jsou malé a zvládnutelné úkoly, nepřetržitá integrace a automatické testování. V důsledku toho se agilní projektové týmy vyznačují dobrou interní komunikací, vyšší kvalitou a pocitem kontroly (Karistrom & Runeson). Počítají však s možnou izolací agilního týmu.
pokud jde o komunikaci, řízení pokroku na základě dokumentů a kontrolu kvality, běžná praxe v tradičním řízení projektů neodpovídá metodě agilního vývoje softwaru (Hanakawa & Okura, 2004). V agilních metodikách je obvykle preferována interakce tváří v tvář pro neustálé přeskupování rozvojových cílů (Mělník & Mauer, 2004). Melnik a Mauer zdůraznili rozdíl mezi tradičními a agilními metodami a navrhli, že při vývoji softwaru je upřednostňován krátký přenos znalostí a přímá komunikace a spolupráce, na rozdíl od tradičních postupů řízení projektů, kde se používají dlouhé řetězce přenosu znalostí, které jsou často náchylné ke zkreslení a ztrátě informací.
jedním z důležitých rozdílů mezi tradičními postupy řízení projektů řízenými plánem a agilními metodami je to, že agilní metody zachycují agilitu spíše z tichých znalostí projektového týmu než explicitních znalostí, často používaných ve formě dokumentů a plánů v tradičním řízení projektů (Boehm, 2002).
dalším rozdílem je množství a typ dokumentace vytvořené pro projekty. Tradiční projektové řízení založené na plánu klade důraz na podrobné plánování, monitorování a kontrolu dokumentů. Zdůvodnění návrhu, dokumenty, které vyjadřují důvody a zdůvodnění, jsou vytvářeny pomocí vysoce automatizovaného postupu a tyto zdůvodnění návrhu slouží jako agilní dokumentace (Sauer, 2003).
Coram a Bohner (2005) identifikovali společné rysy agilní metody: spolupráce, malé týmy, krátké plány vydání, časový Box a neustálé testování. Projektový manažer je zodpovědný za zajištění vysoce kolaborativního prostředí. Za tímto účelem agilní metoda podporuje malé týmy a několik dílčích týmů na projekt, aby podpořily spolupráci. V důsledku toho bude agilní metoda pravděpodobně vyžadovat méně procesů a plánování pro koordinaci týmových aktivit. Agilní metoda také používá krátké plány vydání, které se mohou lišit od dvou týdnů do šesti měsíců. Time boxing je koncept, který ukládá pevnou dobu pro vydání výstupů projektu, což pomáhá snížit zlacení a rozsah tečení. Neustálé testování zajišťuje kvalitu produktu a integraci. Coram a Bohner dále navrhli, že projektoví manažeři musí sledovat pokrok a činit obchodní rozhodnutí s důrazem na reakci na změnu, nikoli na dodržování konkrétního plánu.
Time boxing vede k nepředvídatelnému plánování podle nejlepšího odhadu a pevná data by mohla přinést nečekaná překvapení během vývojové fáze (Patton, 2003). Dalším výsledkem tohoto iterativního procesu plánování projektů je to, že agilní metoda nemůže sledovat pokrok založený na procentech (Patton, 2003).
zapojení malých dílčích týmů do plánování bude mít za následek motivované inženýry vývoje softwaru; technické problémy jsou vzneseny brzy v projektu a při implementaci bude malý odpor (Karistrom & Runeson, 2005). Kromě toho by definování rozsahu projektu agilním přístupem vedlo ke snížení nákladů (Mcgovern, 2002). Agilní metoda využívá plánování založené na požadavcích a také nám umožní řídit rozsah (McGovern).
s využitím všech dosavadních referencí a diskusí a dalších (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), Tabulka 1 poskytuje souhrnné srovnání mezi tradičními a agilními postupy řízení projektů.
Tabulka 1: Srovnání agilního a tradičního řízení projektů
| fáze projektu | tradiční | agilní |
| zahájení |
|
|
| plánování |
|
|
| Execution |
|
|
| monitorování a kontrola |
|
|
| uzavření |
|
|
shrnutí přehledu literatury
metodika agilního řízení projektů se běžně používá pro projekty vývoje softwaru. Má větší přizpůsobivost často se měnícímu rozsahu. V důsledku toho agilní řízení projektů využívá iterativní nebo fázové plánování a nepřetržitou integraci po celou dobu trvání projektu. Klíčovým principem agilního řízení projektů je udržet rozsah projektu měkký. Agilní metoda řízení projektů se liší od tradiční metody řízení projektů tím, že přiřazuje důležitost faktorům, které jsou tradičně považovány za nedůležité. Agile přiřazuje relativně vyšší význam:
- jednotlivci a interakce nad procesy a nástroji
- realizace projektu Nad komplexní dokumentací
- spolupráce zákazníků nad vyjednáváním o smlouvě
- reakce na změnu plánu projektu
agilní metoda zdůrazňuje flexibilitu při uspokojování potřeb projektu. Dále se spoléhá na zpětnou vazbu od zákazníků k zahájení změn v plánu projektu. Metodika využívá přístup identifikace vhodných koncových uživatelů a jejich cílů k formulování výstupů projektu a k uspokojení prováděcích potřeb obchodních procesů. Mezi výhody použití agilní metody patří zvýšená spokojenost zákazníků, nižší míra defektů a rychlejší doba vývoje. Agilní metoda je navíc odpovědí na rychle se měnící požadavky, protože využívá včasnou zpětnou vazbu o technologických vlastnostech výstupů projektu. Agilní metoda zajišťuje, že požadavky nejsou přeplněné. Klíčovými rysy agilní metody jsou efektivní komunikace uvnitř i vně projektového týmu a prokázaná flexibilita při přidávání dalších požadavků.
tyto výhody by pomohly organizacím poskytovat lepší služby zákazníkům. Dále jsou relevantní v současné ekonomice, kde globalizace a filozofie svobodného marketingu ovlivňují vnímání zákazníků při zvyšování očekávání dodávat produkty a / nebo služby rychleji, levněji a lépe.
agilní metoda však není bez nedostatků, jak je vidět v tabulce 1. Často se měnící rozsah vede k obtížím při sledování průběhu projektu. Také není snadné zachytit tiché znalosti ve formě získaných poznatků. Řízení změn rozsahu, dokumentace, komplexní plán, řízení kvality a řízení rizik jsou důležitými výhodami tradičního řízení projektů, o které můžeme být při použití agilní metody zbaveni.
Metodika výzkumu
ke sběru dat jsme použili osobní rozhovory i dotazníky. Vytvořili jsme strukturovaný dotazník sestávající ze dvou částí. První část byla navržena tak, aby zachytila podrobnosti o projektu a jeho charakteristikách. Tato část se skládá z 13 otázky, které se týkají demografie projektu a postupů řízení projektů. Byly prezentovány účastníkům studie s možností poskytnout otevřené odpovědi v případě potřeby.
druhá část se zaměřila na Prohlášení o praxi projektového řízení a účastníci byli požádáni, aby odpověděli na tato prohlášení v pětibodové stupnici s 1 označením „silně nesouhlasím“ a 5 označením “ silně souhlasím.“Byla použita následující prohlášení, která se zabývala důležitými společnými principy postupů řízení projektů a sloužila k kontrastu tradičních a agilních postupů řízení projektů.
- kritéria pro měření úspěšnosti projektu jsou založena na cílech a cílech projektu.
- projekt je řízen požadavky.
- projekt je přizpůsobitelný změnám.
- podle vašeho názoru úsilí projektového řízení dosáhlo očekávaných výsledků
- interakce tváří v tvář a kratší komunikační řetězce mají větší význam než procesy a nástroje.
- tým se zaměřuje na realizaci projektu přes komplexní dokumentaci.
- spolupráce se zákazníky při vyjednávání smlouvy funguje lépe pro váš tým.
- projekt má dobře definovaný rozsah projektu.
- postupy řízení projektů se řídí životním cyklem projektu PMBOK® Guide.
- pro projekt je následováno iterativní nebo fázové plánování projektu.
- projekt má požadavky na dokumentaci, jako je dodržování norem jako ISO9000, OMB 300.
- v průběhu celého projektu jsou dodržovány postupy testování přijetí uživatele (UAT).
- projektový manažer je oprávněn činit rozhodnutí týkající se projektu bez zásahu zákazníka.
odpovědi na tyto výroky jsou analyzovány ve spojení s příslušnými otázkami z první sady 13 otázek. Spolu, odpovědi na obě části poskytly podrobné porozumění projektu pro smysluplnou analýzu.
výsledky studie
dotazník byl strukturován tak, aby zachytil údaje o 20 it poradenských projektech, které probíhaly v době výzkumu. Z projektů 65% jsou projekty typu Časové a materiálové smlouvy a zbývající jsou pevné pevné ceny (FFP). Mezi časovými a materiálními projekty má 55% trvání projektu více než dva roky.
většina projektových týmů je malá: pouze 15% má 10 nebo více členů. Pokud jde o komunikaci mezi členy projektového týmu, 60% respondentů využilo pro potřeby projektu pouze formální komunikaci; 30% používalo formální i neformální komunikaci a zbývajících 10% se spoléhalo pouze na neformální metody.
jeden ze dvou respondentů uvedl, že jejich projekty využily projektový plán. V související otázce, z těch projektů, které neměly plán projektu, 80% nepoužilo ani iterační plánování.
změna rozsahu je důležitým aspektem této studie. Z projektů zaznamenalo 70% alespoň jednou změnu rozsahu. Z těch, kteří zažili změnu rozsahu projektu, ji 60% zažilo více než dvakrát. Zatímco klient rozhoduje o změně rozsahu, konzultant—se souhlasem klienta-může zahrnout plán kontroly kvality do plánu řízení projektu. Na otázku, zda mají pro svůj projekt plán kontroly kvality, 65% respondentů uvedlo, že plán kontroly kvality nepoužilo.
výsledky diskuse a analýza
výsledky výzkumu byly analyzovány pečlivým zkoumáním jakéhokoli vztahu mezi otázkou a všemi ostatními otázkami nejprve k ověření výsledků a za druhé k rozvoji účinných strategií řízení. Kromě toho byly tyto výsledky analyzovány s cílem prozkoumat, které agilní a tradiční postupy řízení projektů lze použít v kombinaci k vývoji robustního přístupu k řízení projektů pro projekty v oblasti IT poradenství.
kritéria úspěchu projektu na základě jeho cílů a cílů
projekt je považován za úspěšný, pokud splňuje své cíle a cíle. Pouze 60% respondentů souhlasilo s tvrzením: „kritéria pro měření úspěchu projektu jsou založena na cílech a cílech projektu.“Asi 30% respondentů nesouhlasilo. Další analýza ukázala, že důvodem nesouhlasu bylo to, že tyto projekty zažívaly neustále se měnící podmínky a požadavky, nebo klient neměl o projektu jasno. Nakonec, tyto projekty zažívaly časté změny rozsahu. V jednom konkrétním případě se cíle a cíle projektu změnily.
je zajímavé poznamenat, že neexistuje žádná souvislost mezi skutečností, že kritéria úspěchu projektu jsou odvozena od jeho cílů a změny rozsahu, typu projektu a existence projektového plánu. Jinými slovy, odvození kritérií projektu ze strategického plánu organizace nemá žádný vliv na změnu rozsahu a na to, zda má projekt plán.
požadavky na projekt
obvykle je vypracován podrobný plán projektu poté, co jsou jasně identifikovány požadavky sponzora projektu. Vývoj plánu projektu a jeho provádění by se v zásadě měly řídit těmito požadavky. Dalo by se tedy očekávat, že projektoví manažeři budou souhlasit s tvrzením: „projekt je řízen požadavky.“Výsledky studie ukazují, že pouze 60% respondentů uvedlo, že jejich projekty jsou řízeny požadavky. Asi 20% respondentů, kteří nesouhlasili s tvrzením, uvedlo, že jejich projekty jsou realizovány bez použití projektového plánu.
asi 20% respondentů, kteří byli v reakci na toto prohlášení neutrální, jsou projektoví manažeři, kteří ve svých projektech nezaznamenali žádnou změnu rozsahu. Všichni ostatní respondenti, ti, kteří s tvrzením souhlasili nebo nesouhlasili, zažili ve svých současných projektech alespoň jednou změnu rozsahu.
Obecně platí, že pokud projekt není realizován podle jeho plánu, můžeme předpokládat, že požadavky nejsou identifikovány nebo se očekává, že se požadavky projektu během jeho provádění změní. V této studii však nemůžeme vytvořit takovou souvislost mezi „realizací projektu bez použití plánu projektu“ a „projekt není řízen požadavky“, protože pouze 50% těch, kteří souhlasili s druhým prohlášením, také řídilo projekty bez použití plánu.
adaptabilita na změnu
osmnáct z 20 projektů reagovalo na změny v projektu úspěšně. Adaptabilita na změnu je považována za primární charakteristiku pro projekt, který je kandidátem na použití agilní metodiky řízení projektů. IT konzultační projekty zastoupené v této studii prokázaly, že mají přizpůsobivost k řešení změny rozsahu.
úsilí o řízení projektů dosáhlo očekávaných výsledků
výsledky naznačují, že klient je ve většině projektů spokojen s výsledkem (70%). Tyto odpovědi však nebyly spojeny s odpověďmi na další důležité dotazníkové otázky týkající se průběhu projektu a produktu vyvinutého z pohledu projektového manažera. Důvody jsou zřejmé. Projekty stále zažívaly překročení času a nákladů. Zatímco konečný výsledek dodání Softwarového produktu je uspokojivý, procesy řízení projektů nebyly úspěšně provedeny. Závěrem by mohlo být, že přijetí tradičních postupů řízení projektů, jako je vývoj milníků, monitorování a kontrola, by pomohlo úspěšně řídit projekt.
význam osobní komunikace versus procesy
komunikace je klíčem k pochopení rolí, odpovědností, politik a postupů souvisejících s projekty a podpoře spolupráce. Komunikace nakonec vede k soudržnému projektovému týmu a povzbuzuje členy týmu ke spolupráci a účasti na rozhodování. Sedm z deseti projektových manažerů, kteří se studie zúčastnili, souhlasilo s tím, že interakce tváří v tvář a kratší komunikační řetězce mají větší význam než procesy a nástroje.
výsledky ukazují silnou souvislost mezi důležitostí osobní komunikace a komunikačními prostředky mezi členy projektového týmu. Ti, kteří nesouhlasili s tím, že osobní komunikace je důležitější než projektové procesy, použili neformální komunikaci mezi členy projektového týmu, zatímco ti, kteří považovali osobní komunikaci za důležitější, použili formální i neformální komunikaci.
zaměření na realizaci projektu Nad dokumentací
Projektová dokumentace je často přehlížena, a proto jsou organizace zbaveny důležitých poznatků získaných při plánování a realizaci projektu. Vzhledem k tomu, že všechny projekty zastoupené v této studii jsou projekty federální vlády, je zajímavé poznamenat, že 70% odpovědných projektových manažerů souhlasilo s tím, že jejich týmy se zaměřily na realizaci projektu ve srovnání s vytvářením komplexní dokumentace. V několika případech, kdy projektoví manažeři usoudili, že dokumentace je důležitější než realizace projektu, další šetření ukázalo, že zákazník byl ve všech těchto případech o projektu nerozhodný.
spolupráce zákazníků při vyjednávání smlouvy
vyjednávání smlouvy je základním rysem externích projektů. Během vyjednávání by se obě strany soustředily na ochranu svých vlastních zájmů. Vyjednávání smlouvy může probíhat v různých fázích projektu. Je žádoucí řešit tyto otázky prostřednictvím spolupráce, konkrétně při realizaci projektu; jinak to povede k problémům, jako je prodloužení smlouvy. Vzhledem k tomu, že všechny projekty zastoupené v této studii jsou smlouvy, je povzbudivé poznamenat, že více než polovina odpovědných projektových manažerů (60%) považuje spolupráci se zákazníky za důležitější než vyjednávání smlouvy. Navrhli, aby spolupráce fungovala lépe pro projektové týmy.
tam, kde došlo k neshodě, z čehož vyplývá, že spolupráce není tak důležitá jako vyjednávání, byly s těmito projekty spojeny dvě zajímavé skutečnosti. Všechny ostatní projekty používaly přímý kontakt jako prostředek komunikace se zúčastněnými stranami projektu, ale tyto projekty používaly řetězovou komunikaci a zákazník byl také nerozhodný o projektu. Oba tyto faktory znamenají obtížné podmínky pro spolupráci.
projekt a dobře definovaný rozsah projektu
projekty jsou obvykle spojeny s nejistotami a neznámými faktory, které vedou k nejednoznačnosti. V důsledku toho nelze v rané fázi projektu vypracovat podrobný rozsah a specifikace. Rozsah projektu se v průběhu projektu neustále mění. Někdy se mohou změnit i původní cíle projektu. Ze zkoumaných projektů má 40% dobře definovaný rozsah, zatímco dalších 45% ne.
80% projektů však zaznamenalo změnu rozsahu alespoň jednou, což potvrzuje dříve předložené argumenty.
postupy řízení projektů a životní cyklus projektu PMBOK® Guide
průvodce PMBOK® vyvinul propracovaný proces životního cyklu řízení projektů; je vyčerpávající a komplexní. Není však nutné, aby každý proces životního cyklu řízení projektu PMBOK® Guide byl aplikován na každý projekt. Jeho přijetí by mělo být specifické pro projekt. Podle očekávání se 45% projektových manažerů řídilo postupy projektového řízení životního cyklu projektu PMBOK® Guide a dalších 45% ne.
iterativní nebo fázové plánování projektu
definice rozsahu a plán řízení projektu jsou součástí plánu projektu. Jak bylo uvedeno výše, podrobný vývoj rozsahu a specifikací nelze vyvinout na začátku projektu. V důsledku toho se rozsah projektu v průběhu projektu neustále mění, což zdůrazňuje význam iterativního nebo fázového plánování projektu, což je důležitá charakteristika agilní metody. Na otázku, zda je pro projekt dodržováno iterační nebo fázové plánování projektu, polovina respondentů uvedla Ano a pouze 15% nedodrželo iterační plánování projektu. Je zajímavé poznamenat, že všichni, kteří nesouhlasili s praxí iterativního plánování projektů, neměli v první řadě projektový plán.
dokumentace a dodržování norem
Projektová dokumentace slouží jako reference pro analýzu historických dat a pomáhá organizacím neustále zlepšovat procesy řízení projektů a rozvíjet standardy. Dokumentace také pomůže identifikovat získané poznatky a upravit systémy řízení projektů, které povedou ke zralosti řízení projektů. OMB300 a ISO9000 slouží jako vodítka při navrhování systémů projektové dokumentace. Konkrétně je mnoho vládních projektů povinno dodržovat pokyny OMB300. Z respondentů 80% uvedlo, že IT projekty, které spravovali, měly požadavky na dokumentaci, jako je dodržování norem jako ISO9000 a OMB300. Tyto požadavky na IT konzultační projekty jsou však použitelné v omezené míře.
uživatelské přijímací testovací postupy
spokojenost zákazníků je primárním měřítkem kvality a úspěchu u dodatelných položek projektu. Proto jsou postupy pro akceptaci uživatelů považovány za důležité. I v případě méně hmatatelných výstupů projektu, jako je služba, je základním měřítkem úspěchu projektu spokojenost zákazníků. Je to však subjektivní. Pouze 30% respondentů uvedlo, že v průběhu projektu postupovalo podle postupů akceptace uživatelů, a 45% respondentů ne.
zmocnění k rozhodování o projektu
obecně by projektoví manažeři měli mít volnou ruku k rozhodování o projektu bez zásahu zákazníka, pokud tato rozhodnutí nemají žádný zásadní dopad na rozsah projektu nebo výstupy projektu. Pouze 15% souhlasilo s tím, že projektový manažer je oprávněn činit rozhodnutí týkající se projektu bez zásahu zákazníka. Asi 40% zůstalo neutrální a zbývajících 45% uvedlo, že projektový manažer tuto moc neměl. Vzhledem k tomu, že tyto projekty jsou externími a vládními projekty, mají tyto výsledky smysl.
závěr
naše výsledky studie ukazují, že většina projektů je řízena požadavky. Téměř všechny projekty zastoupené v této studii prokázaly, že jsou přizpůsobivé změnám. Neformální komunikace je považována za důležitější než formální procesy a systémy. Vzhledem k tomu, že projekty ve studii souvisejí s prací vlády, výsledky ukazují, že projektový tým se zaměřil na realizaci projektu přes komplexní dokumentaci. Spolupráce se zákazníky při vyjednávání smluv navíc funguje lépe pro projektové týmy. Častá změna rozsahu projektu znamená význam iterativního nebo fázového plánování projektu; důležitou charakteristiku agilního řízení projektů. Vzhledem k tomu, že všechny it poradenské projekty zastoupené v této studii jsou smlouvy, výsledky studie podporují formálně přijetí agilní metodiky pro IT konzultační projekty a jejich kombinaci s tradičními postupy řízení projektů, jako je plánovaný vývoj a monitorování milníků, postupy přijímání uživatelů a postupy řízení kvality.
vhodnost agilní metody pro projekty je smluvní závazek související s dokumenty týkajícími se plánování, monitorování a kontroly projektů. Projekty spojené s federální vládou mají obvykle významné požadavky na dokumentaci, jako je dodržování norem jako ISO9000 a OMB300; měli bychom být opatrní při úpravě agilní metody pro takové projekty.
úkolem je udržet agilitu, rychlou reakci na změnu, flexibilní a jednoduché plány, nepřetržitou integraci a další výhody agilní metody při začlenění některých komplexních procesů tradičních postupů řízení projektů.