HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

Techrepublic cikk alapján.

Techrepublic cikk alapján.

A Techrepublic cikk 6 fő okot említ, amibe egy IT projekt belerokkanhat.

Ezek:

Szándék hiánya – Amikor a projekt nem hoz elég hozzáadott értéket vagy előnyt hogy ledöntse az előtte álló akadályokat. Ez azt sugallja, hogy a projektre irányuló szándék az elejétől kezdve hibás volt.

Szponzor hiba – Amikor a projekt gazdája nem eléggé aktív vagy nincs meg a jogköre a projekttel kapcsolatos fontos döntéseket meghozni.

Design vagy Scope hiba – A projekt hatásköre nem lett rendesen meghatározva, ezért a projekt csapat bizonytalan a leszállítandókat illetően.

Kommunikációs hiba – Amikor keveset kommunikál a projekt, vagy ha hiányzik a problémák őszinte megbeszélése.

Project módszertani hiba – Amikor lehetőség van a projekt módszertan vagy a folyamat kikerülésére, így a folyamatból adódó kockázatcsökkentő lépések nem érvényesülnek / nem használják őket.

Beszállító hiba – A beszállító kapcsolat nem tesz lehetővé kommunikációt és változtatásokat.

Amiket én szoktam csinálni ezek kivédésére:

Szponzor: Nem indítok projektet anélkül, hogy ne tisztáznánk, ki a gazdája. Nagyon fontos, hogy a megfelelő szinten a megfelelően nagy embert találjuk meg. Amíg nincs gazdája a projektnek, addig nem is igazán komoly az egész, addig nem több mint „gondolat kezdemény”.

Szándék: Amint tisztázott a szponzor személye, nekiállok kukacoskodni, hogy jelenjen meg írásban a projekt célja és az elérendő előnyök. Ezt eddig mindenki felesleges bürokratikus lépésnek tekintette, hiszen ebben a fázisban inkább mindenki a megoldásokra és a kreatív ötletekre szeret összpontosítani. Pedig hiába szedjük össze a jobbnál jobb ötleteket, ha az alapokat nem tisztázzuk, azaz kinek miért mennyire lesz jó ez az egész.

Scope: Általában a projekt tagok szeretnek rögtön belecsapni a lecsóba, és minél előbb nekiállnak a projektet megvalósítani. Pedig előtte tisztázni kellene: milyen feltevésekre alapozunk, mit fogunk leszállítani, és mit nem fogunk leszállítani. Ez nagyon hosszú és unalmas munka. Pedig jobb ezekről addig vitatkozni, amíg egyetlen kapavágást sem tettünk meg. Nagyon sok felesleges munkától spóroljuk meg magunkat.
Ugye mindenki átélte már, amikor a munka majdnem kész, aztán jön valaki, hogy nem is ezt kellett volna, nem is úgy, illetve hogy ezt és azt még bele kellene tenni a projektbe hogy jó legyen. Lassan járj, tovább érsz!

Kommunikáció: Sokan hiszik azt tévesen, hogy ha halad a projekt, akkor nem kell kommunikálni. Kommunikálni mindig kell! A projekt tagok számára fontos tudni, mi hogy áll. A projekt manager tudni akarja, hogyan áll a projektje. A Szponzor tudni akarja, hogyan áll a projektje. A többi üzleti funkció, akikre majd kihatással lesz a projekt, tudni akarják, mit várhatnak és mikorra.
Mert ha nem kapnak rendszeres és megbízható információt, akkor elfelejtik, félreértik, téves elképzeléseik lesznek. Legrosszabb esetben valaki más ugyanezen probléma megoldására indít egy párhuzamos projektet.

Módszertan: Már szó volt róla – bár sokan a módszertant lassító és felesleges adminisztrációnak tekintik, valójában a módszertant követő projektek gyorsabban teljesítenek. A módszertan nem más, mint az eddigi projektek és Projekt Managerek összegyűjtött, konszolidált, letisztított bölcsessége. Bolondság lenne nem alkalmazni. Igenis lehet projektet hiba nélkül levezényelni az elejétől a végéig, ha az ember pontosan tudja, mit hogyan fog csinálni.

Beszállítók: Mindig minden beszállítóval jó kapcsolatra törekszek. A kapcsolat nem csak egy darab papírt jelent (szerződés), hanem sokkal többet. Van köztünk egy ki nem mondott megállapodás, hogy mindketten figyelembe vesszük a másik érdekeit, és biztosítunk a másik fél részére elegendő mozgásteret.
Ehhez olyan alapvető dolgokra van szükség, mint üzleti tisztesség, a másik fél tiszteletben tartása. Ja és persze tudás + tapasztalat, hiszen a munkát jól és pontosan el kell tudni végezni.
Nem robot-beszállítókat keresünk, hanem társakat egy közös cél megvalósításához, amit aztán tisztességgel megfizetünk.
Azok a beszállítók, akik nem így gondolkodnak, és nem is akarnak így gondolkodni, azok nem érdekelnek, még ingyen sem.

Címkék: it bukás projekt módszertan managament techrepublic

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr915211301

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

m 2010.02.11. 18:56:30

az alaplista nem rossz, de szerintem a Te megoldasaid megelozesen alapulnak, illetve azon, hogy mindket-harom-akarhany oldalon felelos, hozzaerto emberek uljenek, akik mind erdekeltek a projekt sikereben. Ez igy talan kicsit tul idealis ahhoz, hogy az esetek tobbsegeben igy is tortenjen. Kicsit szelsoseges, viszont megtortent pelda, BESZALLITOI szemszogbol (talan nem igaz, de szvsz altalaban kiszolgaltatottabbak, mert kevesbe rugalmasan tudjak kezelni az emlitett problemak nagyreszet): Egy darabig nincs baj - de aztan menet kozben valtozik a szponzor (az eredeti belso helyezkedes/felti a segget/stb miatt "kihatral" a projekt - es a felelossegviseles- alol), az uj "szponzorra" gyakorlatilag ra van eroltetve a projekt, O nem akarta, keson kapta meg, sot, a sajat hataskoreben sem biztos (szponzor problema), nem igy akarta (szandek problema), es nem pont erre akarta (scope problema) - ez egy olyan specialis helyzet, ahol egyszeruen azon fugg a tuleles, hogy a valtozasokat _minden_ oldal kezelni tudja-e, illetve az egyenek motivaltak-e, hogy ezt tegyek. A kommunikacio ilyen esetben letfontossagu, de a beszallito egy ponton tul csak sertodessel eroltetheti tovabb, sot, megfelelo meretu piros gomb nyomkodasa nelkul meg talan azzal sem. Peldaul hogyan tudsz surgosen motivalni valakit - beszallitoi oldalrol -, aki a projektnel (es a ceg erdekenel) fontosabbnak tartja a "politikai helyezkedest" (azaz: egy esetleges bukas eseten minel kevesbe lehessen osszefuggesbe hozni ot a projekttel)? Hogy tudod ezt megtenni anelkul, hogy a kezbe harapj, amelyik etet (nem a cegvezetes/anyaceg beszallitoja vagy, hanem olyan osztalyoke es vezetoke, akik eppen orulten probalnak nem lathatova valni a projekt kapcsan? :) A konkret esetben ketszer tortent komolyabb eszkalacio, a masodiknal "botrany" is lett (etsd: valsagertekezlet a felsovezetes irodajaban, a kockazatrol mar az anyaceg is tud; a szponzor azonnal megbetegszik/balesete volt/szorosan rogziti a fejet a nyakahoz, a 'seppuku' google-talalatainak szama meredeken emelkedik, stb), es itt egy idore a ceg felsovezetese vette kezbe az ugyet, az eredeti szponzor, es annak fonokenek feje felett atnyulva (beszallito szamara: az ertekezlet hatasaitol fuggetlenul eletbe lepnek a kezbe harapas minositett esetenek velejaroi). A projekt innentol a felsovezetes szemei elott tortenik, a szponzor(ok) felelossege megkerdojelezhetetlen, a feladataik tisztazva - de a beszallito szempontjabol kisse keson. A projekt vegul egyebkent elkeszult, az eredeti scope-pal, hataridore, a feladatat tokeletesen ellatva, a kritikus helyzetet megszuntette. Mondhatnank, hogy szakmailag valoszinuleg, a ceg szamara mindenkeppen sikeres a projekt. DE. A tortenet elejen elmenekult szponzor ugyan rendkivul meglepodve konstatalja, hogy a projekt sikeresen veget ert, pedig sosem hitte volna, de mar nem O a szponzor: ebbol neki elonye nem szarmazik, az O csodaval vegyes tisztelete a beszallitonak nem er tul sokat. Az uj szponzor ugye nem akarta az egeszet, maszatolt, ezert a felsovezetesnel rendkivul kinos meetingen kellett izzadnia, a scope, a szandek, semmi sem egyezik azzal, amit, ahogy, amikor O csinalt volna a projekt kereteben. Szamara a projekt bukas, a beszallito pedig darts tablara valo, nem szerzodes masik vegere. A felsovezetes erzesei lenyegtelenek (es felderithetetlenek), a beszallitokkal nem ok foglalkoznak. Igy tehat a projekt a beszallitonak vegul bukas, hiaba szallitotta pontosan azt es pontosan akkorra, amiben es amikorra megegyeztek, illetve hiaba tett meg mindent a megrendelo ceg szamara kritikus projekt megmenteseert (sikeresen). Oke, nem az a tipikus pelda - de letezik ilyen, es a legtobb atlagos projekten is elojonnek ennek az allatorvosi lonak ilyen vagy olyan reszletei - menet kozben, a legjobb szandekod vagy felkeszulesed ellenere. Viszont mindenkeppen erdekelne, most, hogy a "megelozesrol" megjelent ez a poszt, hogy szerinted (a tobbi kommentelot bevonva: szerintetek) a menet kozbeni kriziseknel vajon mik az aranyszabalyok, es mit tehet ez, vagy az az oldal, ha nincs meg az az idealis helyzet, hogy alapvetoen mindenki a projekt sikereben erdekelt?

Ismeretlen_102125 2010.02.12. 11:23:00

@M Igazad van, a megelőzés embere vagyok. Az is igaz, hogy a postjaim többsége az ideális esetről szól - mert abban a közegben, amiben vagyok, valóban így mennek a dolgok. Akadnak ugyan lusta emebrek, inkompetens szakértők, nehéz esetek, de megoldjuk. Ha nyugodtan akarsz aludni, akkor csinálj mindent jól. Az ideális esetre tervezünk, és csökkentjük a kockázatát annak, hogy bármi is letérítsen erről az útról. Ha mégis krízishelyzet adódik, akkor meg kitaláljuk, hogyan lehet a legrövidebb úton visszarúgdosni a projektet az ideális ívre. Annyit még hozzátennék, hogy nem alsóvezető vagyok. Ha valami gáz van, akkor nemcsak jogom van berontani a vezérigazgató irodájába, hanem ez az elvárás. Ha valakinek nincs kedve dolgozni, vagy nem így akarja, nem ezt - nagyon sajnálom, ez az ő saját problémája. Univerzális megoldás nincs krízishelyzetekre. Arra a legjobb projektvezető sem tud felkészülni, hogy autóbalesetben elhalálozik a szponzor, vagy hogy a projekt szervert terrorista támadás éri. Ezek megoldása az adott helyzettől, az adott emberek képességétől/vérmérsékletétől függ. Beszállítóként valóban igaz, hogy kevesebb a lehetőség, és nehezebben lehet eszkalálni. És az is igaz, hogy a világ legjobb IT beszállítója sem fog tudni jobb szoftvert letenni az asztalra, mint amennyire jól az ügyfele menedzseli őt. A jó együttműködéshez két fél kell: jó ügyfél és jó beszállító. Annak ellenére, hogy nincs univerzális tanács, mégis próbálok adni egyet :) Máshol azt láttam, hogy nagyon gázos projektre (beszállítói oldal) hívtak drágábbnál drágább managert, akik próbáltak ráolvasástól kezdve módszertanon át mindent. A megoldás az volt, hogy a projektet egész egyszerűen leállítottuk 1-2 hónapra. Volt egy őszinte megbeszélés az ügyféllel, mindenki megértette, hogy további maszatolásnak nincs értelme. Szóval a projekt állt, rendbe tettük az alapokat, és amikor kezdtek a dolgok normális formát ölteni, akkor újra indultunk. És jó lett. Olyat is láttam már, hogy a projekt közepén az ügyfél és a partner leült újratárgyalni a szerződést, mert menet közben megváltoztak az érdekek, a keretszámok, a határidők és az igények. A többieknek mi a véleménye?

Hesz Roland 2010.02.12. 12:50:59

Hát, én egyfelől egyetértek a poszttal, nagyon jó lépéseknek tűnnek, és láthatjuk sűrűn, hogy hiányuk hová vezet. De egyetértek M-mel, ez tényleg ideális állapot. A projekt szponzor mint olyan nagyon sokszor hiányzik, mint ahogy a projekt bajnok is, általában a "projekt mindenkié, tehát senkié" felállás alakul ki, a kommunikáció akadozik, zavarás és kozmetikázott, a szándékok illetve előnyök nincsenek konkrétan tisztázva, a beszállítókkal, alvállalkozókkal szemben pedig nem igazán partneri hozzáállás tapasztalható. Megjegyzem, sokszor viszont sem. Nincs bizalom, mindkét fél erősen csak az önös érdekeket nézi sok esetben. Ha pedig a két félből csak az egyik viselkedik tisztességesen, akkor azt erősen csőbe húzzák, legközelebb pedig már ő sem fog. Egyébként most fejeztem be Tom DeMarco : Medvékkel keringőzik című könyvét, ami a kockázat menedzsmentről szól, abban volt még egy érdekes ok a projekt bukására: Későn kezdődött.

m 2010.02.12. 14:50:33

@akocsis, "Az is igaz, hogy a postjaim többsége az ideális esetről szól - mert abban a közegben, amiben vagyok, valóban így mennek a dolgok." Ez világos, és nem is szeretnék vele vitába szállni; de nekem az eddigi kommentek alapján, és saját tapasztalatom szerint is úgy tűnik, az olvasóid többsége nem ebben a cipőben jár. Tehát egyrészt jó dolog, ha bemutatod az "ideális" helyzeteket - az ember legalább tudja, mi lenne a cél -, de önmagában ez csak "szórakoztató irodalom" - nagyon hiányzik a köztes lépcső, hogy vajon a helyi rögvalóság és az általad leírt ideális célhelyzetek között hol vannak átjárható pontok, hogyan lehet eljutni oda (azaz beszállítói és megrendelői oldal menedzseri székéből külön-külön hogyan lehet javítani az összképen adott "típusproblémák" esetén, hol és ki a leglényegesebb elem, mit tehet egy alsó- középvezető (hiszen sokan itt ülnek), hogy "politikai öngyilkosság" nélkül előbbre pattinthassa a beragadt kereket). Voltak ezeket karcolgató posztok, de igazából nem ezen van a hangsúly, pedig ez a keményebb része a problémának - pont az ezerféle kötöttségek és közel sem ideális felállás miatt, és végső soron ez adna kézzelfogható segítséget azoknak, akik mondjuk úgy, "tanácsokért" (is) olvassák a blogot. Te nyilván véggijártad ezeket a szinteket és rengeteg releváns tapasztalatot szereztél, itthon és odakint is, tehát biztosan hozzá tudnál szólni ezekhez a problémákhoz. Az egyébként kivételesen nagy pácban vergődő állatorvosi ló esetét is részben ebből a gonosz, provokatív célból hoztam fel: ez az az állapot, amit az olvasóid többsége valószínűleg jobban ismer; és bár sok a tipp és az információ a posztjaidban, az általában elsikkad, hogy ebből az állapotból hogyan jutunk abba (vagy legalább egy azt közelítő) állapotba, amit a Te megelőzésen alapuló - egyébként hasznos - javaslataid már előfeltételként kezelnek. Mert nyilván azt is el kell (és lehet) érni valahogy, lehet erőltetni, támogatni, egy pontig kikényszeríteni mindkét oldalról - viszont az olvasók többsége szvsz nincs pozícióban, hogy felülről biztosítsa, vagy nyugodt lehessen, hogy majd az ő főnökei felülről megoldják neki.

Ismeretlen_102125 2010.02.15. 17:51:12

@M A válasz túl egyszerű, nem fogsz neki örülni :) A jó Project Manager tegyen meg mindent, ami tőle telik. Ha olyan problémába ütközik, amit nem tud maga megoldani, akkor eszkaláljon a tulajdonosnak, az ügyfélnek, a főnökének vagy a Project Sponsor-nak. Ha ezek az emberek saját korlátaik miatt nem akarnak vagy nem tudnak segíteni, akkor felesleges bármiféle tanács. Ha ezek az emberek azt akarják, hogy a híd összedőljön, akkor az össze fog dőlni. És akkor hiába cserélünk eszmét arról, hogyan kell egy hidat aládúcolni - sose lesz jó. Én jól megtervezett és felépített hidakban gondolkodok, nem aládúcolt vagy összeomlóban lévőkben. Ezen gondolkodásom miatt a gázos helyekre eleve fel se vesznek - mert oda veterán tűzoltó+csodatevőket keresnek (akik valójában nem léteznek, úgyhogy a végén mindenki azt kapja, amit megérdemel).