Miks projektid ebaõnnestuvad?

Ammu aega tagasi sai käidud projektijuhtide koolitusel ning sealgi küsiti sama küsimust. Vastuseid oli palju: ebatäpsed nõuded, tehniline praak, halvad ajahinnangud, scope creep, vähene suhtlus jne. Siiski taandaksin ise ebaõnnestumise kahele peamisele probleemile: suhtlemine ja tehniline praak.

Uurides põhjalikumalt, miks on ebatäpsed nõuded, siis taandub see vähesele või ebaefektiivsele suhtlusele. Teine variant võib olla ka see, et ei saadud pidevalt tagasisidet, mis on üks suhtluse vorme. Ebatäpsed ajahinnangud viitavad samale probleemile. Kui arendada tsükliliselt, siis peaks olema võimalik ajahinnanguid korrigeerida. Tellijagi peaks aru saama, et ennast petta pole mõtet, kui teostaja soovib ajahinnanguid muuta (siinkohal võib tellija otsustada pigem, kas sellise kulu põhjal on tal vastavat funktsionaalsust kasulik osta).

Veel problemaatiline koht on skoobi haldamine. Tüüpiliselt tekkib nõuete üleküllus aja ja eelarve suhtes. Siin näen kahte lahendust: teostaja haldab või tellija haldab. Esimese puhul on vaja ise ohje hoida ning nõuetesse ka kirjutada, et mida tellija ei saa vastavate hinnangute ja eelarve eest. See on küllaltki kulukas ja tihtipeale ka sõjakas lähenemine. Teine variant on tunduvalt parem – tellija ise haldab skoopi ning arendust tehakse tsüklite kaupa. See lähenemine nõuab rohkem suhtlemist, kuid sõda pole lähenemas.

Seega suur osa probleeme tekkivad halvast või vähesest suhtlusest. Isegi olen näinud, kuidas mõnel projektijuhil kaob selgroog, kui tuleb tellijat teavitada aegade üleminekust (ja seda siis kui tähtajani on veel palju aega). Aus suhtlus viib pigem parema teostaja-tellija suhteni.

Teine suuremat sorti projektide hävitaja on tehniline praak. Peamine põhjus seisneb selles, et kaoses ei anna piisavalt kiiresti edasi liikuda. Siinkohal võite lugeda eelnevat kirjutist teemal “Kuidas kaob tarkvara kvaliteet?” Kvaliteedi puudumisel on raske mõistliku tempoga edasi minna ja sellest hakkab ka teostaja-tellija suhe kannatama. Seega häkkimine, kiirustamine ja testimata kood on suured ohu allikad.

Tsükliline arendus eeldab küllaltki tugevaid tehnilisi oskusi, seega ainult suhtlemine ei pruugi aidata – tuleb ka töötajaid harida.

Parema projekti õnnestumise jaoks tuleb tellijaga rohkem suhelda ja hoolitseda, et tehnilist praaki ei tekkiks.