Muistan vielä oikein hyvin Biitin ensimmäisen projektin. Teimme innoissamme asiakkaalle Salesforce-käyttöönottoa, jonka halusimme viedä kunnialla läpi. Laadimme tarkan toimitussopimuksen ja kuvasimme yksityiskohtaisesti jo ennen projektin aloitusta, mitä tehdään ja missäkin vaiheessa.
Kirjoittaja: Ikla Puustinen / CEO, Biit Oy
Puhuimme silloin Statement of Workista eli SOW:sta. Se oli sinänsä pätevä paperi, johon kirjattiin projektin tuotokset ja määriteltiin samalla, mitä kaikkea projektiin kuuluu ja mitä ei kuulu. Toimitusmallina alkuaikoina oli aina vesiputous. Siitä lisää tässä Fiidissä.
Tämä lähestymistapa tuotti kaikenlaisia haasteita. Todellisuus iski projektien aikana vasten kasvoja, kun tarkoista määrittelyistä huolimatta uusia tarpeita löytyi asiakkaan puolelta joka viikko. Budjetit paukkuivat kesken kaiken. Seurasi ikäviä keskusteluja, kun asiakas ei ollut halukas maksamaan lisätyöstä.
Mikä avuksi? Lisäsimme määrittelytyöpajoja ja kuvasimme aiempaa tarkemmin, mitä kaikkea projektiin ei kuulu. Myyntityöhön kului yhtäkkiä moninkertaisesti enemmän aikaa kuin aikaisemmin. SOW:hen listattiin out-of-scope -asioita enemmän kuin varsinaisia tuotoksia. Huh huh.
”Nykyisin projektiemme toimitusmalli on ketterä. Teemme asiat yksi sprintti kerrallaan ja tiedämme saavamme sillä aikaan parhaat tulokset – ja tyytyväisimmät asiakkaat. Tämä lähestysmalli sopii Salesforce-maailmaan parhaiten.”
Onneksi nämä ajat ovat jo kaukana takanapäin. Nykyisin projektiemme toimitusmalli on ketterä. Teemme asiat yksi sprintti kerrallaan ja tiedämme saavamme sillä aikaan parhaat tulokset – ja tyytyväisimmät asiakkaat. Tämä lähestysmalli sopii Salesforce-maailmaan parhaiten.
On turhaa edes yrittää kuvata kaikkea etukäteen tarkasti, sillä se on käytännössä mahdotonta. Ketterä malli myös pakottaa asiakkaan priorisoimaan. Näin emme jahtaa yhdessä lillukanvarsia, vaan keskitymme liiketoiminnan kannalta tärkeimpiin kehityskohteisiin.
Olen myös huomannut, että ketterän projektin myötä asiakkaan suhtautuminen asioiden kehittämiseen on usein muuttunut. Järjestelmään ei suhtauduta sellaisena asiana, joka pyritään saamaan kerralla valmiiksi, vaan sitä halutaan kehittää pienin askelin. Koko ajan liiketoiminnan tarpeet edellä.
Asiakkaan päätöksentekijöille tämä on toisinaan vaikea aihe. Sopimusta lukiessa voi tuntua siltä kuin ei tietäisi tarkalleen, mitä projektin päätteeksi tulee saamaan. Ja niinhän se onkin. Parhaat tulokset saadaan silloin, kun jätetään muutoksille riittävästi pelivaraa ja keskitytään aina sillä hetkellä tärkeimpiin kehityskohteisiin. Yhdessä asiakkaan kanssa.
Projektimaailmassa kyse ei koskaan ole pelkästään hyvästä lopputuloksesta, vaan myös siitä, miten asiat tehdään. Siksi nostimme tämän Fiidin teemaksi IT-projektit ja niiden toimintamallit. Toivottavasti pystymme nyt raottamaan sitä, mitä kaikkea tapahtuu sopimuksen allekirjoittamisen ja go-liven välissä.
