Kotisivulle Sivukartta

Matti Vuori

IT-projektien kokonaisvaltaisesta odotustenhallinnasta

On kuulemma hyvä odottaa hyviä asioita, mutta aina ei saa sitä, mitä odottaa. Odotustenhallinta on toimintaa, jolla varmistetaan, että - tyypillisesti - palvelun asiakas saa sitä mitä odottaa, ja kenties yllättyy vielä hieman iloisesti (muttei välttämättä liikaa, jotta ei odotustaso kasva vaarallisesti).

Tässä tekstissä katsellaan odotuksia ja niiden toteutumista IT-projektitoiminnan näkövinkkelistä miettien asiaa kummankin näkökulmasta. Teksti on yleisluonteinen eikä sen sisältöjä pidä ajatella kattavina.

Kuva: Tarpeet, toiveet, unelmat synnyttävät odotukset projektiasetelmassa.

Odotuksen olemus

Mikä on odotus? = Tulevaisuuden mentaalimallissa tulee jokia asia toteutumaan, jotain tiettyä tapahtumaan, jokin asia saavuttaa tietyn määrän tai arvon, jokin laadullisuus saavuttaa tietyn tason, syntyy tietynlaista arvoa tai kokemusta, jotain muutosta tullaan huomaamaan, jotain ongelmia taas ei tule vastaan jne...

Odotuksissa kohtaavat asian tila kokemuksellisuuden. Odotus on faktuaalista, mutta sen toteutuminen on myös tunnetason asia. Siksi se on oleellinen käsite yhteistyö- ja palvelukokemuksen kannalta ja tärkeää nykyajassa.

Odotusarvo on joidenkin asioiden ennuste. Joskus ennusteet ja odotukset sekaantuvat lupauksiin, mutta se on eri asia. Odotus ei tuota lupausta, mutta lupaus synnyttää odotuksen, että se täyttyy.

Odotus perustuu tietoihin odotukseen vaikuttavista asioista, jotka voivat olla tosiasiota, jopa sellaiseksi todennettuja, tai vain oletuksia: jos oletetaan, että systeemi toimii testeissä luotettavasti, voi odottaa, että se toimii käytössäkin ihan hyvin.

Odotukset eivät aina ole tiedostettuja (kuten eivät ole niihin vaikuttavat oletuksetkaan). Maailmammehan pyörii rutiineilla, joita ei tarvitse ajatella. Mutta sitten odotus tulee tietoiseksi, kun se ei toteudukaan... Tärkeissä asioissa onkin hyvä tehdä odotukset tietoisiksi, jotta voidaan vaikuttaa niiden toteutumiseen.

Odotukset ovat osa monenlaisten toiveiden maailmaa

• Asiakkaan unelmat, visiot - miten ne toteutuvat edes osin.
• Tarpeiden tyydyttyminen.
• Toiveet uudelle ratkaisulle.
• Pakolliset vaatimukset ja rajoitteet ratkaisulle.

Odotuksille on hyvä, että ne ovat realistisia. Kun ne täyttyvät tai ylittyvät, voi olla tyytyväinen. Jos ne eivät toteudu, ei olla tyytyväisiä. Pessimisti odottaa pahinta, optimisti parasta. Realismi on yleensä hyvä juttu.

Odotukset voivat kohdistua moneen asiaan

Ennen projektin alkua asiakas päättää mitä on hankkimassa. Silloin luodaan siihen liittyviä odotuksia esim.

• Hinta mahtuu budjettiin.
• Ominaisuudet täyttävät tarpeen ja tavoitteet.
• Mahdollisesti uutta kilpailuetua.
• Laatu on riittävää - kaikilla relevanteilla alueilla.
• Turvallisuutta.
• Kenties odotetaan jotain sellaista, mikä on aiemmin uupunut.
• Kenties jotain uutta tekniikkaa käyttöön.
• Ratkaisu on kokonaisuutena parempi kuin kilpailijat.
• Etiikka, vastuullisuus.
• Kaikkien tyytyväisyys lopputulemaan ja miten se muutti asioita.
• Yleisesti ottaen odotetaan lopputulemaa, joka antaa heti arvoa tai mahdollistaa arvon synnyttämisen.

Samoin etsitään toimittajaa, jolta odotetaan esim.:

• Osaamista.
• Luotettavuutta ja ongelmattomuutta.
• Sopivaa kustannustasoa.
• Hyviä toimintatapoja, alan yleisiä käytäntöjä, jottei niissä tule yllätyksiä.
• Asiakkaan ymmärtämistä - toimialaymmärrys, kulttuurinen yhteensopivuus, arvopohja.
• Kenties tietynlaista temperamenttia.
• Ehkä sellaista brändiä, josta tarttuu jotain asiakkaaseenkin.

Projektyö yhdistää asiakasta, toimittajaa ja tuotetta ja tapahtuu omassa toimintajärjestelmässään. Siihenkin liittyy odotuksia:

• Prosessi ja käytännöt.
• Asiakkaan osallistuminen.
• Projektin työmäärä, kuormittaminen, kesto.
• Työn motivaatio, merkitykset, tyytyväisyys.
• Valta, normit.
• Yhteistyö sidosryhmien kanssa.
• Oppiminen.

Projektityö on työtä ja siltä pitäisi voida odottaa samoja laadullisuuksia kuin ihmisen muutakin työltä (toimittajan puolella ei ihmisillä kenties muunlaista työtä olekaan).

Maailma muuttuu. Odotukset systeemeille voivat kattaa perinteisiä asioita, mutta voidaan myös odottaa tietynlaista etiikkaa tai tms... Olennaista tässä on se, että odotukset ovat dynaamisia. Tulee uusia, painokertoimet vaihtelevat, jotkut jäävät pinnan alle, joistain taas kannetaan huolta.

Ihmisten odotuksia - kulttuurissa

Huomattakoon heti, että odottaja ei ole organisaatio, vaan yksi tai useampi henkilö, esim. johtaja, ICT-päällikkö, ostovaikuttava expertti, tietoturvajohtaja, laatupäällikkö yms. tai käyttäjä. Näillä kaikilla on omat odotuksensa pohjautuen omiin akuutteihin tarpeisiin ja vastuisiin tai henkilökohtaisiin pyrkimyksiin (urakehitys, bonukset)... Joku odottaa kustannustehokkuutta, joku painottaa laatua, joku haluaa asiat äkkiä tulille. Kaikki ne voivat olla odotusavaruudessa valideja pointteja. Yhdessä ne muodostavat kokonaisuuden, jossa voi olla ristiriitojakin, mutta missäpä ei. Systeemien kehittämisprosessi on sitten paikka luoda kokonaisuudessaan paras synteesi.

Tietenkin ihmisillä on paljon yhteisiä oletuksia asioista, jotka sitten synnyttävät projektillekin yhteisiä odotuksia. Sitä sanotaan kulttuuriksi. Me elämme aikalailla samanlaisissa oloissa ja totumme siihen, että asiat toimivat tietyillä tavoilla.

Samassa kulttuurissa voi tietysti ihmisillä olla erilaisia käsityksiä organisaation olemuksesta (nyt ja ideaalisesti) ja projektin tavoitteista. Tässä tarvitaan ajatusten ja tiedon tasausta.

Ihmisten pyrkimykset oletetaan rationaalisiksi, mutta sitä ne eivät ole edes projektitoiminnassa. Ihmiset voivat pyrkiä omituisiin asioihin ja luoda irrationaalisia odotuksia - projektityön käytännöt on keksitty sitä varten, että järki voittaisi.

Osa odotuksista on lausuttuja, mutta osa on lausumattomia. Sekin on kulttuurille ominaista:

• Kulttuuriset käsitykset ja oletukset.
• Toimialan tavat joissakin asioissa.
• Ammatteihin ja rooleihin liittyvät stereotypiat.
• Henkilökohtaiset tiedot ja käsitykset asioista.
• Erilaiset vinoumat.
• Brändin ja maineen tuottamat epäsuorat käsitykset asioista, tekemisestä, laadusta,
• Asioita voidaan antaa ymmärtää epäsuorasti.

Kokemattomalla hankkijalla on kaikki epämääräistä. Ei osata edes odottaa muuta kuin jonkinlaista lopputulemaa. Projektin osataan kuvitella kulkevan kuin edellisen projektin. Learning by doing tuottaa horjuvia odotuksia ilman teoriaosaamista. Siksipä esim. asiakkaan vuokraprojektipäällikkö on usein hyvä idea.

Ajattelu auttaa

Hyviin odotuksiin auttaviin asioihin kuuluu hyvä ajattelu. Kaksi aikamme (2020-luku) muotiasiaa ovat kriittinen ajattelu ja uteliaisuus. Kriittinen ajattelija ei usko ennusteita, skenaarioita ja väitteitä perusteetta. Häneen ei hype pure. Uteliasta myös katsella asioiden taakse, löytää niiden luonne, logiikka ja vaihtoehdot. Nämä kaksi ajattelun laatua ovat hyvät varsinkin yhdessä.

Entäpä tieteellinen ajattelu? Joidenkin mukaan jo hyvien prosessien noudattaminen on tieteellistä. Sitä se ei toki ole, mutta tieteellinen ajattelu olisi tällaisia piirteitä IT-projekteissa:

• Rajatataan tuotoksen skouppi, jotta ymmärretään mitä ollaan tekemässä.
• Suunnitelmat koetaan hypoteeseiksi, joiden pätevyys pitää osoittaa.
• Kaikki altistetaan avoimelle kritiikille ja siitä opitaan.
• Haetaan mielellään faktoja asioiden tueksi.
• Validoidaan asiat mielellään empiirisesti.
• Ollaan analyyttisiä.
• Havainnoidaan matkan varrella ja ollaan avoimia uudelle.
• Ollaan nöyriä todellisuuden edessä. Hyvä tiede on egotonta.

Näistä on paljonkin iloa odotusten kanssa. Tiedehän on ideaalisesti ei-odottamista ja pärjäämistä epävarmuuden kanssa.

Systeemiajattelu on jo klassikko. IT-systeemit ovat tietysti teknisiä systeemejä, mutta useimmiten myös sosioteknisiä systeemejä. Ne ovat myös aina vuorovaikutuksissa muiden systeemien kanssa. Systeemiajattelu auttaa avaamaan kaikentasoisia vuorovaikutuksia ja siten laajentaa odotusavaruutta ja tekee odotuksista realistisempia.

Muotoilua on montaa sorttia ja niin on muotoiluajatteluakin (älkää antako menetelmäkauppiaiden omia termiä!). IT-projekteissa sen ydintä on fokusoida käyttäjiin ja käyttökontekstiin. Tämä tuottaa suoraan odotuksia projektin prioriteeteille, menetelmille ja tuotoksille.

Riskiajattelu on itsestäänselvää. Teollisuuslaitoksen toiminnalta voi odottaa mitä tahansa ilman riski- ja luotettavuusanalyysejä. Sama pätee tietojärjestelmän tietoriskeihin ja sen kautta sen liiketoimintaan. Voiko Riskiajattelu auttaa ymmärtämään lopputulemaa ja olemaan varmempi sen suhteen mitä voidaan odottaa. Se näkyy asennoitumisena ja tekoina: projektin kriittisyyden ymmärtäminen, vaikutusten arviointi, riski- ja luotettavuusanalyysit jne...

Odotuksille ja niiden saavuttamiselle hyödyllistä ajattelua on siis montaa sorttia. Maailmamme on tällainen. Onneksi sen kaiken ei tarvitse tulla mukaan samoissa "nahkakansissa". Miksei laatuajattelua ole mainittu? Siksi, että nämä kaikki muodostavat sen yhdessä.

Klassinen tyyli projektinhallinnassa

Klassinen odotustenhallinta on rationaalista ja systemaattista:

• Dokumentoidaan kaikki odotukset sopimuksissa, vaatimusmäärittelyissä jne.
• Osa odotuksia voidaan jättää yleisiin sopimusehtoihin, jolloin ne eivät kuormita projektin dokumentaatiota ja sopimusprosessia.
• Pyritään varmistamaan, että kumpikin osapuoli ymmärtää kaiken samalla tavalla.
• Määritetään odotettaville asioilla hyväksymiskriteerit, joilla voidaan selvittää "objektiivisesti" onko odotettu asia saatu vai ei.
• Todennetaan sovitut asiat matkan varrella erilaisilla tavoilla, mm. mittaamalla, testaamalla jne...
• Tehdään tiivistä seurantaa tekemisille, jotta ongelmat eivät pääse kerääntymään.
• Todetaan yhdessä katselmoinen asioiden ja odotusten tila.

Tämä on ihan normaalia projektitoimintaa ja osa projektinhallintaa. Tässä mallissa on selvää, että esim. käytettävyydelle on syytä määrittää kriteerejä, sillä asiakas tietysti odottaa hyvää tasoa, mutta mistä toimittaja tietää asiakkaan vaatimustason? Ja miten se laatu osoitetaan, mitkä ovat sen kriteerit ja mittarit? Osoittaminen myös vaatii työtä eli aikaa ja rahaa.

Kun asioita dokumentoidaan, on dokumenttien viestivyys tietysti tärkeää. Nykyään siihen kiinnitetään huomiota jopa lakiasioissa (legal design), niinpä on päivänselvää, että projektidokumenttien pitää todella viestiä niihin kirjattuja asioita. Tietenkään dokumentit eivät saisi toimia yksinään, vaan enemmänkin rikkaan, monimuotoisen ja monikanavaisen viestinnän viiteaineistona.

Kirjaamattomat asiat

Kaikkia odotuksia ei koskaan kirjoiteta ylös. Se olisi ihan mahdoton työ. Systeemeillä on jokin peruskonsepti, joka oletetaan ymmärretyksi. Tämä ymmärrys edellyttää yleistä systeemiymmärrystä ja toimialaymmärrystä. Toisaalta kaivataan väistämärrä asiakkaan kontekstin erityisyyden ymmärtämistä. Mistä se syntyy?

• Yleisen kokemuksen reflektointi.
• Kokemus asiakkaan kanssa.
• Tapa ja kyky jäsentää ja selvittää kulttuuria, tutkia toimintaa ja tarpeita.
• Vuorovaikutus prosessin aikana.
• Prototyypitys / MVP ja inkrementaalinen kehittäminen keinona vähitellen oppia asioita asiakkaasta, käyttäjistä ja kehittämisen kohteesta.

Miten sitten asiakas saadaan odottamaan "oikeita" ja realistisia asioita ja oikealla laadulla tehtyinä? Eka asia on toimittajan brändi, asemoituminen toimijakentässä - vahvaksi koetulta osaajalta sopii odottaa enemmän pyytämättäkin; epävarmaksi ymmärretyn ja uuden toimijan kanssa kannattaa odottaa vähän ongelmia. Toinen taso on prosessien ja toiminnan kuvaus. Asiakkaan perehdyttäminen on aina hyvä asia, sillä hankintaosaaminen ei useinkaan ole vahvaa ja pienikin preppaus auttaa. Tämän päälle sitten yhteistyö tarpeiden ja vaatimusten selvittämisessä.

Teknologiaodotukset, hype ja harhat

Teknologia muuttuu ja aina haluttaisiin käyttää uusinta teknologiaa... jos se vain toimii riittävän hyvin. Teknologiaodotukset saa realistisiksi selvittämällä asioita:

• Systemaattinen selvitys nettihakua käyttäen.
• Keskustelupalstojen, tukifoorumien seuranta.
• Muun somen seuranta.
• Hankittu tai oma analysointi ja testaus (proof of concept).

Tekniikkaan on tapana rakastua ja rakastunut ei näe rakkauden kohdetta selvästi. Hype sumentaa aistit ja ajatukset. Organisaation valintatilanteissa onkin hyvä olla dialogia, jotta intoa tasapainotetaan riskianalyysillä ja sosioteknisellä realismilla. Silloin odotukset tasoittuvat ja muodostavat perustellun kokonaisuuden.

Oletukset odotusten taustalla

No niin, jos odotukset ovat tervehenkisiä, pitää miettiä niitä oletuksia, joita niiden saavuttaminen edellyttää. Ovatko oletukset systeemin laadun prioriteeteista oikeat? Tiedetäänkö edes käytöstä riittävästi? Oletukset voivat olla kohdallaan, jos vanhoja asioita päivitetään, mutta uutta tehdessä ne voivat olla ihan poskellaan. Siksipä niitä pitää selvittää. Sitten jää tietysti jäljelle kaikenlainen kehittämistyö, joka on ihan omien artikkeliensa asia.

Odotus-termin käyttäminen on mahdollisuus ja riski

Odotus on hyvä termi, koska se on aktiivinen ja suora ("Mitä odotuksia sinulla on..."), mutta suoraan kysyttäessä se tuottaa vastauksia, joihin odotetaan (sic.) vastinetta ja jos niin ei tapahdu, petytään.

Toisaalta se on tuotteesta / järkestelmästä puhuttaessa liian konkreettinen ja perustuu oletuksiin konseptista eli rajaa heti ratkaisuavaruutta ja jättää pois tilanteeseen liittyvät unelmat ja uudelleenajattelun. Siksipä suunnittelussa pitää puhua epäsuoremmin (tietenkin joskus kannattaa olla simppeli ja suora).

Niinpä odotuksia kannattaa lähestyä epäsuoremmin ja muiden termien ja artefaktojen kautta, joita jokaiseen kontekstiin on tarjolla ihan kylliksi. Esimerkiksi vaatimusmäärittelyssä on kyse eritasoisista odotuksista toiseen muotoon paketoituna. "Odotusten" sijaan selvitetään mieluummin miten tärkeitä erilaiset asiat ovat ja millaisia piirteitä niissä olisi hyvä olla.

Loppusanat

Odotusten maailma on rikas ja asioiden miettiminen sen kautta voi avata niitä uusilla tavoilla, vaikka odotuksista ei käytännössä puhuisikaan ihan jatkuvasti.

Fiksut odotukset ovat kaikkien etu. Onneksi niiden saavuttamiseksi on iso nippu tunnettuja keinoja.

Toimittajan kannattaa panostaa odotuksiin, sillä niillähän erotutaan kaikista muista, ja täyttämällä odotukset tehdään kaikki osapuolet tyytyväisiksi. Projektin asiakkaan on aivan kriittistä jäsentää odotuksiaan ja miettiä miten projekti tulee ne täyttämään ja miten voi omilla toimilla edistää tarpeellisia asioista.