A komplex projektek világáról először egy NASA-kutatásban olvastam pár éve, amikor abban a témában kerestem anyagot, hogy van-e különbség a sikeres női és férfi projektmenedzserek képességei között. Ebben a cikkemben azt járom körül röviden, miért minősül komplexnek egy projekt, és mit jelent ez a projektvezetőre, és a módszertanra nézve.

A NASA-projektek természetét kutató Mulenburg szerint egy projekt komplexitását az határozza meg, mennyi idő van a megvalósítására, mekkora a mérete és mennyire kiszámíthatatlan a műszaki, technológiai környezet, amiben a fejlesztés zajlik. Így például, a NASA Mars-kutatásának egyik legsikeresebb űrszondája, a Mars Rover fejlesztése komplex projektnek minősül, mivel 3 év alatt 265 millió dollárból kellett elkészíteni az első olyan marsautót, amely felvételeket tudott készíteni a Mars felszínéről.

Milyen képességek kellenek ahhoz, hogy komplex projektet vezess a NASA-nál?

Mulenburg kutatása szerint minél bizonytalanabb a projektkörnyezet, amiben a megvalósítás zajlik, annál fontosabb, hogy a projektvezető érzelmileg kiegyensúlyozott legyen, határozottan kivédje a projektet érő külső „támadásokat” – akár úgy, hogy konfrontálódik -, és erős intuícióval rendelkezzen, azaz tudjon hallgatni a zsigeri megérzéseire, amikor váratlan fordulatokat vesz a projekt. Fontos az is, hogy tisztában legyen a képességeivel: amiben erős, azt tovább erősítse, amiben viszont gyenge, ott vonjon be olyan szakembert, aki kompenzálni tudja az ő hiányosságait. Ehhez kiemelkedő önismeretre és alázatra van szükség – a nagy ego komplex projektben a projekt bukásához is vezethet.

A kutatás másik fontos állítása az volt, hogy minél komplexebb a  NASA-nál egy projekt, annál inkább az úgynevezett „soft” vezetői képességek lesznek a fontosak. A projekt sikere azon fog múlni, hogyan bánik az emberekkel a projektvezető, mennyire sikeresen tud hozzájuk kapcsolódni, mintsem azon, hogy milyen műszaki szaktudással rendelkezik – a vizsgált 16 NASA projektmenedzser közül ketten például bölcsész végzettségűek voltak, köztük egy pszichológus és egy irodalmár.

Mulenburg az alábbi ábrával szemlélteti a projektmenedzser szerepét a komplex NASA-projektekben: úgy tudják strukturálni a projekt környezetét, hogy pajzsot tartva a projekt felett védik a projektet az olyan felülről jövő behatásoktól, mint például új és változó vezetői igények, más projektekből származó kockázatok, miközben oldalirányban porózusan tartják a projektrendszer határait, hogy a technikai-műszaki információk szabadon áramolhassanak a szakértők között. A projekt működtetéséhez szükséges szerepek, folyamatok és szabályok sem merevek, a rendszer belső határai flexibilisek és áteresztőek, így a napi projekt tevékenységekkel kapcsolatos kommunikáció, döntéshozás és problémamegoldás rugalmasan tud alakulni.

Milyen módszertannal érdemes komplex projekteket vezetni?

A projekt sikere számos más tényezőn kívül nagyban múlik azon is, felismerjük-e időben, mely módszertan szerint kell a fejlesztést megvalósítani. Egyik elképzelés szerint az dönti el, melyik termék- és rendszerfejlesztési módszert célszerű használni egy projekt során, hogy mennyire ismert és definiált az üzleti igény a projekt elején és mennyire bejósolható a fejlesztés kimenetele.

Jómagam elsősorban nagyvállalati informatikai rendszerfejlesztési és üzleti projektekbe láttam bele az elmúlt 20 évben, és ez idő alatt gyökeres változásokon ment keresztül a szakma: a biztos, tervezhető projektmenedzsmentből a tervezhetetlen, bejósolhatatlan és néhol kaotikus projektmenedzsmentbe. Amikor a Vodafone-nál 2012-ben elkezdtem dolgozni, még nagyrészt a hagyományos projektvezetési módszertanban gondolkodtunk, azonban az első nagy business transzformációs program során fel kellett ismernünk, hogy a klasszikus, “vízeséses” megközelítés egyre kevésbé húzható rá a rohamosan változó, egyre komplexebbé váló üzleti és technológiai környezetre.

Az informatikai fejlesztésekre adaptálva az alábbi Stacey mátrix azt mutatja, hogy minél bizonytalanabb az, hogy mit is akarunk lefejleszteni, vagy minél inkább változni fog az üzlet igény a fejlesztés során, annál inkább olyan fejlesztési módszertant kell választani, ami a bizonytalanságból fakadó kockázatokat kezelni képes.

• „Known knowns” (tudjuk, miről van szó): Hagyományos, úgynevezett „vízeséses” projektekről akkor beszélünk, amikor lépcsőzetesen, fokozatosan jutunk el az üzleti igényektől a tervezésen át a megvalósításig, egyik lépés következve a másikból. Először megértjük az ügyfél igényét arról, hogy mit kell megvalósítani, megtervezzük ez alapján a projektet, majd megvalósítjuk. Akkor célszerű ezt alkalmazni, ha tiszta a projekt célja, van idő és lehetőség mindent pontosan megtervezni és fontos az erőforrások optimális felhasználása.
• „Known unknowns” (tudjuk, hogy nem tudunk valamit): Bonyolult projekteknél ez a féle fokról fokra építkezés már nem állja meg a helyét, mert a projekt természetéből fakadóan a megrendelő(k) igényei nem világosak az elején, vagy nagyon eltérnek egymástól, illetve változhatnak a projekt során, a megvalósítás ugyanakkor még kiszámítható. Ekkor az úgynevezett „agilis” megközelítés alkalmazása a szerencsésebb. Agilis projektekben ugyanis iteratív hurkok vannak beépítve a fejlesztési folyamatba – azaz megértjük mit akar az üzlet, leszállítjuk a termék egy részét és leellenőrizzük, valóban ezt akarta-e, majd továbblépünk a termék következő elemének a fejlesztésére. Ezt a folyamatot többször is elvégezzük, főleg, ha a fejlesztéssel egy időben a megrendelő igénye is változik az egyes termékcsomagokkal kapcsolatban. Az iteratív visszacsatolás a fejlesztők és a megrendelő közt lehetővé teszi az ügyfélközpontúságot: mindig csak azt szállítjuk le, ami az ügyfél valós igénye, így kevésbé áll elő az a helyzet a projekt végén, hogy a megrendelő nem azt kapta, amit elképzelt. Az agilis projektek akkor sikeresek, ha a csapattagok között közeli és szoros az együttműködés. Jóllehet az agilis először a szoftverfejlesztés terén terjedt el, egyre inkább kiterjesztették az agilis fogalmát a teljes szervezeti működésre is. Egyesek szerint úgy érdemes az „agilis”-re tekinteni, mint egy keretrendszerre, ami magában foglalja a szervezeti kultúraváltáshoz szükséges mindset változást is.

• „Unknown unknowns” (nem tudjuk, hogy nem tudunk valamit): Előfordulhatnak olyan komplex rendszer- és szoftverfejlesztési projektek, ahol már nehézkéssé válik a projekt elején az igények pontos megfogalmazása, és bizonytalan a technikai megvalósítás kimenetele is. Ilyenkor a „scrum” módszertan használata javallott, ami az agilis termékfejlesztés egyik legnépszerűbb és leggyakrabban használt módszertana: rövidebb iterációkkal, és gyakoribb ellenőrzésekkel lehet a bizonytalanságot kordában tartani és a végtermék megbízhatóságát növelni, tudván azt, hogy a komplexitást nem lehet tervezni, és csökkenteni, inkább növekvő tendenciát mutat a projekt során.
• „Unknowables” (megismerhetetlen, bejósolhatatlan): Kaotikus projektek esetében azonban már sem a pontos igény, sem a technológiai megvalósítás kimenetele nem ismert, és a legkisebb módosítás is beláthatatlan következményekkel járhat: ilyenkor a kanban módszertannal lehet legrugalmasabban kézben tartani a projektet, és csökkenteni a kockázatokat. A kanban módszerben már nincsenek jól strukturált sprint-ek, a folyamatos megvalósításon és kockázatkezelésen van a hangsúly.

Az, hogy mi minősül „csak” bonyolultnak (komplikáltnak) és mi komplexnek, egy Vodafone-os példával tudom illusztrálni. Míg egy marketing kampány tervezése és megvalósítása a Vodafone-nál bonyolult volt a sokféle, szerteágazó összetevője miatt, egyes informatikai rendszerfejlesztések már komplexnek minősültek: hiába tartott hónapokig az üzleti igények felmérése és a fejlesztések tesztelése, a rendszerek egymásra hatásának komplexitása miatt nem lehetett minden működésbeli esetet letesztelni, így előfordult, hogy az élesbe állított fejlesztés bejósolhatatlan hibákra futott, súlyos, több tízmilliós nagyságrendű üzleti károkat okozva a cégnek.

Káosz az informatikában

Az informatikában és a projektmenedzsmentben is megjelent a káosz elmélet és a kaotikus rendszerek működési alapelveinek vizsgálata: a káosz engineering szerint akkor tudunk leginkább megbizonyosodni egy rendszer hibatűrő képességéről, ha proaktív módon, tesztrendszereken kísérletezve azonosítjuk be a rendszer gyengeségeit a projekt során, majd éles rendszeren is folytatjuk a „gyakorlást”, teljesen addig, amíg a rendszer rezilienssé nem válik, hiszen terheléskor egy kaotikus rendszer viselkedése a legkisebb behatásra megváltozhat.

Projektmenedzsmentben a káosz egy olyan állapotot jelöl, amikor az instabil projektkörnyezet miatt állandóan változik a projektterv, vagy komplett újratervezésekre van szükség a projekt során a váratlan behatások miatt. Ilyenkor válik fontossá mindaz, amit a NASA-kutatás megállapított: ha a projektvezető érzelmileg és mentálisan stabil, nem billen ki a kiszámíthatatlanná vált projektkörnyezet miatt, és erős intuíciója segítségével el tudja navigálni a projektet a céldátumig. Vodafone-os projektekben tapasztalt káosz élményeimről ebben a cikkemben olvashat bővebben: A Vodafone VUCA világa.

Felhasznált irodalom:

Mulenburg, G. (2000): The Characteristics of Project Managers: An Exploration of Complex Projects in NASA

Mulenburg, G. (2002). Gender in project managers: Are NASA women and men project managers equal?

2019.12.01

Copyright © Czifra Julianna – Minden jog fenntartva!