Kuus nõuannet IT-projekti ohjes hoidmiseks

IT-projektid püsivad palju paremini ajagraafikus ja eelarves, kui firma IT-inimesed teavad, mis suunas nende ettevõte liigub. Iga IT-lahenduse tellija peab enne tellimuse koostamist keskenduma enda äritegevuse analüüsile. Mis on ikkagi ettevõtte tegevusala ja millised on põhiprobleemid ning milliste ressursside abil neid probleeme kõrvaldada saab. Kui selle käigus selgub, et tegemist on tõesti IT-alase probleemiga, siis tasub: kirjeldada võimalikult selgelt soovitavat tulevikuseisundit ja veenduda, et ettevõte suudab edendada oma põhitegevust pärast plaanitava IT-lahenduse loomist ning organisatsioon uue lahenduse omaks võtta. Alles siis tuleb mängu tehnoloogia.

Usaldage asjatundjaid, st nii kolleege kui partnereid. Ükski firma Eestis ei ole nii suur ja rikas, et suudab üleval pidada ülikooli õppejõudude tasemel analüüsikeskkonda, maailmatasemel teostusmeeskonda, suurepäraseid dokumenteerijaid jms. Vähem või rohkem tuleb infosüsteemide korraldamisel teha koostööd teiste firmadega. Usaldus ja partnerist lugupidamine on olulised võtmesõnad. Pooled peaksid leppima kokku, mida nad teevad. Ja ärge minge pärast partneriga kohtumist tagatuppa tegema sedasama, mida palusite tal teha, et saaksite pärast kritiseerida ? mina sain selle asja palju kiiremini ja paremini valmis.

Väljendage võimalikult selgelt seda seisundit, kuhu tahate koostöö käigus välja jõuda, st koostage sisuline, mitte vormiline spetsifikatsioon. Seega ärge kirjeldage tarkvara ekraanipilti ega soovitavat arvutite hulka. Pigem tehke seda ärilises keeles ? mis on teie ettevõttele kasu sellest, kui te midagi teete, ehk kas see on üldse IT-probleem. Sealhulgas saage ka ise aru, mida tellite.

Määrake projekti kestus ja pidage sellest kinni. Ilmselt on vaid üksikuid näiteid, kus kümme aastat kestnud projektiga on mõlemad osalised rahul ja koostöö jätkub. Palju rohkem on selliseid näiteid, kus aasta-kaks veninud projekt on ajanud pooled tülli ja võib-olla ka pankrotti. Pole võimalik juhtida tähtajatut või mõõtmatut projekti.

Enne IT-projekti käivitamist tuleb soovitud seisundini jõudmine jagada etappideks. Ühe etapi teostamiseks ei tohiks kuluda üle kolme kuu. Pikema perioodi jooksul kipuvad lihtsalt eesmärgid ähmastuma ja tellijal tekib soov projekti eesmärke muuta või täiendada. See omakorda tähendab asjatuid vaidlusi ja emotsioone, mis ei mõju hästi ei projekti ajagraafikule ega maksumusele.

Ärge kunagi muutke projekti eesmärki. Te võite alati defineerida projektile järgmise etapi. Samuti võite defineerida uue projekti. Kuid ärge projekti käigus muutke selle sisu ? proovige püsida kokkuleppe ja spetsifikatsiooni piires. Kui tõesti on vaja projekti muuta või selgub, et eespool mainitud kolm kuud on liiga pikk periood ja selle aja jooksul muutub keskkond liiga palju, siis olge enda ja partneri vastu aus, lõpetage see projekt ja alustage uut.

Saage aru enda ettevõtte ärist ja kontrollige oma arusaama pidevalt. Enne, kui firma IT-üksus või projektijuhtimisüksus asub mingit tellimust vormistama, peab firma äripool olema sõnastanud nii probleemi kui selle soovitavad lahendused.

Samuti on tellijal vaja hinnata lahenduste kasulikkust. Proovige mõista, mis kasu uuest IT-lahendusest või infosüsteemi arendusest tegelikult on. Igal lahendusel peab olema taga mingi majanduslik mõte. Kord juhtis audiitor mu tähelepanu IT-süsteemi riskile, mis toonuks kahju 100 000 krooni. Nad pakkusid lahenduse, mis maksnuks üle miljoni krooni...

tehnoloogiat arendades jälgige kogu aeg, et suudate seda hallata. Tundke ja teadke oma üldist infosüsteemide keskkonda, et selle raames anda pakkumiskutse koostamisel täitjaile piirid ette. Võimalusel kasutage alati avatud ja universaalseid lahendusi, et tagada endale võimalus probleemide korral tuge leida. Leidke ettevõtte eesmärkidest lähtuvalt oma süsteemide kriitilised komponendid ja arendage nende haldamiseks olulised oskused võimalusel ettevõtte sees. Ja olge vähemalt neljakordselt hoolikas nendes valdkondades tehtavate arenduste ning muude tegevuste dokumenteerimisel ja logimisel.

Kui järgite neid näpunäiteid, siis võite olla suhteliselt kindel, et partner püsib graafikus. Kui te teate, mida tahate, kui te ei kirjuta seda tahtmist liiga arusaamatult lahti, kui te ei lepi kokku juhitamatult pikas koostööprojektis ja kontrollite veidi ka tulevase partneri tausta, siis lõppeb see projekt õigel ajal.

Ja kui kõigele vaatamata kulub projekti valmimiseks rohkem aega ning seetõttu täitjal ka ressurssi ja eelarve läheb lõhki, siis kes selle vahe katab? Üks võimalus on see, et täitja tahab olla tellijale pikaajaline partner ja oma vigadest õppida, makstes ise osa esimese ühisprojekti kasumist selle projekti õnnestumisse. Teine võimalus on see, et esialgne pakkumine tehaksegi sellise puhvriga, et see sisaldaks ka kõikvõimalikke ajalisi viivitusi.