Bevezetés
a projektek gyakran jelentik a szervezet stratégiai terveinek operacionalizálását. A projektek célja a termékek és szolgáltatások fejlesztése, valamint a működési hatékonyság növelése. Az üzleti tevékenység egyre inkább projektálódik, és a projektekre fordított globális kiadások évente több milliárd dollárt tesznek ki (Williams, 2005). Az okok nyilvánvalóak. A projektek lehetőséget nyújtanak olyan projektmenedzsment gyakorlatok alkalmazására, amelyek elősegítik az erőforrások hatékony és eredményes felhasználását. A projektmenedzsment tudományágának és szakmájának fejlődése ellenére azonban a közös tapasztalat azt sugallja, hogy sok projekt kudarcot vall (Williams, 2005), ami hangsúlyozza a projektmenedzsment folyamatok és a teljesítmény javításának fontosságát és szükségességét.
a szervezetek általában arra törekszenek, hogy a PMI szabványokon alapuló hagyományos projektmenedzsment legjobb gyakorlatait alkalmazzák a projektcélok elérése és az ügyfelek elvárásainak teljesítése érdekében. Azonban a projektmenedzsment Tudásbázis (PMBOK) nem minden ajánlott eljárása és gyakorlata lehet releváns minden projekt esetében. Gyakran a szelektív megközelítésnek van értelme a projektmenedzsment folyamatok és gyakorlatok elfogadásakor, hogy megfeleljenek a projekt méretének, típusának, összetettségének és az iparágnak, amelyben a projektet végzik. Az informatikai projektek irányításának eltérő megközelítésének szükségességét a projektmenedzsment szakirodalma jól dokumentálja.
a szoftverfejlesztési projektek gyakran ütköző kihívásokkal néznek szembe a szoftvertermékek gyorsított ütemben történő fejlesztése során, miközben robusztusan fejlesztik őket, hogy megbízhatóvá váljanak (Boehm, 2002). A gyorsan változó technológiai fejlesztésekkel lépést tartó informatikai projektek a tervezési és végrehajtási szakaszban gyakran hatókör-változásokon mennek keresztül. Következésképpen az informatikai projekteknek olyan kihívásokkal kell szembenézniük, amelyek eltérnek a hagyományos projektektől. Az informatikai projekteknél a hagyományos projektmenedzsment gyakorlatok számos kiigazítását és módosítását fejlesztik és gyakorolják, ezáltal új projektmenedzsment módszereket vezetnek be, mint például az agilis projektmenedzsment.
az agilis projektmenedzsment módszertan—a gyakran változó hatókörhöz való nagyobb alkalmazkodóképességével—iteratív vagy szakaszos tervezést és folyamatos integrációt alkalmaz. A fő elv az, hogy a projekt hatóköre puha maradjon. A módszertan elősegíti az együttműködést és növeli az ügyfelek elégedettségét. Az agile azonban nem teljes megoldás a szoftverek gyors ütemben történő fejlesztésére, miközben kielégíti az ügyfelek robusztus és megbízható igényeit. Ebben az összefüggésben a Boehm (2002) a hagyományos projektmenedzsment és az agilis szoftverfejlesztési módszertan kombinációját javasolta, amely megvalósítható és előnyösebb. Kiegészítő megközelítés lenne egy kockázatalapú megközelítés kidolgozása, amely úgy van kialakítva, hogy megőrizze mind az agilis, mind a tervvezérelt módszerek előnyeit, ugyanakkor enyhítse számos gyengeségüket (Boehm & Turner, 2003).
ez a kutatási cikk a fenti javaslatokat vizsgálja (Boehm, 2002; Boehm & Turner, 2003) az informatikai tanácsadási projektek irányításának kombinált megközelítéséről, amelyek különböznek az informatikai projektektől. Az informatikai tanácsadási projektek célja az informatikai projektek irányítása és támogatása. Gyakran kezdeményezik őket a kormányzati szektorban. Az informatikai tanácsadási projektek nem szoftverfejlesztési projektek; inkább projekttámogatást nyújtanak az informatikai projektekhez.
ebben a tanulmányban arra törekszünk, hogy megértsük, hogy az agilis projektmenedzsment gyakorlatok mennyire relevánsak az informatikai tanácsadási projektek szempontjából. A tanulmány célja az agilis projektmenedzsment használatának előnyeinek azonosítása, alkalmassága, valamint a hagyományos projektmenedzsmentek mely aspektusai kombinálhatók az agilis projektmenedzsmenttel az informatikai tanácsadási projektek számára a projekt teljesítményének javítása érdekében. A következő részben az agilis projektmenedzsment módszertan átfogó szakirodalmi áttekintését felhasználva azonosítottuk az agilis módszer legfontosabb jellemzőit és a projektek kezelésének egyedi megközelítését a hagyományos projektmenedzsmenthez képest. Az irodalmi áttekintés segített megérteni az agilis szoftverfejlesztés legfontosabb fogalmait és előnyeit. Továbbá, a szakirodalmi áttekintés eredményei alapján kidolgoztunk és bemutattunk egy strukturált kérdőív segítségével egy kutatási módszert az informatikai tanácsadási projektek megértésének fejlesztésére. Az adatok elemzése és megbeszélése, amelyet később bemutatnak, fontos betekintést és megállapításokat nyújt a tanulmányból. A tanulmányt az informatikai tanácsadási projektekre vonatkozó kutatási eredményeinkkel és ajánlásainkkal zárjuk.
Irodalmi áttekintés
az átfogó tervezés által vezérelt hagyományos projektmenedzsment gyakorlatok akkor alkalmazhatók, ha a projekt specifikációi egyértelműen meg vannak határozva. Másrészt, ha a specifikációk gyakran változnak a projekt élettartama alatt, a projektek irányításának hagyományos megközelítése nem működik hatékonyan. A szoftverfejlesztési projekteket gyakran minimális specifikációkkal tervezik meg, ami gyakran megváltoztatja ezeket a specifikációkat a projekt végrehajtása során. Ezenkívül a szoftverprojekt fejlesztési időtartama rövid. Az agilis módszerek a hagyományos projektmenedzsment technikákkal összehasonlítva alkalmasak szoftverfejlesztési projektekre, mivel ezek a projektek rövid fejlesztési időtartamúak (Hanakawa & Okura, 2004).
általánosságban elmondható, hogy a különböző szoftverfejlesztési módszerek, mint például az agilis projektmenedzsment, nagyobb ügyfél-elégedettséget, alacsonyabb hibaszázalékot, gyorsabb fejlesztési időt ígérnek ,és megoldást jelentenek a gyorsan változó projektkövetelményekre (Boehm & Turner, 2003). Az agilis projektmenedzsmenttel ellentétben a stage-gate modell egy munkafolyamatot használ a koncepció ötletétől a végül szállított termékig. Ez a modell a projektmenedzsment életciklus fázisait fejleszti a termékfejlesztés különböző szakaszai alapján a projektek kezeléséhez. Fontos különbség a stage-gate modell és az agilis projektmenedzsment között, hogy az előbbi megpróbálja minimalizálni a követelmények változását, hogy a termék időben elkészüljön (Karistrom & Runeson, 2005). Egy másik módszer a szoftverek fejlesztésére a SCRUM, amely a projektmenedzsment alapelveinek összessége, amely kis, keresztfunkcionális és saját irányítású csapatokat alkalmaz (Schatz & Abdelshafi, 2005). A SCRUM megköveteli, hogy minden csapattag és Terméktulajdonos együtt dolgozzon minden fejlesztési elem elején, és a módszertan a meglévő fejlesztési folyamatok köré épül. Ezért Schatz és Abdelshafi azzal érvelt, hogy a SCRUM-nak nem lesz alapterve a projekt sikerének mérésére. Az agilis projektmenedzsmentet azonban figyelembe veszik ebben a tanulmányban, mivel nagyobb rugalmasságot és alkalmazkodóképességet biztosít a szoftverfejlesztési projektekhez.
a fent tárgyalt előnyök mellett az agilis módszertan alkalmazható turbulens és folyamatosan változó környezetekben (Highsmith & Cockburn, 2001). Továbbá az agilis módszer hangsúlyozza a piachoz, a technológiához és a folyamatokhoz való alkalmazkodóképességet (Mellor, 2005). Az agilis módszertan olyan megközelítés, amely elsősorban a fontos jellemzőkre összpontosít, és ennek eredményeként korai visszajelzéseket keres a funkciókról (Karistrom & Runeson, 2005). A fontos jellemzők azonosítása után a projektmenedzser biztosítja, hogy ne legyen késés. Karistrom és Runeson jelezte, hogy az agilis folyamat elkerüli az erőforrások, a rögzített tervek és a hosszú távú tervek támogatását.
az agilis módszertan azonban nem alkalmas minden szoftverfejlesztési projektre. Scott Amblerre, az agilis módszer fejlesztőjére hivatkozva a Boehm (2002) hagyományos, tervvezérelt projektmenedzsment módszertant ajánlott olyan biztosítási szoftverekhez, mint az életkritikus rendszerek.
az agilis módszer a káosz és bizonytalanság által jellemzett igényes projektkörnyezet miatt tehetséges emberekből álló projektcsapatokra van szükség a kihívást jelentő igények és igények kielégítésére. Constantine (2001) kutatási tanulmányára hivatkozva Boehm (2002) azt javasolta, hogy az agilis módszerek nagyon alkalmas embereket igényelnek. Ezenkívül az agile nem alkalmas nagyobb csapatok számára (Highsmith & Cockburn, 2001), mivel a sikerhez szorosan összehangolt csapatmunkára van szükség, és a 15 vagy 20-nál több fejlesztővel rendelkező csapatok növelik a projekt kezelésének nehézségeit (Constantine, 2001).
nyilvánvaló, hogy az agilis módszer koherens csapatokat alkalmaz (Karistrom & Runeson, 2005). Karistrom és Runeson további agilis funkciókat azonosítottak, mint például a kis és kezelhető feladatok, a folyamatos integráció és az automatikus tesztelés. Következésképpen az agilis projektcsapatokat a jó belső kommunikáció, a magasabb minőség és az irányítás érzése jellemzi (Karistrom & Runeson). Ugyanakkor potenciális elszigeteltséget terveznek az agilis csapat számára.
a kommunikáció, az előrehaladás dokumentumalapú kezelése és a minőségellenőrzés szempontjából a hagyományos projektmenedzsment általános gyakorlata nem egyezik az agilis szoftverfejlesztési módszerrel (Hanakawa & Okura, 2004). Az agilis módszertanokban általában a személyes interakciót részesítik előnyben a fejlesztési célok folyamatos átrendezése érdekében (Melnik & Mauer, 2004). Kiemelve a hagyományos és az agilis módszerek közötti különbséget, Melnik és Mauer azt javasolta, hogy a szoftverfejlesztésben előnyben részesítsék a rövid tudástranszfert, valamint a közvetlen kommunikációt és együttműködést, szemben a hagyományos projektmenedzsment gyakorlatokkal, ahol hosszú tudástranszfer láncokat alkalmaznak, amelyek gyakran hajlamosak az információ torzulására és elvesztésére.
az egyik fontos különbség a tervvezérelt hagyományos projektmenedzsment gyakorlatok és az agilis módszerek között az, hogy az agilis módszerek az agilitást a projektcsapat hallgatólagos tudásából, nem pedig a hagyományos projektmenedzsmentben gyakran dokumentumok és tervek formájában használt explicit tudásból ragadják meg (Boehm, 2002).
egy másik különbség a projektekhez készített dokumentáció mennyisége és típusa. A tervvezérelt hagyományos projektmenedzsment hangsúlyozza a dokumentumok részletes tervezését, nyomon követését és ellenőrzését. A tervezési indokok, az okokat és indoklásokat kifejező dokumentumok nagymértékben automatizált eljárással készülnek, és ezek a tervezési indokok agilis dokumentációként szolgálnak (Sauer, 2003).
Coram and Bohner (2005) azonosította az agilis módszer közös jellemzőit: együttműködés, kis csapatok, rövid kiadási ütemtervek, időbokszolás és állandó tesztelés. A projektmenedzser felelős a rendkívül együttműködő környezet biztosításáért. Ebből a célból az agilis módszer arra ösztönzi a kis csapatokat és projektenként néhány alcsoportot, hogy ösztönözzék az együttműködést. Ennek következtében az agilis módszer valószínűleg kevesebb folyamatot és tervezést igényel a csapat tevékenységeinek koordinálásához. Az agilis módszer rövid kiadási ütemtervet is alkalmaz, amelyek két héttől hat hónapig változhatnak. Az időbokszolás olyan koncepció, amely rögzített időtartamot ír elő a projekt eredményeinek kiadására, ami segít csökkenteni az aranyozást és a hatókör kúszását. A folyamatos tesztelés biztosítja a termék minőségét és integrációját. Ezenkívül Coram és Bohner azt javasolta, hogy a projektmenedzsereknek nyomon kell követniük az előrehaladást és üzleti döntéseket kell hozniuk, különös hangsúlyt fektetve a változásokra való reagálásra, nem pedig egy konkrét terv követésére.
az Időbokszolás kiszámíthatatlan tervezéshez vezet a legjobb tipp szerint, és a rögzített dátumok váratlan meglepetéseket hozhatnak a fejlesztési szakaszban (Patton, 2003). Ennek az iteratív projekttervezési folyamatnak egy másik eredménye az, hogy az agilis módszer nem tudja nyomon követni az előrehaladást a teljes százalék alapján (Patton, 2003).
a kis alcsoportok bevonása a tervezésbe motivált szoftverfejlesztő mérnököket eredményez; a projekt elején technikai kérdések merülnek fel, és kevés ellenállás lesz a megvalósításban (Karistrom & Runeson, 2005). Ezenkívül a projekt hatókörének agilis megközelítéssel történő meghatározása költségcsökkentést eredményezne (Mcgovern, 2002). Az agilis módszer a követelményeken alapuló tervezést használja, és lehetővé teszi az US control scope (McGovern) használatát is.
az eddigi és egyéb referenciák és megbeszélések (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004) felhasználásával az 1.táblázat összefoglalja a hagyományos és az agilis projektmenedzsment gyakorlatainak összehasonlítását.
1. táblázat: Az agilis és a hagyományos Projektmenedzsment összehasonlítása
| projekt fázis | hagyományos | agilis |
| beavatás |
|
|
| tervezés |
|
|
| Execution |
|
|
| ellenőrzés és ellenőrzés |
|
|
| Bezárás |
|
|
a szakirodalom összefoglalása
az agilis projektmenedzsment módszertant általában szoftverfejlesztési projektekben használják. Nagyobb alkalmazkodóképességgel rendelkezik a gyakran változó hatókörhöz. Ennek következtében az agilis projektmenedzsment iteratív vagy szakaszos tervezést és folyamatos integrációt alkalmaz a projekt teljes élettartama alatt. Az agilis projektmenedzsment legfontosabb elve az, hogy a projekt hatóköre puha maradjon. Az agilis projektmenedzsment módszer különbözik a hagyományos projektmenedzsment módszertől azáltal, hogy fontosságot tulajdonít a hagyományosan lényegtelennek tartott tényezőknek. Az agilis viszonylag nagyobb jelentőséget tulajdonít a:
- egyének és interakciók folyamatokon és eszközökön keresztül
- projektvégrehajtás átfogó dokumentáción keresztül
- ügyfél-együttműködés szerződéses tárgyalásokon keresztül
- válasz a projektterv módosítására
az agilis módszer hangsúlyozza a rugalmasságot a projekt igényeinek kielégítése érdekében. Ezenkívül az ügyfelek visszajelzéseire támaszkodik a projektterv módosításainak kezdeményezéséhez. A módszertan a megfelelő végfelhasználók és céljaik azonosításának megközelítését használja a projekt eredmények megfogalmazásához és az üzleti folyamatok teljesítő igényeinek kielégítéséhez. Az agilis módszer használatának előnyei közé tartozik a megnövekedett ügyfél-elégedettség, az alacsonyabb hibaszázalék és a gyorsabb fejlesztési idő. Ezenkívül az agilis módszer válasz a gyorsan változó követelményekre, mivel korai visszajelzéseket használ a projekt eredményeinek technológiai jellemzőiről. Az agilis módszer biztosítja, hogy a követelmények ne legyenek zsúfolva. Az agilis módszer legfontosabb jellemzői A hatékony kommunikáció a projektcsapaton belül és kívül, valamint a rugalmasság a további követelmények hozzáadásában.
ezek az előnyök segítenék a szervezeteket abban, hogy jobb ügyfélszolgálatot nyújtsanak. Továbbá relevánsak a jelenlegi gazdaságban, ahol a globalizáció és a szabad marketing filozófia befolyásolja az ügyfelek felfogását a termékek és/vagy szolgáltatások gyorsabb, olcsóbb és jobb szállítására vonatkozó elvárások növelésében.
az agilis módszer azonban nem hiányos, amint az az 1. táblázatban látható. A gyakran változó hatókör nehézséget okoz a projekt előrehaladásának nyomon követésében. Továbbá nem könnyű megragadni a hallgatólagos tudást a tanulságok formájában. A Scope change control, a dokumentáció, az átfogó terv, a minőségirányítás és a kockázatkezelés a hagyományos projektmenedzsment fontos előnyei, amelyektől megfoszthatunk az agilis módszer alkalmazása során.
kutatási módszertan
az adatok gyűjtéséhez mind személyes interjúkat, mind kérdőíveket használtunk. Kidolgoztunk egy strukturált kérdőívet, amely két részből áll. Az első rész célja a projekt részleteinek és jellemzőinek rögzítése volt. Ez a szakasz 13 kérdésből áll, amelyek a projekt demográfiájához és a projektmenedzsment gyakorlatához kapcsolódnak. Bemutatták őket a tanulmány résztvevőinek azzal a lehetőséggel, hogy szükség esetén nyílt végű válaszokat adjanak.
a második szakasz a projektmenedzsment gyakorlati állításaira összpontosított, és a résztvevőket arra kérték, hogy ezekre az állításokra ötpontos skálán válaszoljanak, 1-vel “határozottan nem értek egyet”, 5-tel pedig “határozottan egyetértek.”A következő nyilatkozatokat a projektmenedzsment gyakorlat fontos közös tételeivel foglalkoztuk, valamint a hagyományos és agilis projektmenedzsment gyakorlatok szembeállítását szolgáltuk.
- a projekt sikerének mérésére szolgáló kritériumok a projekt célkitűzésein és céljain alapulnak.
- a projektet követelmények vezérlik.
- a projekt változtatható.
- véleménye szerint a projektmenedzsment erőfeszítései elérték a várt eredményeket
- a személyes interakciók és a rövidebb kommunikációs láncok fontosabbak, mint a folyamatok és az eszközök.
- a csapat a projekt végrehajtására összpontosít az átfogó dokumentáció felett.
- az ügyfelek együttműködése a szerződéses tárgyalások során jobban működik a csapat számára.
- a projekt jól meghatározott projektkörrel rendelkezik.
- a projektmenedzsment gyakorlata a PMBOK (PMBOK) fejezetet követi a projekt életciklusának útmutatójában.
- iteratív vagy szakaszos projekttervezést követ a projekt.
- a projekt dokumentációs követelményekkel rendelkezik, mint például az ISO9000, OMB 300 szabványok betartása.
- felhasználói elfogadási tesztelési (UAT) eljárásokat követnek a projekt során.
- a projektmenedzser jogosult a projekthez kapcsolódó döntések meghozatalára az ügyfél beavatkozása nélkül.
ezekre az állításokra adott válaszokat az első 13 kérdésből álló megfelelő kérdésekkel együtt elemezzük. Együtt, mindkét szakaszra adott válaszok részletes megértést nyújtottak a projektről Az értelmes elemzés érdekében.
vizsgálati eredmények
a kérdőívet úgy alakították ki, hogy a kutatás idején folyamatban lévő 20 informatikai tanácsadási projekt adatait rögzítse. A projektek 65% – a idő-és tárgyi szerződés típusú projekt, a fennmaradó rész pedig szilárd rögzített ár (FFP) típusú. Az idő-és anyagprojektek közül 55% – nak a projekt időtartama meghaladja a két évet.
a projektcsapatok többsége kicsi: csak 15% – nak van 10 vagy több tagja. A projektcsapat tagjai közötti kommunikáció tekintetében a válaszadók 60% – a csak formális kommunikációt használt a projekt igényeihez; 30% mind formális, mind informális kommunikációt használt, a fennmaradó 10% pedig csak informális módszerekre támaszkodott.
két válaszadó közül egy jelezte, hogy projektjei projekttervet használtak. Egy kapcsolódó kérdésben a projekttervvel nem rendelkező projektek 80% – a nem alkalmazta az iteratív tervezést sem.
a hatókör megváltoztatása a tanulmány fontos szempontja. A projektek 70% – a legalább egyszer tapasztalta a hatókör változását. Azok közül, akik tapasztalták a projekt hatókörének változását, 60% – uk több mint kétszer tapasztalta meg. Amíg az ügyfél dönt a hatókör megváltoztatásáról, a tanácsadó—az ügyfél beleegyezésével—felveheti a minőségellenőrzési tervet a projektmenedzsment tervbe. Arra a kérdésre, hogy van-e minőség-ellenőrzési tervük a projektjükhöz, a válaszadók 65% – a jelezte, hogy nem használ minőség-ellenőrzési tervet.
eredmények vita és elemzés
a kutatási eredményeket úgy elemeztük, hogy gondosan megvizsgáltuk a kérdés és az összes többi kérdés közötti összefüggéseket, először az eredmények validálása, másodszor pedig a hatékony irányítási stratégiák kidolgozása érdekében. Ezen túlmenően ezeket az eredményeket azzal a céllal elemezték, hogy megvizsgálják, mely agilis és hagyományos projektmenedzsment gyakorlatok kombinálhatók az informatikai tanácsadási projektek robusztus projektmenedzsment megközelítésének kidolgozására.
a projekt sikerességi kritériumai a célkitűzései és céljai alapján
a projekt akkor tekinthető sikeresnek, ha teljesíti célkitűzéseit és céljait. A válaszadók mindössze 60% – a értett egyet a kijelentéssel: “a projekt sikerességének mérésére szolgáló kritériumok a projekt célkitűzésein és céljain alapulnak.”A válaszadók mintegy 30% – a nem értett egyet. További elemzések kimutatták, hogy az egyet nem értés oka az volt, hogy ezek a projektek folyamatosan változó feltételeket és követelményeket tapasztaltak, vagy az ügyfél nem volt tisztában a projekttel. Végül ezek a projektek gyakran változtak a hatókörben. Egy konkrét esetben a projekt céljai és célkitűzései megváltoztak.
érdekes megjegyezni, hogy nincs összefüggés a tény között, hogy a projekt sikerkritériumai a célkitűzéseiből és a hatókör változásából, a projekt típusától és a projektterv meglététől származnak. Más szavakkal, a projektkritériumok levezetése a szervezet stratégiai tervéből nem befolyásolja a hatókör változását és azt, hogy a projekt rendelkezik-e tervvel.
Projektkövetelmények
általában részletes projekttervet dolgoznak ki, miután a projektszponzor követelményei egyértelműen meghatározásra kerültek. A projektterv kidolgozását és végrehajtását elvileg ezeknek a követelményeknek kell vezérelniük. Ezért azt várnánk, hogy a projektmenedzserek egyetértenek a kijelentéssel: “a projektet a követelmények vezérlik.”A tanulmány eredményei azt mutatják, hogy a válaszadók mindössze 60% – A mondta, hogy projektjeiket a követelmények vezérlik. A nyilatkozattal nem értő válaszadók mintegy 20% – a jelezte, hogy projektjeiket projektterv használata nélkül hajtják végre.
A válaszadók mintegy 20% – A, akik semlegesek voltak erre a kijelentésre, azok a projektmenedzserek, akik nem tapasztaltak semmilyen változást a projektjeikben. Az összes többi válaszadó, azok, akik egyetértettek vagy nem értettek egyet a kijelentéssel, legalább egyszer tapasztaltak hatókör-változást jelenlegi projektjeikben.
általánosságban elmondható, hogy ha egy projektet nem a terv szerint hajtanak végre, akkor feltételezhetjük, hogy a követelményeket nem határozták meg, vagy a projekt követelményei várhatóan megváltoznak a végrehajtás során. Ebben a tanulmányban azonban nem hozhatunk létre ilyen összefüggést a “projekt megvalósítása a projektterv használata nélkül” és a “a projektet nem a követelmények vezérlik” között, mivel a második állítással egyetértőknek csak 50% – a irányított projekteket terv használata nélkül is.
alkalmazkodóképesség a változáshoz
20 projektből tizennyolc sikeresen reagált a projekt változásaira. A változáshoz való alkalmazkodás elsődleges jellemzője annak, hogy egy projekt jelölt legyen az agilis projektmenedzsment módszertan alkalmazására. Az ebben a tanulmányban képviselt informatikai tanácsadási projektek bebizonyították, hogy alkalmazkodóképességük van a hatókör változásának kezelésére.
a projektmenedzsment erőfeszítései elérték a várt eredményeket
az eredmények azt sugallják, hogy az ügyfél elégedett az eredménnyel a projektek többségében (70%). Ezek a válaszok azonban nem kapcsolódtak a projekt előrehaladásával és a projektmenedzser szemszögéből kifejlesztett termékkel kapcsolatos egyéb fontos felmérési kérdésekre adott válaszokhoz. Az okok nyilvánvalóak. A projektek még mindig idő-és költségtúllépéseket tapasztaltak. Bár a szoftvertermék kézbesítésének végeredménye kielégítő, a projektmenedzsment folyamatokat nem hajtották végre sikeresen. A következtetés az lehet, hogy a hagyományos projektmenedzsment gyakorlatok, például mérföldkövek kidolgozása, monitoring és kontrolling elfogadása elősegítette volna a projekt sikeres irányítását.
a személyes kommunikáció fontossága a folyamatokkal szemben
a kommunikáció kulcsfontosságú a projektekkel kapcsolatos szerepek, felelősségek, politikák és eljárások megértéséhez és az együttműködés ösztönzéséhez. Végül a kommunikáció egy összetartó projektcsapathoz vezet, és arra ösztönzi a csapattagokat, hogy működjenek együtt és vegyenek részt a döntéshozatalban. A tanulmányban részt vevő tíz projektmenedzser közül hét egyetértett abban, hogy a személyes interakciók és a rövidebb kommunikációs láncok nagyobb jelentőséget kapnak, mint a folyamatok és az eszközök.
az eredmények szoros összefüggést mutatnak a személyes kommunikáció fontossága és a projektcsoport tagjai közötti kommunikációs eszközök között. Azok, akik nem értettek egyet azzal, hogy a személyes kommunikáció fontosabb, mint a projektfolyamatok, informális kommunikációt alkalmaztak a projektcsoport tagjai között, míg azok, akik fontosabbnak tartották a személyes kommunikációt, mind formális, mind informális kommunikációt alkalmaztak.
a projekt végrehajtására összpontosít a dokumentáció felett
a projektdokumentációt gyakran figyelmen kívül hagyják, következésképpen a szervezeteket megfosztják a projekttervezés és-végrehajtás fontos tanulságaitól. Figyelembe véve, hogy a tanulmányban bemutatott összes projekt szövetségi kormányzati projekt, érdekes megjegyezni, hogy a válaszadó projektmenedzserek 70% – a egyetértett abban, hogy csapataik a projekt végrehajtására összpontosítottak az átfogó dokumentáció elkészítéséhez képest. Néhány esetben, amikor a projektmenedzserek úgy vélték, hogy a dokumentáció fontosabb, mint a projekt végrehajtása, a további vizsgálat feltárta, hogy az ügyfél minden esetben határozatlan volt a projekttel kapcsolatban.
ügyfél-együttműködés a szerződéses tárgyalások során
a szerződéses tárgyalások a külső projektek alapvető jellemzője. A tárgyalások során mindkét fél saját érdekeinek védelmére összpontosítana. A szerződés tárgyalása a projekt különböző szakaszaiban történhet. Kívánatos, hogy ezeket a kérdéseket együttműködés útján kezeljük, különösen a projekt végrehajtása során; különben olyan problémákhoz vezet, mint a szerződés meghosszabbítása. Tekintettel arra, hogy a tanulmányban bemutatott összes projekt szerződés, érdemes megjegyezni, hogy a válaszadó projektmenedzserek több mint fele (60%) fontosabbnak tartja az ügyfelek együttműködését, mint a szerződéses tárgyalásokat. Azt javasolták, hogy az együttműködés jobban működjön a projektcsapatok számára.
ahol nézeteltérés merült fel, ami azt jelentette, hogy az együttműködés nem olyan fontos, mint a tárgyalás, két érdekes tényt társítottak ezekhez a projektekhez. Az összes többi projekt közvetlen kapcsolatot használt kommunikációs eszközként a projekt érdekeltjeivel, de ezek a projektek parancsnoki láncon keresztül kommunikáltak, és az ügyfél is határozatlan volt a projekttel kapcsolatban. Mindkét tényező az együttműködés nehéz feltételeit jelenti.
projekt és jól meghatározott Projektkör
a projektek általában bizonytalanságokhoz és ismeretlen tényezőkhöz kapcsolódnak, amelyek kétértelműséghez vezetnek. Ennek következtében a projekt korai szakaszában nem lehet részletes hatókört és előírásokat kidolgozni. A projekt hatóköre folyamatosan változik a projekt során. Néha a projekt eredeti célkitűzései is megváltozhatnak. A vizsgált projektek 40%-A rendelkezik jól meghatározott hatókörrel, míg további 45% – uk nem.
a projektek 80% – A azonban legalább egyszer tapasztalta a hatókör változását, ami igazolja a korábban bemutatott érveket.
Projektmenedzsment gyakorlatok és a PMBOK (PMBOK) fejezet a projekt életciklusa
a PMBOK (PMBOK) fejezet átfogó és átfogó projektmenedzsment-életciklus-folyamatot dolgozott ki. Nem szükséges azonban, hogy a PMBOK minden projektre alkalmazza a projektmenedzsment életciklusának minden folyamatát. Elfogadásának projektspecifikusnak kell lennie. Ahogy az várható volt, a projektmenedzserek 45% – A követte a PMBOK-ok projektmenedzsment gyakorlatát a projekt életciklusának irányításában, további 45% – uk pedig nem.
iteratív vagy szakaszos projekttervezés
a hatókör meghatározása és a projektmenedzsment terv a projektterv részét képezi. Amint azt korábban tárgyaltuk, a hatókör és a specifikációk részletes kidolgozása nem dolgozható ki a projekt korai szakaszában. Következésképpen a projekt hatóköre folyamatosan változik a projekt során, ami hangsúlyozza az iteratív vagy szakaszos projekttervezés fontosságát, amely az agilis módszer fontos jellemzője. Arra a kérdésre, hogy az iteratív vagy szakaszos projekttervezést követik-e vagy sem, a válaszadók fele igennel válaszolt, és csak 15% – uk nem követte az iteratív projekttervezést. Érdekes megjegyezni, hogy mindazok, akik nem értettek egyet az iteratív projekttervezés gyakorlatával, eleve nem rendelkeztek projekttervvel.
dokumentáció és szabványok betartása
a projektdokumentáció referenciaként szolgál a múltbeli adatok elemzéséhez, és segíti a szervezeteket a projektmenedzsment folyamatainak folyamatos fejlesztésében és a szabványok kidolgozásában. A dokumentáció segít a levont tanulságok azonosításában és a projektmenedzsment rendszerek módosításában is, amelyek a projektmenedzsment érettségéhez vezetnek. Az OMB300 és az ISO9000 útmutatóként szolgál a projektdokumentációs rendszerek tervezésében. Pontosabban, sok kormányzati projektnek be kell tartania az OMB300 irányelveit. A válaszadók 80% – a azt mondta, hogy az általuk kezelt informatikai projektek dokumentációs követelményekkel rendelkeznek, mint például az ISO9000 és az OMB300 szabványok betartása. Ezek az informatikai tanácsadási projektekre vonatkozó követelmények azonban korlátozott mértékben alkalmazhatók.
felhasználói elfogadási vizsgálati eljárások
a vevői elégedettség a minőség és a siker elsődleges mércéje a projekt szállítható termékeknél. Ezért a felhasználói elfogadási vizsgálati eljárásokat fontosnak tekintik. Még a kevésbé kézzelfogható projektteljesítmények, például a szolgáltatás esetében is, a projekt sikerének mögöttes mércéje az ügyfelek elégedettsége. Ez azonban szubjektív. A válaszadók mindössze 30% – A mondta, hogy a projekt során végig követte a felhasználói elfogadási teszt eljárásait, a válaszadók 45% – a pedig nem.
a projekttel kapcsolatos döntések meghozatalának felhatalmazása
a projektmenedzsereknek általában szabad kezet kell kapniuk a projekttel kapcsolatos döntések meghozatalához az ügyfél beavatkozása nélkül, amikor ezek a döntések nincsenek jelentős hatással a projekt hatókörére vagy a projekt eredményeire. Csak 15% – uk értett egyet azzal, hogy a projektmenedzser felhatalmazást kap a projekttel kapcsolatos döntések meghozatalára az ügyfél beavatkozása nélkül. Körülbelül 40% semleges maradt, a fennmaradó 45% pedig azt mondta, hogy a projektmenedzsernek nincs ilyen hatalma. Mivel ezek a projektek külső és kormányzati projektek, ezeknek az eredményeknek van értelme.
következtetés
vizsgálati eredményeink azt mutatják, hogy a projektek többségét követelmények vezérlik. A tanulmányban bemutatott projektek szinte mindegyike bizonyította, hogy alkalmazkodnak a változásokhoz. Az informális kommunikáció fontosabb, mint a formális folyamatok és rendszerek. Figyelembe véve, hogy a tanulmányban szereplő projektek kormányzati munkához kapcsolódnak, az eredmények azt mutatják, hogy a projektcsapat a projekt végrehajtására összpontosított az átfogó dokumentáció felett. Ezenkívül az ügyfelek együttműködése a szerződéses tárgyalások során jobban működik a projektcsapatok számára. A projekt hatókörének gyakori változása az iteratív vagy szakaszos projekttervezés fontosságát jelzi; az agilis projektmenedzsment fontos jellemzője. Tekintettel arra, hogy a tanulmányban bemutatott összes informatikai tanácsadási projekt szerződés, a tanulmányi eredmények ösztönzik az agilis módszertan hivatalos elfogadását az informatikai tanácsadási projektekhez, és ötvözik azokat a hagyományos projektmenedzsment gyakorlatokkal, mint például a tervvezérelt mérföldkövek fejlesztése és nyomon követése, a felhasználók elfogadási eljárásai és a minőségirányítási gyakorlatok.
az agilis módszer projektekre való alkalmassága a projekttervezésre, monitoringra és ellenőrzésre vonatkozó dokumentumokkal kapcsolatos szerződéses kötelezettség. A szövetségi kormányhoz kapcsolódó projektek általában jelentős dokumentációs követelményekkel rendelkeznek, mint például az ISO9000 és az OMB300 szabványok betartása; óvatosan kell eljárnunk az ilyen projektek agilis módszerének módosításakor.
a kihívás az agilis módszer agilitásának, a változásokra való gyors reagálásnak, a rugalmas és egyszerű terveknek, a folyamatos integrációnak és az agilis módszer egyéb előnyeinek fenntartása, miközben magában foglalja a hagyományos projektmenedzsment gyakorlatok néhány átfogó folyamatát.