Üks hea halb projektijuht. Ehk ausalt rollidest, mida paljud põlgavad

Allikas: Äri-IT Sügis 2021
Autor: Olga Saddarov, BCS Itera projektijuht

Toon siin välja kõige ebapopulaarsemad rollid, millesse tuleb majandustarkvara projektijuhil aeg-ajalt asuda, sest nende vältimisel võib kogu projekt sattuda kriisiolukorda.

Olen majandustarkvara projektijuht. Tellijale partner, kasutajate nõustaja, projekti vedaja, riskide maandaja, probleemide lahendaja, info vahendaja, tiimi juht ning juhtide parem käsi.

Kuid igapäevases töös võtan ma endale ka mitmeid teisi rolle, mis ei kõla üldse nii uhkelt. Neid tiitleid paljud juhid väldivad ja seetõttu tekivadki pahatihti projektis kriisiolukorrad.

Millised on need ebameeldivad, aga samas äärmiselt vajalikud rollid?

Lootuste purustaja

• „Ei, seda suurt juurutust ei saa ühe kuuga ära teha.“
• „Ei, teie kasutajad ei saa ilma koolituseta hakkama, ka mitte väga tublid.“
• „Jah, paljude lahenduste integreerimine on potentsiaalne riskikoht ning te peate olema valmis suuremaks aja- ja rahakuluks.“

Olen kaotanud projekte müügifaasis oma veendumuse tõttu, et klient peab alustama lahtiste silmadega. Nii mõnigi nendest teise partneriga koostööd alustanud klientidest on tulnud meie juurde tagasi pooleli jäänud projektidega, mille lõpetamine käis juba palju tõsisema ajalise survega ja kori suurema eelarvega.

Riskide ja realistlike kulude arutamine on palju ebameeldivam kui roosilised müügijutud ja utoopilise lähituleviku kirjeldamine. Kuid veelgi ebameeldivam on tegeleda riskidega siis, kui need on juba päriselt kriisi tekitanud.

Liigne eelarverida?

Arendajad arendavad, konsultandid seadistavad ja testivad lahendust. Mida teeb projektijuht? Kas projektijuhi ülesanded piirduvad lepingu ettevalmistamise ja arvete väljasaatmisega? Kui nii, siis miks projektijuhtimine on nii suur kuluartikkel?

Paljud IT-partnerid ei pea sellele retoorikale vastu ja pakuvadki odavamat projektijuhtimist, mis hõlmab ainult administratiivset tegevust. Ja projektid (jälle) kannatavad.

Enamik projektijuhi tööst ei ole kliendile nähtav. Tegelik arendamine, seadistamine ja testimine ei juhtu iseenesest. Neid töid on võimalik teha ainult siis, kui tegijate ressursid on leitud ja planeeritud, ligipääsud tagatud, õiged litsentsid õigeaegselt tellitud, ja vajadusel tehnoloogiatiimi ja väliste ekspertide abi korraldatud.

Projektijuht vastutab ühtlasi eelarves ja ajakavas püsimise, samuti projektitiimi ning kliendi esindajate teavitamise eest. Ohverdades projektijuhtimiseks vajalikke tunde ja kvaliteeti, et olla „hea, odav ja igati vastutulev partner“, jäetakse need kriitilised vastutusalad katmata.

Parandamatu bürokraat

Uus kokkulepe, ametlik protokoll, muudetud lahenduse konfiguratsioon, lepingu lisa!

Dokumendid on rangelt struktureeritud, suhtlemiskanalid ja ühine inforuum lepingus fikseeritud. Lõpmatu hulk memosid, lepinguid, nende lisasid ja lisade lisasid, protsesside jooniseid, vajaduste kirjeldusi, projektiplaane ja graafikuid… See on igav ja näib justkui liigne osa, mida „bürokraatlik“ projektijuht peab usinasti kontrollima.

Kastist väljas mõtleja ja karismaatilise suhtleja asemel astub kliendi ette hoopis pedantne nohik. Kuid just see bürokraatlik lähenemine päästab olukorra, kui paari aasta pärast tekib vajadus lahenduse jätkuarendamise või integreerimise järele, kuid varem projektitiimis olnud inimesed ei ole enam kättesaadavad.

Kuri politseinik

Riskide ennetamisest ja muudatuste juhtimisest on võimalik lõpmatuseni rääkida. Kuid karm reaalsus näitab, et ka suurepäraselt planeeritud ja tugeva tiimi juhitud projektides võivad tekkida keerulised ja valusalt lahendatavad olukorrad. Näiteks kui võtmerollis tiimi liige jääb tõsiselt haigeks ning teiste koormus kasvab. Või kui kliendi juhtkond avastab ootamatult töötajate tugeva vastupanu, millega tegelemiseks ei jätku ajalist ega ka füüsilist ressurssi.

Kriisidel on palju põhjusi, kuid üldine tulemus on alati sarnane: meeletu ajasurve, finantskahjude risk ning jube pingeline keskkond, kus inimesed peavad saavutama tulemusi. Kui „hea“ ja sõbralik projektijuht ei julge või ei suuda sellises olukorras võtta jõulisemat positsiooni ning tegeleda lahendustega, võib projekt halvasti lõppeda.

Agressiivne müüja

Seda rolli ei armasta reeglina ei kliendid ega ka projektijuhid ise. Üldiselt on kõik investeeringut vajavad teemad kliendi vabatahtliku otsustamise ala. Projektijuht ei sekku otsustamisprotsessi ja aitab võimalusel tellijal ebavajalikest lisakuludest hoiduda ka siis, kui oma ettevõtte müügikasum sellest kannatab.

Kuid on olukordi, kus tellija ei pruugi kriitilise investeeringu vajadusest aru saada. Sellisel juhul on projektijuhi viisakas vaikimine kliendile kahjulik.

Hea näide on tarkvaralahenduste versioonide uuendamise projekt. Kasutajatele tundub, et vana versioon justkui ei tekita mingeid probleeme. Uuele üleminek võib olla kallis ja tekitada ebamugavusi (erinevalt sellest, et näiteks Micorosft Dynamics 365 Business Centrali versioonid uuenevad reeglina tellija jaoks automaatselt). Kui lahenduse hooldamise eest vastutav partner üritab iga hinna eest vältida „tüütu“ partneri silti, võib tellija sattuda raskesse situatsiooni. Lahenduse turvalisus on mingist hetkest küsitav, ühtegi uuendust tellija ei saa, kõik arendused arveldatakse topelthinnaga ning vajalik uuendusprojekt muutub iga aastaga aina kallimaks, kuna kuristik versioonide vahel suureneb üha.

Kumb probleem on siis tõsisem, kas projektijuhi järjekindlus või tellija reaalne kahjum?

Kokkuvõtteks

Keeruliste olukordade ning pingeid tekitavate ülesannete vältimine on täiesti inimlik ja arusaadav. Aga tarkvaralahendustega tegeledes peavad nii tellija kui ka IT-partnerid leppima sellega, et projektitöö võib olla stressirohke ja nõuda keerukamaid otsuseid. Seega ärme püüdle utoopilise headuse ja lihtsa ning stressivaba plaani poole. Oleme tugevad, ausad, julged ja valmis väljakutsetele silma vaatama ning vajadusel ka mõistlikult „halvad“!