A dolgozat áttekinti a nemzetközi gyakorlatban is jól ismert projektvezetési módszertanok néhány elemét és azokat összeveti a szerzők legfrissebb gyakorlati tapasztalataival. A célkitűzés az, hogy bemutassák, menynyire lehet hasznos az elmélet alapos ismerete, miben segíthet bennünket a napi, gyakorlati problémáink megoldásában. Bár tapasztalataik és következtetéseik elsősorban informatikai projektekhez kötődnek, de úgy gondolják, hogy azok általánosíthatóak.
Angol absztrakt:
The authors of the paper review several elements of one of the internationally well known project leading methodologies and compare them with their latest practical experience. Their goal is to show how useful it is to know the theory deeply, how can it help to solve the daily and practical problems. Although the authors’ experiences and conclusions are mainly IT based, they believe they can be generalized.
A regisztrálást követően fogja tudni megtekinteni a cikk tartalmát!
A megadott cikk nem elérhető!
Tisztelt Felhasználónk!
Az Ön által megtekinteni kívánt cikk nem elérhető a rendszerben!
A megadott cikk nem elérhető!
Tisztelt Felhasználónk!
Az Ön által megtekinteni kívánt cikk nem elérhető a rendszerben!
Sikeresen szavazott a cikkre!
Tisztelt Felhasználónk!
Köszönjük a szavazatát!
A szavazás nem sikerült!
Tisztelt Felhasználónk!
Ön már szavazott az adott cikkre!
Cikk megtekintése
Tisztelt Felhasználónk!
A cikk több nyelven is elérhető! Kérjük, adja meg, hogy melyik nyelven kívánja megtekinteni az adott cikket!
Cikk megtekintésének megerősítése!
Tisztelt Felhasználónk!
Az Ön által megtekintetni kívánt cikk tartalma fizetős szolgáltatás.
A megtekinteni kívánt cikket automatikusan hozzáadjuk a könyvespolcához!
A cikket bármikor elérheti a könyvespolcok menüpontról is!
INFOKOMMUNIKÁCIÓ INFORMÁCIÓS RENDSZEREK Projektvezetés elmélete és gyakorlata Fehér András, Pipis László, Humánsoft Kft. A dolgozat áttekinti a nemzetközi gyakorlatban is jól ismert projektvezetési módszertanok néhány elemét és azokat összeveti a szerzők legfrissebb gyakorlati tapasztalataival. A célkitűzés az, hogy bemutassák, menynyire lehet hasznos az elmélet alapos ismerete, miben segíthet bennünket a napi, gyakorlati problémáink megoldásában. Bár tapasztalataik és következtetéseik elsősorban informatikai projektekhez kötődnek, de úgy gondolják, hogy azok általánosíthatóak. The authors of the paper review several elements of one of the internationally well known project leading methodologies and compare them with their latest practical experience. Their goal is to show how useful it is to know the theory deeply, how can it help to solve the daily and practical problems. Although the authors’ experiences and conclusions are mainly IT based, they believe they can be generalized. PROJEKTALAPÍTÓ DOKUMENTUM (PAD) Biblia. Forrás. Gránitalapzat. Nélkülözhetetlen! Ne sajnáljuk rá az időt, energiát! Többnyire még „békeidőben” készül, tehát nyugodtan, alaposan át lehet gondolni mindent, egyeztetni lehet és kell az elképzeléseket. Egy külön dolgozatot szentelhetnénk a témának, most csak néhány részletet emelnénk ki. Ha sikerül világosan, tömören, röviden megfogalmaznunk a projekt céljait, sikerkritériumait, az nagyon hasznos lesz a projekt értékelésekor. Mást nem is említve, amikor „elvesztünk, készül ránk szakadni az ég” a projekt megvalósítása során, sokat segíthet a tisztánlátásban, a helyes út kiválasztásában, ha visszanyúlunk ezekhez a kritériumokhoz mint rendező elvekhez. Bármily magától értetődőnek is tűnik, itt kell megfogalmazni a projekt tárgyát is, ami az angol nyelv játékosságával élve, legyen SMART. Azaz „Specific, Measurable, Agreed upon, Realistic, Timely” vagyis jól meghatározott, mérhető, reális, időben behatárolt, és a döntéshozók értsenek egyet velük, amit aláírásukkal is erősítsenek meg. Újabban gyakran találkozhatunk olyan fejezettel is, ami azt tartalmazza, mi nem része a projektnek. A logika szabályai szerint itt persze mindent felsorolhatnánk, ami nem a projekt része, de természetesen józan ésszel kell kezelni a kérdést. Elsősorban a megvalósítói oldalról szemlélve javasoljuk számba venni azokat az elvárásokat, amelyekről feltételezzük, hogy az ügyfél a projekt részének tekinti, mi viszont nem gondoljuk, hogy szerződésünk kiterjed rájuk. Mivel még „jóban vagyunk” egymással, sokkal egyszerűbb itt tisztázni és rögzíteni a nézetkülönbségeket. A projektdokumentumok tartalmi és formai elemeinek rögzítése is a PAD-ba való. Csak arra ügyeljünk, hogy annyi és olyan részletezettségű dokumentumot határozzunk meg, amennyit képesek leszünk folyamatosan vezetni, vezettetni és amennyi jól szolgálja céljainkat. Gyakori hiba az is – bár ennek egy külön fejezetben, a projekt dokumentálásában is helye volna –, hogy a projekt során engedünk elveinkből és azt mondjuk, inkább dolgozzunk, most nem érünk rá dokumentálni. Óriási hibát követünk el ekkor. Amit ma nem dokumentálunk, azt holnap sem fogjuk. Amit ma nem rögzítünk, arra holnapután nem fogunk, vagy másképpen fogunk emlékezni, viszont ami a legmegrázóbb, amikor veszekedni kezdünk egymással, nem áll majd rendelkezésre olyan írás, ami alapján rendet tehetünk a fejekben és a feldúlt lelkekben. A „Szállított termékek” meghatározása sokszor elfelejtődik. Itt elsősorban az olyan dolgokra gondolunk, amelyek tárgyiasulnak és átadás-átvételre kerülnek. Informatikai projektek esetén például a program, az alkotó modulok felsorolásával, a licencek, dokumentációk, egyedi fejlesztés esetén a tervezési dokumentumok, tesztelési tervek és ne feledkezzünk meg rendelkezni a tulajdonjogokról, a harmadik félnek történő esetleges átadás feltételeiről. Bár nem egyszerű feladat, jó, ha meg tudunk állapodni a termék elfogadásának feltételeiről is. Csak egy példát említve a szerződő feleknek általában teljesen eltérő elképzelése van a szükséges dokumentáció mennyiségéről és minőségéről. PROJEKT SZERVEZET A PAD-ban a helye, de megér néhány kiemelést. Általában a tervezéskor könnyen jutunk túl ezen a részen. Legfeljebb a látványos megjelenítéssel bíbelődünk egy kicsit. Majd a gyakorlatban ébredünk rá, hogy alulméreteztük a szakmai csapatok létszámát. Nem biztosítottuk a hatékony projektvezetés személyi feltételeit, gyenge, döntésképtelen szervezetet alkottunk, nem gondoltuk át igazán, hogy a Projekt Irányító Bizottságba kit is kell delegálnunk. Az utóbbi esetében arra hívnánk fel a figyelmet, hogy azoknak a vezetőknek van itt a helye elsősorban, akik a projekt megszületésekor is segédkeztek. Sok félreértést, magyarázkodást kerülhetünk el később, ha így teszünk. Az is friss tapasztalatunk, hogy a hosszan tartó, bonyolult projektek esetében már a kereskedelmi fázisban érdemes bevonni a későbbi projektvezetőket. Sokkal inkább magukénak fogják érezni a feladatot, sokkal hatékonyabb lesz később a munkájuk, mert ismerhetik az előzményeket. Fontos tudniuk, mi miért van, hogyan alakult, változott, fejlődött a projekt terve. IME VI. ÉVFOLYAM 3. SZÁM 2007. ÁPRILIS 49 INFOKOMMUNIKÁCIÓ INFORMÁCIÓS RENDSZEREK PROJEKT TERV Lapos, elcsépelt poénnak tartjuk a mondást: „A projektterv arra való, hogy legyen mitől eltérnünk.” Igen, de miért az a mindennapi tapasztalat, hogy egy éves projekt során kétszer-háromszor is az élethez kell alakítanunk terveinket? Pontosabban, hozzá kell igazítani a tervet a már nyilvánvaló csúszásokhoz. Újra és újra. Mit csinálunk rosszul? Lehet, hogy már a tervezéskor is tudjuk, hogy lehetetlen lesz tartani a szoros határidőket, csak még nem merünk szembe nézni ezzel? Hogy nézne az ki, ha már az induláskor leírnánk: bizony késni fogunk! Pedig legyünk őszinték, az első módosítás magyarázata többnyire ez. Annak érdekében, hogy versenyben maradjunk vagy, hogy legyőzzük ellenfeleinket, bevállaljuk a lehetetlent, abban bízva, hogy biztos lesz majd mód a módosításra. És persze többnyire van, mert az ügyfél is tudja, nem volt reális, amit kért. Jobbik eset, ha csak az ütemezésen, a mérföldköveken kell változtatni, nem szükséges a végső határidő módosítása. Ez utóbbit többnyire a kötbér segítségével is próbálja betartatni a megbízónk. A második és további módosítások oka már sokrétűbb. Gyakori probléma, hogy az ügyfelünk késik a dokumentumok jóváhagyásával, akadályozva ezzel a továbbhaladást. Mit tehetünk ez ellen? Gyakori, többé-kevésbé bevált módszer, hogy a projekt alapító dokumentumban rögzítjük a megbízó teljesítéseire vonatkozó határidőket. Ha ezeket nem kötbérezzük – amit nem egyszerű elfogadtatni a másik féllel – akkor jó eséllyel nem számíthatunk a betartásukra. Az általunk javasolt módszer olyan dokumentumok készítése, amelyek az eldöntendő kérdések esetében alternatívákat tartalmaznak, megjelölve az általunk elfogadásra javasoltat. Amennyiben ügyfelünk a kért határidőre nem véleményezi az átadott anyagokat, elfogadottnak tekintjük azokat, az általunk javasolt verzióban. Mi a legfőbb oka annak, hogy az ügyfelünk sem képes tartani a megállapított határidőket? A MEGBÍZÓ BEVONÁSA, ÉRDEKELTTÉ TÉTELE A TELJESÍTÉSBEN Az egyik legfontosabb tapasztalatunk, hogy a projektek sikere jórészt azon múlik: a megrendelő mennyi erőforrást tud felszabadítani és egyértelműen, bizonyítottan a projekthez rendelni. Leggyakoribb gond, hogy mégoly fontos projektek esetében sem áll rendelkezésre megbízói oldalon egy függetlenített projektszervezet. A napi feladatok mellett, túlmunkában, csekély plusz juttatásért végzi munkáját a legtöbb kulcsember. Tehát ha nem tudunk csak a projekttel foglalkozó csapatot felállíttatni, akkor nagyon fontos, hogy a motivációt biztosítani tudjuk. Mondjuk ki! Jól meg kell fizetni azt a temérdek plusz munkát, amit elvárunk a kulcsembereinktől. Ennek biztosítása nem egyszerű feladat, akkor járunk el leggondosabban, ha már a projekttervezéskor biztosítjuk ezeket feltételeket. Ha nem tudjuk, gondoljuk meg: igazán meg akarjuk valósítani a projektet? 50 IME VI. ÉVFOLYAM 3. SZÁM 2007. ÁPRILIS FELADATMEGHATÁROZÁS – RENDSZERTERV – KONCEPCIÓ TERV Elöljáróban leszögeznénk azt az álláspontunkat, hogy komoly hibának tartjuk az informatikai fejlesztéssel, programbevezetéssel foglalkozó projekteket csak az informatikusokra bízni. A jelentősebb ilyen jellegű munkák általában alapjaiban fordítják fel vagy kellene, hogy felfordítsák az érintett szervezetet. Hiszen ezek a munkák valamilyen fontos, kiemelkedő szervezeti cél érdekében történnek. Sajnos, elsősorban takarékossági okokból, „kiment a divatból” a folyamatok újragondolása, a szervezet átalakítása, a változáskezelés. Ha ismét visszahoznánk és megfelelően a helyére tennénk ezeket, sokkal sikeresebbek lehetnének a projektjeink. Másik, új keletű hiba, hogy sok projekt informatikai szempontból „fejnehéz” lesz. A szervezet első számú vezetői a tervezéskor nem fordítanak elegendő figyelmet a célok, feladatok meghatározására, az informatikusok „átveszik a hatalmat”, ők határozzák meg a fő irányokat, sajnos többnyire rosszul, szűklátókörűen. Bár a jó szándék sokszor nem vonható kétségbe, a hozzá nem értés, az egyoldalúság, a „szakbarbárság” rossz irányba tolja az ügyeket. A régebbi gyakorlatban a feladat kiírásához tartozó műszaki melléklet, az ezek alapján elkészíthető fizikai és logikai rendszerterv megfelelő alapdokumentumai voltak egy informatikai fejlesztésnek, bevezetésnek. Ma már a kiinduláshoz szükséges dokumentumok többségét is a vállalkozók készítik. Sajnos. Elmarad a megbízó oldalán az az értékes előkészítő munka, amely során, még a leendő megvalósító befolyásától mentesen, kiforrnak a gondolatok, lebonyolódnak a szükséges viták, megszületnek a jó kompromisszumok. A tanácsadók csillaga is hanyatlóban van. Pedig rájuk nagy szükség van, ha igazgatás-rendészeti rendszertervet vagy ezzel ekvivalens dokumentumot kell készíteni, illetve amikor ezeket le kell bontani koncepciótervvé, logikai rendszertervvé, vagy használati eseteket kell belőlük – a jól érthetőség érdekében, lehetőleg minél nagyobb számban előállítani. KOCKÁZATKEZELÉS A kockázatok számbavételére, minősítésére, valószínűségük meghatározása, az elkerülésükre tervezett lépéseink átgondolására még a tervezés idején érdemes figyelmet fordítani. Majd folyamatosan figyelemmel kell lenni a bekövetkező változásokra, hasznos, ha a projektértekezleten is értékeljük ezeket. Fontos a karbantartás, a változatos figyelemfelkeltés, mert a mégoly komoly kockázati tényezők veszélye is megkopik, ha csak ismételgetjük azokat. Megfontolandó, hogy akár harsányan színezett táblázatos formában is megjelenítsük a vezetők számára ezeket az információkat. Arra is ügyeljünk, hogy csak a valóban lényeges dolgokra összpontosítsunk, a kevésbé érzékeny kockázatokat a napi operatív tennivalók között kezeljük. INFOKOMMUNIKÁCIÓ INFORMÁCIÓS RENDSZEREK MINÔSÉGBIZTOSÍTÁS Sokan ezt a munkát is „afféle úri huncutságnak” tartják, kétségbe vonják valódi hasznosságát. Van alapja a vélekedésnek, az utóbbi időben sokan lejáratták ennek a munkának a becsületét vagy félreértették a szerepét. Magunk úgy gondoljuk, a jó minőségbiztosító aranyat ér. Mikor jó? Ha azt csinálja, ami a nevében van és ezt esősorban segítő, jobbító akarattal teszi. Leggyakoribb hiba, amikor a megbízott csak látszat-tevékenységet végez, ha a minőségbiztosító „pálya széléről” kiabál be. Annak érdekében, hogy ez a szerepkör valóban hasznára legyen a projektnek, javasoljuk a lehető legnagyobb mértékű sikerdíjas szerződés megkötését a minőségbiztosításra felkért vállalkozóval. PROJEKTDOKUMENTÁCIÓ Saját gyakorlatunkból a folyamatos projektnapló vezetésének hasznosságára hívnánk fel a figyelmet. Kevés olyan adatot rögzítsünk, aminek leírására mindig lesz időnk, de ügyeljünk a folyamatosságra, ne hagyjunk ki egyetlen eseményt, akciót, megbeszélést, akár fontos telefont, levelezést sem. Említeni sem kellene, de magunk is gyakran elkövetjük azt a hibát, hogy a teljesítésigazolásokat nem készítjük el akkor, amikor a teljesítések megtörténnek. Érdemes ehhez szigorúan ragaszkodnunk, még ha ez vaskos hiba- vagy nem megfelelőségi listával együtt történik is. Az ügyféllélektan olyan, hogy később, amikor már jobban megismeri a rendszert és új elképzelései, ötletei vannak, előbb szeretné megvalósulni látni azokat is, és csak azután adná ki a teljesítésigazolást. „Kedvenc” idézetünk ennek alátámasztására az „ezt egy valamire való rendszernek tudnia kell” mondat. Ennek kezelése más feladat, amelyet változáskezelésnek hívunk. VÁLTOZÁSKEZELÉS Ezt a cselekménysort meg kell különböztetünk attól, amit pontosan ugyanígy nevezünk, de a szervezetfejlesztése, átalakítása során fellépő változások menedzselését értjük alatta. Amit itt értünk változáskezelésen, az az eredeti elképzelésektől jelentősen eltérő, elsősorban új igények megvalósítását jelenti. Első feladatunk ennek kapcsán, hogy mindenkiben tudatosítani szükséges: nem hibáról, hanem valami újnak a megvalósításáról van szó. Ennek érdekében ez is olyan dolog, amit már a PAD-ban érdemes pontosan definiálni. Mit értünk új igény alatt? Kik, hogyan döntenek elbírálásukról? Hogyan történik a megvalósítás? Nem utolsó sorban: ki, miből állja a költségeket? Az sem haszontalan a véghatáridő tarthatósága érdekében, ha előre behatároljuk a megvalósításra kerülő új igények számát, költségkeretét. KOMMUNIKÁCIÓ ÉS PROJEKTMARKETING Sokszor elmondtunk már, hiába, egy projektet legalább háromszor kell „eladni”, és általában „hátradőlünk”, ha megvolt az első, megkötöttük a szerződést. Pedig a megbízó elégedettsége ettől a perctől kezdve általában folyamatosan csökken. Ahogy szembesül azzal, hogy nem pontosan azt kapja, amit megálmodott, kezdődhet a második „eladás.” A harmadikra pedig akkor kerül sor, amikor a felhasználók tömegeit kell meggyőzni, hogy a menedzsment jól döntött, jót választott. Döbbenten tapasztaljuk, hogy ennek az eladásnak az intézményes lehetőségét, például egy program bevezetésénél a felhasználók oktatását mennyire rosszul használjuk ki ebből a célból. Hit és meggyőződés nélküli oktatók „nyomják” le az anyagot, csak, hogy ezen a fázison is túl legyenek. Ha tehetnénk, mi ennek a munkának egy részét is a kereskedőkre bíznánk. Félreértés ne essék! Nem azért, hogy „marketingszöveggel tömjék a hallgatóság fejét”, hanem azért, hogy valódi, szakmai kérdésekkel szembesüljenek és jól felkészült szakértőkkel fogadtassák el a terméküket. Beszélgetni, tájékoztatni, minden lehetséges alkalmat megragadni! Tisztában kell lenni azzal, hogy amit mi tudunk, azt nem biztos, hogy minden érintett tudja vagy számukra nem olyan fontos az ügy, a projekt sikere, mint mi azt hisszük. Nem vonjuk kétségbe a sok tapasztalatra és elméleti kutatásra alapozott módszertanokat, de azok testreszabását, az adott feladathoz való illesztést elengedhetetlennek tartjuk. A nemzetközi szakirodalomban jól ismert és sokszor favorizált eljárások esetében is szükség van folyamatos elemzésre, visszacsatolásra és az egyedi problémák megoldásában a projektvezetés kreatív gondolkodására. Sok esetben pedig a józan ész diktálta, kézenfekvő megoldásokat tartjuk a legjobbnak. A SZERZÔ BEMUTATÁSA Pipis László a Budapesti Műszaki Egyetem Villamosmérnöki szakán végzett. 10 éve foglalkozik informatikai rendszerek tervezésével, bevezetésével, ezek minőségbiztosításával és auditjával, többek között felsőoktatási területen. Számos pénzintézetnél vezetett üzletmenet folytonossági terv kidolgozására irányuló projektet. Jelenleg a HUMANsoft Kft. programmenedzsere, aki a HEFOP 4.4 program keretében megvalósuló egészségügyi intézményi informatikai fejlesztésért felel a dél-dunántúli régióban. Fehér András bemutatását lapunk V. évfolyamának 9. számában olvashatják. IME VI. ÉVFOLYAM 3. SZÁM 2007. ÁPRILIS 51
