Projektvezetési módszertan összefoglaló a projektszemlélet kialakulásához

Olvasási idő 10 perc

Biztos hallottál már a most népszerű Scrumról, Prince2-ról, vízesés módszertanról, LEAN-ről.
Esküdnek rá, hogy működik, de a valóságban meg mégsem.
Aztán jönnek a kérdések: Mitől van ez? Miért nem úgy történnek a dolgok, ahogy le van írva? Egyáltalán melyiket is válasszam? Ki a hibás? A módszertanok? A sok buzzword? A sok dokumentum? A sok könyv? …

Akkor most tegyük tisztába a dolgokat! Ebben a dokumentumban összefoglaltam, hogy mik a legfontosabb projektvezetési módszertanok, valamint, hogy hogyan használd őket.

Szakmázzunk: mi alapján válaszd ki a projekted?

Az új és tapasztalt projektmenedzserek számára egyaránt nehézkes, hogy valójában miként is kell megközelíteni a projektet. Egyes szervezetek a projektmenedzsment-iroda (PMO) keretében az összes projektet szabványosították az irányelveken keresztül, míg más szervezetek lehetővé teszik a projektcsoport számára, hogy kiválassza és testre szabja az egyedi projekthez a legmegfelelőbb megközelítést. 

Kötöttebb eset: néhány projektmenedzser kiválaszt egy módszertant, és az elejétől a végéig megköveteli az annak való megfelelést, tekintet nélkül a projekt méretére vagy összetettségére. Neked ismerős ez a szituáció?

Lazább eset: az ellenkezője is megesik, mivel vannak, akik a kevésbé szigorú megközelítést választják.

Íme a kihagyhatatlan kérdéskör a projektmenedzsment során: 

  • Mi a projekt végső célja?
  • Mennyire összetett a projekt?
  • Milyen módszertant alkalmaznak a szervezetben?
  • Vannak-e korábbi projektekből származó tanulmányok vagy eredmények, amelyeket fel lehet használni?
  • Mennyire lettek az ügyfelek bevonva a projektbe?
  • A projektben résztvevők ismerik egyáltalán a módszertant ami bevetésre kerül?

Már most az elején elárulom a módszertanok körüli hűhót: nem a módszertanokban van a lényeg egy projekt szempontjából.
A módszertan is fontos, de a kooperáció, kommunikáció a legfontosabb, mind a megrendelő, mind a szállító részéről.

Akkor meg minek a sok módszertan? Na azért várj csak, ne engedd el ilyen könnyen a dolgot!

Kezdjük azzal, hogy a projektvezetőnek a projektcsoporttal együtt kell meghatároznia a számos projektmenedzsment folyamat és gyakorlat közül azokat, amelyek a legmegfelelőbbek az egyes projekthez.

Amit nem szabad megúszni, hogy minden projektmenedzsment folyamatot precízen meg kell fontolni, hogy alkalmazható-e a projektre, avagy sem! Persze vannak örökös tagok is, amik nem elhagyhatóak, mint például a WBS (Work breakdown structure), azaz a tevékenységek, munkalebontás strukturálása.

Egy jó tanács: ha van egy, már jól kialakult módszertan, akkor azt nem érdemes elkezdeni fúrni faragni, és mindenképpen átállni pl. agilis üzemmódra. Ha valami jól működik, azt nem kell bolygatni, aztán átmenni a nagy bizonytalanságba. Ugye ahogy korábban mondtam, bezavarhat 1-2 új módszertan. Alapos tervezés nélkül elég rosszul fog debütálni, bármelyikről is legyen szó.

A projekt életciklusa – tervalapú vagy változásvezérelt?

Az életciklusokat bármelyik projektre ráhúzhatod. A projekt életciklusa határozza meg a projekt elejét és végét.
A projektek életciklusát – bizonyos variációkkal – újra felhasználhatod hasonló típusú projektek esetében. Különböző projektek életciklusait azonban nem alkalmazhatod a más-más termékek és szolgáltatások számára. Értsd: például egy épület felhúzásához szükséges életciklus nagyon eltér a szoftverfejlesztés életciklusától.

Tervalapú projekt 

Egy prediktív, azaz tervvezérelt projekt életciklusa megkísérli belőni a teljes hatókört a projekt elején. Ez a projektéletciklus akkor funkcionál a legjobban, ha tutira mész. 

A tervvezérelt nem működik jól  a “kutyaszorítóban”, azaz ahol nagy a bizonytalanság és a változás. A prediktív életciklus segítségével kielégítheted a menedzsment azon igényét, hogy kiszámíthatóságot és ellenőrzést biztosítasz a projekt felett. Itt a pikk-pakk változásoknak esélyük sincs, hiszen a projekt módosításait hivatalos felülvizsgálati és elfogadási folyamat irányítja.

Változásvezérelt projekt 

Az iteratív projekt életciklusa az, amikor a végterméket vagy szolgáltatást ismételt ciklusok sorozatán keresztül fejlesztik ki . Míg a növekményes inkrementálás projekt életciklusa egymást követően növeli a végtermék vagy szolgáltatás funkcionalitását. Az iteratív és inkrementális projektéletciklusok általában akkor előnyösek, ha a projektcsoportnak a változó célokat és követelményeket kell kezelnie a projekt bonyolultságának csökkentése érdekében.

És ezt még tovább lehet csavarni.

A projekt növekményes életciklusa a prediktív projekt életciklusának variációja. Feltételezhető, hogy az egyes növekményes kiadások vagy fázisok teljes hatóköre abszolút meghatározható, mielőtt végrehajtanák a kiadást.
Egy iteratív projektéletciklusnak általában kisebb funkcionalitási egysége van, mint egy inkrementális esetében. A következő iteráció tervezését úgy kell végezni, hogy a munka a jelenlegi iteráció hatókörén és teljesítménye szerint haladjon előre, és ez lehetővé teszi a projektcsoport számára, hogy fokozatosan építsen ki bizonyos szintű funkcionalitást, részeket, amely fokozatosan épít a végső végtermékbe.

Egy adaptív változásvezérelt életciklus reagál a magas szintű változásokra és az érintettek folyamatos bevonására. Az adaptív módszerek hasonlóak az iteratív / növekményes életciklushoz, de akad különbség is, pl. hogy az iterációk nagyon rövidek, általában 2-4 hetes időtartamúak, továbbá rögzítik méretüket és költségeiket. 

Az adaptív életciklus során a projektet rövid iterációkkal hajtod végre, és ez a mód rugalmasan alkalmazkodik a projekt követelményeihez, változásaihoz. Minél kevésbé ismerik a projekt végfelhasználói a követelményeket, annál jobban alkalmazkodnak a projektcsoport igényeihez.

A szponzort és az ügyfelek képviselőit folyamatosan be kell vonni a projektbe, hogy visszacsatolást nyújtsanak az eredményekről, és hogy azok biztosan tükrözzék az igényeiket.

Ismerkedj meg a leghíresebb módszertanokkal! 

PMBOK (Project Management Body of Knowledge)

Rögtön egy kakukktojás, mivel ez inkább egy összefoglaló arról, hogy mi szerint kellene haladnia a projektnek. Tudod: kezdeményezés, tervezés, kivitelezés, megfigyelés és ellenőrzés, zárás. PMBOK egy könyv, ami kiváló alap, de irtózatosan száraz. Ám ha nem rettentél el és szeretnéd pontosan, precízen tudni, hogy hogy kéne lennie a folyamatoknak, akkor hajrá! 

PRINCE2 (PRojects IN a Controlled Environment)

Na, ez már egy módszertan, mely előre meghatározott folyamatokon keresztül viszi végig a projekt lépéseit. Módfelett alapos keretrendszert biztosít, a nagy valószínűséggel megjósolható és bekövetkező (predictable) eseményekre fókuszál. 

A projektet folyamatosan felülvizsgálják, hogy kitapossák a célok teljesülésének útját, amelyek gyakran változnak a projekt életciklusa alatt.

Jól illeszkedik a hierarchikus szervezeti struktúrához, mivel irányítás- és ellenőrzéscentrikus.

A PMBOK-hoz hasonlóan van egy szókészlete. Míg az alapelvek és a témák nagyon sok mindent lefektetnek, addig a folyamatok hosszúra nyúlhatnak. Kis projekt esetén nehezen alkalmazható a merevsége miatt.

Tudtad, hogy van PMP (Project Management Professional) illetve PRINCE2 képzés és vizsga?

Vízeséses módszer

A módszerrel a projektet előre megtervezik, majd merev sorrendben, a követelmények betartásával hajtják végre, így a projekt egyetlen, általában igencsak hosszú ciklusban teljesül. Az elvárásokat teljes egészében a projekt elején szögezik le. Egy fázist be kell fejezni, mielőtt egy következő megkezdődne, és a fázisok között nincs átfedés. 

Ha már a tesztelési szakasz jött el, akkor felettébb nehéz visszamenni és megváltoztatni valamit, amelyet a koncepció szakaszában nem fejlesztettek ki jól. Mint tudjuk, ilyen típusú projektek esetén jó, ha időközönként a megrendelő ránéz a projektre, és nem csak a végén.

A vízesés kiszámítható megközelítést ad, de abban az esetben célszerű alkalmazni, ha a követelmények rögzítve vannak, jól dokumentáltak és egyértelműek, a technológiák rendelkezésre állnak, valamint nincs változtatás a fejlesztés közben.

Agilis módszertan helyett agilis projektszemlélet legyen!

Az agilitást, mint gondolkodásmódot érdemes először elsajátítanod. Ha ez hiányzik, oda az agilis projektszemlélet!  Erről itt találsz egy bejegyzést: Az Agilis Kiáltvány, és ahogy az alkotók érthették.

Az agilitásban a legfontosabb a változásra való nyitottság, tanulás és kommunikáció. Ahogy korábban már sugalltam, ebben az írásban nem a módszertanon van a lényeg (emlékszel mik azok, amik a módszertannál is fontosabbak?), hanem a gyors környezeti változáskra való reagáláson illetve a lehetséges megoldások válaszán.  

Először is egy agilis és egy hagyományos projekt közötti különbség összehasonlítását láthatod. Általában ezt a két megközelítést ismerik a legjobban. Sok agilis szakértő dobálja a buzzwordöket /szakzsargon/,  pedig ha el tudnák mondani hétköznapibb nyelven… /Itt több infó van róla./

Iparágtól függetlenül találod az összehasonlítást, hiszen az agilist lehet szoftverfejlesztésen kívül is használni, és mint tudjuk, az IT-n túl is van élet.

JellemzőkKlasszikus projekt Agilis projekt
Fejlesztési lépcsőkLépcsőzetes, előre meghatározott fázisokSok kis rövid idejű sprintek,különböző elemek később is belekerülhetnek
Változtatás lehetősége, új funkciók integrálásaLehetséges, de nagyon sok energiaGyakori és könnyen lehetséges a hátraléklista alapján
Csapatok nagyságaNagy csapatok koordinálásaKisebb csapatok 6-8 fő
Mikor kommunikál az ügyféllel?Leginkább mérföldkövek esetén van visszajelzéspl. 2 havontaBármikor, de kéthetente legalább, amikor bemutató van
CsapatmunkaA csapatnak megadják a fő irányt, és ezt gyakran felügyelikA csapat önálló 
Vezető szerepeIrányítja a csapatotTámogatja a csapatot
Megrendelő felé kommunikáció (belső, külső)A projekt elején előre leegyeztetett időközönkéntGyakori, akár hetente
Dokumentáció, szerződésElőre lefektetett, kijelölt irány, merevFontos, de van benne rugalmasság
VeszélyeNem tud reagálni gyorsan a változásokra.Egy-egy változás nagy hatással lehet a kimenetre; ha változik az igény,
az a rövid időtávok miatt mégis könnyen kezelhető
Fő különbségMinden apró részletet előre lefektetnek, alapos tervezés megy végbeNincs egy előre mereven meghatározott forgatókönyv. Kis lépésenként halad a fejlesztés
Mikor jó használni?Bejáratott fejlesztési lépcsők során;Nagy komplexitású projektek eseténGyorsan változó közegben, változékony vevői igények és visszajelzések alkalmával;
Alacsony komplexitás során;Startupok esetében

Az agilis módszertanról itt több mindent megtudhatsz. Vigyázat, azért nem csodaszer!

SCRUM

A Scrum módszertanban egy iteratív fejlesztési ciklust sprintnek neveznek. Az adott sprint során – ami 2-4 hét között lehet -, a megvalósítandót “product backlog”-nak vagy sprint teendőlistának hívják. Lényegi pontja, hogy gyorsan kell alkalmazkodni a vevői igényekre. 

KANBAN/SCRUMBAN

Itt találsz részletesebb anyagot.
A lényeg: a kanban jelentése kártya, jel, tábla, azaz vizuális megjelenítés.
Rugalmasan lehet követni a megrendelői igényeket. A Lean szerint a Pull, azaz a húzóelv érvénybe lép, ha bármiféle termékre, folyamatra igény áll fenn. Abszolút leegyszerűsítve pedig azt mondhatjuk, ha el kell végezned egy feladatot, ezt vizuálisan láthatóvá teheted.

A kanban korlátozza az egyszerre folyamatban lévő feladatok számát, azaz a WIP kártyákat. (work-in-progress)
A folyamatba ne engedj be több munkát, amíg nincs kész az egyik! Így korlátozni tudod, hogy ne csak ott legyenek a feladatok, hanem végezd is el őket.

A scrumban használt kanban viszont nem korlátozza az egyszerre elvégzendő feladatok számát.
Ott nagy hangsúlyt kíván a csapattal való tervezés.

KVP, LEAN, Six Sigma

Ezek a módszertanok se maradjanak el!  KVP-vel kezdünk, mert így épül egymásra a rendszer.

KVP/KAIZEN

Valószínűleg már Te is találkoztál a kifejezéssel, KVP (Kontinuierlicher Verbesserungsprozess), azaz folyamatos folyamatfejlesztés, napról napra.
Egy workshop keretében a probléma például: átfutási idő csökkentése, kommunikáció javítása, megfogalmazására kerül sor, majd a megfogalmazott elleintézkedések felülvizsgálatra kerülnek, hogy haladnak-e, alkalmazzák-e a kijelölt folyamatokat.

A Kaizen a folyamatokat szüntelenül kis lépésekben fejleszti és javítja. Ez a módszer a cég összes dolgozóját igényli, tehát mindenki hozzáteszi a részét a folyamatok javításában. A módszer alkalmazása egy hosszú távú szemléletmódot tesz lehetővé.
A KVP-n belül alkalmazható a PDCA ciklus, amiről itt tudsz többet olvasni.

LEAN Menedzsment

Elég sokan ráhúzzák, hogy e szerint dolgoznak. De biztosan jól ismerik?

Először is a célja, hogy a vállalat gazdaságosabban állítsa elő a termékeit, szolgáltatásait úgy, hogy csak arra fókuszál ami a vevőnek érték, magyarán az értékteremtés a lényeg.

A LEAN a kulcsa a projekt-felülvzsigálatok esetén, hogy hogyan lehet a folyamatokat optimalizálni ha eltérésre kerül a művelet a normálistól, újra visszairányítani a megszokott kerékvágásba, hogy a vevő számára csak értékteremtés legyen.

Menni fog, mint a karikacsapás, ha a LEAN gondolkodásmód elterjed a csapatban. Az a cél lebegjen mindenki előtt, hogy árgus szemmel figyelje a folyamatait, így a lehetséges veszteséget, túltermelést el lehet kerülni.

Seregnyi eszköz áll rendelkezésedre a LEAN menedzsment eszköztárában, amiket töretlenül érdemes használni és mérni az eredményeket.

Ha jobban beleásnád magad a LEAN mendzsmentbe, akkor itt olvashatsz róla. 

SIX Sigma 

Gyártásban terjedt el először, de már az IT is használja. Alkalmazásának feltétele, hogy rendelkezésre álljanak a mérőszámok. Az adatvezérelt módszer miatt nagy jelentősége van. Mérhető az előtte és az utána állapot. Az adatvezérelt döntés lesz valószínűleg 2020 után az egyik új buzzword, készülj fel rá! Tehát minden ami mérhető, mérni is kell, de a nehézsége is ott rejlik, mivel a sok adat közül leginkább számokat kell mérni és kiértékelni.

A Hat szigma, vagy angolul Six Sigma standard, ami 3,4 hibát jelent egymillió hibalehetőségre.

DMAIC ciklusból áll, aminek a jelentése: 

Definiálás – Define – Probléma megfogalmazása
Mérés – Measure – Mérd meg a problémát
Analízis – Analyze – Analizáld, hogy mi okozza a hibát
Fejlesztés – Improve – Javítsd ki azokat 
Kontroll – Control – Felügyeld a hiba körüli folyamatokat

A Six sigma módszer használata számos fontos mérföldkövet jelent a projekt megtervezési és haladási szakaszában.
Egy Six sigma projekt első lépése a probléma és a projekt kívánt eredményeinek meghatározása. Ez a lépés nagy figyelmet igényel a projekt megtervezésekor.

Hogyan válaszd ki a megfelelő módszertant?

Minden projekt egyedi. Vagy nem? Attól függ.

Terveken alapuló projektmegközelítés esetén, például ahol jelentős kockázatok vannak, szigorú előírások, üzleti veszteség stb., ott a  tervvezérelt projektmenedzsment megközelítést kell alkalmaznod, amely magában foglalja a további tervezési, valamint ellenőrzési tevékenységeket, amelyek már beváltak.

Néhány projekt viszonylag egyszerű és kiszámítható. Mások nagyon bonyolultak és kockázatosak. Mindegyik eltérő megközelítést igényel a projekt irányításának szempontjából. Ugyanazon projektmenedzsment módszer alkalmazása minden projektnél felesleges lehet. Ennek ellenére sok szervezet és projektmenedzser eltérés nélkül alkalmazza a projektmenedzsment dogmákat, ahelyett, hogy erőfeszítéseiket megfelelően testre szabnák. 

A projektmenedzserek gyakran megkísérelik egy projektet arra kényszeríteni, hogy illeszkedjen egy adott módszertanhoz, mert mondjuk az a legismertebb. A projektvezetőknek ki kell bővíteni gondolkodásmódjukat, hogy elfogadják a projektmenedzsment különböző formáit.

A menedzsernek és a csapatnak a projektmenedzsment megközelítést, az üzleti környezetet, a kockázatok és a projekt összetettségét vizslatva kell testre szabnia.

Hybrid megoldás?!

Ha a projekt elsődleges célja egy innovatív, korszerűbb termék vagy szolgáltatás, akkor a projekt megvalósításának egyetlen módja egy rugalmas vagy változásvezérelt projekt-megközelítés. 

Kell a dokumentum, kell a tervezés, de a végrehajtási fázisban már rugalmasabb a projekt.

A gyorsan változó környezettel való kapcsolat kezelésekor általában a változásvezérelt, mondjuk agilis szemléletmódnak a megközelítése részesül előnyben, hiszen ilyenkor a követelményeket nehéz előre meghatározni. Éppen ezért, amikor lehetséges, a lépéseket kis, fokozatos fejlesztésekkel lehet végrehajtani, amelyek értéket képviselnek az érdekelt felek számára. 

A projekt különböző fázisokra bontása segít megkülönböztetni a különféle elvégzendő munkákat. A projekt szakaszai biztosítják a projekt teljes előrehaladásának nyomon követésére és ellenőrzésére szolgáló módszert is.

A projekt szakaszokra bontása lehetőséget kínál a projektcsoport számára a teljesítések, sőt a projekt teljesítményének áttekintésére is. Ezáltal ki lehet jelenteni, hogy a projekt céljai teljesülnek-e, avagy sem. 

A projekt szakaszai terméktől függő leírások, amelyek a termék életciklusából származnak. A termékfejlesztés életciklusának különböző fázisai vannak. Az egyes fázisok az életciklus egy meghatározott sorrendjét követik annak érdekében, hogy az életciklus következő szakaszához szükséges teljesítményeket előállítsák.

Ahogy szokták mondani, semmi sem állandó. Ez különösen igaz most a szüntelenül változó világra, melyben élünk. Azt döntsd el magad, hogy ebben a változékonyságban mit használsz munkád során. 

És hogy milyen lépések mentén érdemes haladnod, azt a projekt komplexitásából és idejéből kikövetkezdtetheted.

A módszertanok jók, DE ha nem jó a kommunikáció, koordináció, és nincs kooperáció az egész füstbe ment terv!

Ajánlatkérés, ajánlatadás, mindenki tudja mi a cél, neki áll tervezni, kalkulál, ajánlatot ad, utánkövetés, kick-off meeting… Haladunk! Ez az!
Aztán elindul a projekt, de nem a tervek szerint alakul.
Változás mindig lesz. És akkor itt jön szóba a kommunikáció.

Hidd el, a kommunikáció, a koordináció és a kooperáció a legfontosabb!


Vajon miért készült a one pager a munkában bejegyzés, vagy a képernyőkép készítése bejegyzés?
Az egész Ifjú projekttitán könyvnek is a kommunikáció az egyik legfontosabb mondanivalója a módszertanok felett.

NLP-ben, azaz a  Neuro lingvisztikus programozásban van egy nagyon jó előfeltevés.

A térkép nem a terület!

Nem tudhatod, hogy a másik mit gondol, amíg nem kérdezed meg, nem mondja!

Melyik módszertant is használd akkor?

Csak akkor kezdj el használni egy módszertant, például az agilisat, ha már érted, hogy miről szól, és milyen előnyei lehetnek. Azért ez így elég egyszerűen hangzik, nem?
Fontos és érdemes minél több módszertant elsajátítani és megérteni, de mi fontosabb azok felett?

Érti a megrendelő, hogy milyen módszertant használunk? Tudja ő is hogy mit akar? Tudja, hogy milyen lépései vannak a módszertannak? Elfogadja a projektben leírt lépéseket, mérföldköveket a projekt indulása után is? 

Hozzá kell szoknod, hogy az igények újra és újra változnak, mellette a projektben résztvevők, vezetők, döntéshozók és a prioritások is. Mindent lehet kezelni, még az ügyféligényeket is. 

Ha nem is a kilókat, de a tudást érdemes felszedned! 

Kommunikációs készségek szükségesek (és azok fejleszthetők) az együttműködéshez a sokszínű csapat tagjaival, hisz ezzel lehet bebiztosítani, hogy teljes mértékben részt vegyenek a feladatban.
Hasznos a jó kifejező képesség (fejleszthető), hiszen jól jön, ha az előrehaladásról számolsz be. Továbbá előnyös az analitikai, adatvezérelt döntés (tanulható), tervezési és szervezési ismeretek, rugalmasság.

Érti a megrendelő a módszertanodat?

Amikor a megrendelő már túl sok mindent akar, akkor jól jön a gyakori kommunikáció és a feladatlista, valamint a rövid sprintek. De ehhez érteni kell a megrendelőnek is a folyamatokat, tehát, hogy milyen módszertan alapján halad a projekt.

Itt szokott egy halom projekt rögös útra tévedni.
Kulcsfontosságú a tárgyalási képesség is, és a változáskezelés. Ha azt kéri a megrendelő, akkor helyette lesz ez.

Szoktál úgy módosítást elfogadni, hogy megcsinálom ezt, de akkor nem csinálom meg azt?! És ezt le is kell írni egy jegyzőkönyvbe. 
Vajon miért lett annyiféle jegyzőkönyv felsorolva Az ifjú projekttitán könyvben? Konkrétan emiatt – nem mintha nehéz lett volna kitalálni -, mivel a kommunikáció egyik formája.
Az agilis projektszemléletnek (nem a módszertannak) pont a kommunikáció a vesszőparipája.

A 3K minden projektben

Elindul a projekt. Meg van határozva hogyan történik a kommunikáció, ki-kivel kommunikál, mi hova lesz mentve, milyen dokumentum kerül használatra, hogyan történik a kockázatértékelés, mi alapján van change management. (Remélhetőleg volt idő ezeket elkészíteni, vagy csak a fiókból elővenni.)

Egy cégnél alap (vagy annak kéne lennie), hogy van dokumentációs rendszer.

Nincs csoda megoldás, nincs csoda módszertan, helyette kommunikáció, koordináció és kooperáció van kéz a kézben.  

Az ifjú projekttitánban jó néhány módszert megtalálsz.
RACI, Gantt diagram, jegyzőkönyv írás, és még többféle dokumentum, de a standardizált dokumentumok és gyakorlatok kidolgozása elengedhetetlen, amelyek a különféle tényezők változásának függvényében újra definiálhatók.

Egy pofonegyszerű trükk: készítsd el egyszer az alap dokumentumokat, kommunikációs tervet, alap folyamatábrákat, majd újra és újra felhasználhatod.

Összefoglaló

Azt tanácsolom neked, hogy legyenek rendben az alapok! Legyen egy folyamat kidolgozva arra, hogy ki-hogyan, mit- mikor kommunikál. Egy módszertanba nem lehet fejest ugrani csak úgy. Át kell rágni! 
Ki akarja elkezdeni, használni az új módszert? Bottom up, vagy bottom down.

Azaz lentről felfelé akarnak javítani a folyamatokon a csapatban dolgozok, vagy fentről lefelé van egy erős döntés által kell, hogy használjak az emberek a módszertant.
Remélem a módszertanokból tudam egy rövid, de átfogó összefoglalót adni számodra.

Sok módszer van, de két ugyanolyan projekt nincs.

Bármilyen jól megtervezheted a projektet, de amikor elkezdtek közösen dolgozni, akkor sokszor változnak az igények, és azt jól kell tudnod menedzselni.

Ha a vezetőség rászánja az időt egy olyan projektmenedzsment megközelítés megtervezésére, amely a meglévő szervezeti standardok, a bevált gyakorlatok és a projekt sajátos jellemzőinek kombinációján alapul, plusz legalább egy módszertan egyikét is használják, akkor hozzájárul a siker nagyobb esélyéhez.

A módszertanokról még könyveket lehetne írni, de amit a sok infó közül semmiképp se felejts el, az a megrendelő-beszállító közötti kommunikáció és kooperáció!

Csilinkó Ádám
Számos ország multinacionális projektjében vettem már részt, de az igazi szakmai és önismereti gyorsítósáv Japánban ért el, ahol 2 évig tevékenyen dolgoztam, mint projektvezető. Itt tapasztaltam meg igazán, hogy mennyire fontosak más tényezők is a módszertanok ismeretén kívül, mint mondjuk a kooperáció. Ismerj meg jobban a rólunk oldalon.
2,877RajongókTetszik