Verkkopalveluprojektin kolme kuolemansyntiä

29.9.2016

Verkkopalveluita toteutettaessa törmätään yleensä matkan varrella hyviin ja huonoihin asioihin. Samalla kun koko polun kulkemista halutaan muuttaa helpommaksi ja mukavammaksi, katse kiinnittyy niihin asioihin, joita voitaisiin parantaa. Kun vielä näistä parannuskohteista valitaan tärkeimmät huomataan, että projektin alussa tehdyt virheet kertautuvat matkan aikana suurimmin, ja juuri ne aiheuttavat ongelmia, joihin on vaikea reagoida myöhemmin.

Valitsin kolme näin valikoitunutta ongelma-aluetta alla olevaan artikkeliin, joka pohjautuu Markkinoinnin viikko -tapahtumassa 22.9.2016 pitämääni esitykseen.

Tarkastellaan ensin hieman verkkosivustojen historiaa hyvin karkealla tasolla. Ensin oltiin kiinnostuneita ns. käyntikorttisivustoista, joiden tarkoituksena oli yksinkertaisesti saattaa organisaatio verkkomaailman tietoisuuteen, tavallisesti hyvin yksinkertaisella esittelymateriaalilla. Tämän jälkeen verkkopalvelut alkoivat muuttua tietovarastoiksi. Perinteinen sanonta ”meidän on saatava X nettiin” kuvastaa tätä tilannetta (millä vain X:llä). Nykyään puhutaan verkkopalveluista tuloksellisina työkaluina. Tämä tarkoittaa sitä, että verkkopalveluun upotettavasta rahasta ja vaivasta tulisi saada vastaava hyöty ja toisaalta verkkopalvelun tulisi voida ratkaista sellaisia haasteita, joihin ei muilla keinoin pystytä tarttumaan.

Ensimmäinen synti kiteytyy vastuiden ja päätöksenteon ristiriitaiseen priorisointiin. Mikä on päättäjän vastuulla ja mistä kutakin osa-alueesta vastaava asiantuntija saa päättää? Onko verkkopalvelun tekeminen taidetta, asiantuntijatyötä vai maksavan asiakkaan palvelemista?

Ymmärtääksemme vastuunjakoa tarkemmin, tarkastellaan verkkopalvelun toteuttamiseen vaadittavia toimia ja tuloksia. Yllä kuvatussa mallissa toteuttamiseen vaadittavat valmistelevat toimenpiteet on kuvattu kaavion vasemmalla puolella. Tarpeesta herää hankintapäätös, jonka seurauksena valitaan toteuttavat tahot ja työryhmät, joiden toimintaa koordinoidaan projektin aikana. Koordinoinnin alaisia toimia ovat suunnittelu (jonka perimmäisenä tavoitteena on jalostaa toteutettavan asian tarkoitusta), asettelu (joka tarkoittaa fyysisten ilmenemien kuten ilmeen ja käyttöliittymien laatimista) sekä lopulta käytännön tekniikka.

Oikealla puolella on kustakin toimesta seuraavia tuloksia. Teknisen alustan päälle rakennetaan suunnitelmien pohjalta sisältö, käyttäjäkokemus hiotaan ja tarvittaessa palataan etenemistä seurattaessa piirrustuspöydän ääreen ja tehdään jotain uudelleen. Kun työ on valmis, suoritetaan palvelun käyttöönotto. Asioiden siirtyessä tuotantoon kerätään toivottavasti investoinnin tulokset, joita seurataan.

Tässä kaaviossa voidaan yleistäen todeta, että kullakin rivillä vasemmalla olevasta toimesta vastuussa oleva taho on vastuussa myös samalla rivillä oikealla olevasta tuloksesta. Ilman kunnon suunnitelmaa on mahdotonta saada toimivaa käyttökokemusta, ilman koordinointia seuranta pettää ja budjetit paukkuvat. Toisaalta nuolia pitää lukea toisinkin päin. Ymmärtämättä suunnittelun lähtökohtia ja itse suunnittelutyön tavoitteita on mahdotonta yrittää tehdä pelkän sisällön perusteella toimivaa käyttökokemusta. Erityisen tärkeää on ymmärtää, että lopputuloksen on tyydytettävä nimenomaan siitä vastuussa olevaa tekijää.

Tätä kaaviota voidaan käyttää hyväksi myös kun mietitään mitä toimijoita projektin varrella tarvitaan. Meillä Poutapilvellä tavanomaisin malli on sellainen, jossa asiakkaallamme (verkkopalvelun tilaajalla) on syntynyt tarve kehittämiseen, ja sitä edistämään on perustettu projektiryhmä. Me rakennamme asiakasta varten oman projektiryhmämme, joka käy asiakkaan kanssa vuorovaikutuksessa projektin koko matkalla yhteistyössä asioita rakentamaan. Tämän projektiryhmän alla on vielä asiantuntijoita, jotka tekevät määritelmien mukaan toteutustyötä.

Kaavioon voidaan piirtää viivat, jotka kuvaavat sekä tätä yhteistä aluetta että kunkin toimijan omaa osa-aluetta.

Vastuunjaon synneistä

Nyt sitten niihin synteihin…

Ensimmäinen synneistä koskee väärää päätöksentekemisen tasoa. Otan tästä kaksi tyypillistä esimerkkiä.

Tilaajan organisaatiossa hankinnasta ja projektin läpiviennistä vastaa kaksi eri työryhmää, näistä ensimmäinen voi olla vaikka organisaation hallitus, toinen joko projektia varten kerätty työryhmä tai olemassaoleva viestintäosasto. Läpiviennistä vastaava työryhmä on mukana suunnittelutyössä ja esittelee projektin vaiheita johtoryhmälle. Vastassa on haaste, jossa suunnittelutyön ohella on huomattu joidenkin tavoitteiden olevan vääriä, ja käytettäviä resursseja tulee kohdistaa uudelleen. Johtoryhmä ei tunne esille tulleiden muutostöiden perimmäisiä syitä ja ohjeistaa projektiryhmää tekemään tämän paremmasta tiedosta huolimatta väärän päätöksen. Resursseja ei voida käyttää oikein ja kehitysprojektin tavoitteet eivät kohtaa todellisuutta.

Tilaajan käytännön toimitustyöstä vastaa sama projektiryhmä, joka on määrätty koordinoimaan projektia toimittajan kanssa. Tilaajaosapuolen sisäisissä palavereissa on sovittu, että ensin tarvitaan alusta ja sitten tehdään sisältö. Hankintavaiheessa eri toimittajat pyrkivät tarjoamaan erilaisia tarjouksia pystyäkseen jotenkin vastaamaan tarpeisiin ja taatakseen lopputuloksen toimivuuden, mutta jokin tarjouksista hyväksyttiin kiinnittäen huomiota vain teknisen suorittamisen vaiheisiin. Kunnollista sisältöä ei saada ennen yhteisen projektin loppua, ja kehitysprojekti ei onnistu tavoitteissaan.

Molemmissa tapauksissa tehtiin päätös ilman oikeaa kontekstia. Johtoryhmä ei ollut ajan tasalla koordinointi- ja suunnittelutyön etenemisestä. Perinteisesti voidaan toki esittää kysymys tulee näiden ollakaan. Lähtökohtaisesti tämäntyyppisissä projektissa sanoisin että ei, riittää kun pidetään huoli alkuperäisistä kokonaistavoitteista ja annetaan vastuu suorittavalle vastaavalle, tässä tapauksessa projektiryhmälle. Jälkimmäisessä esimerkissä ei pystytty tuottamaan sisältöä oikeassa vaiheessa projektia, käyttökokemusta ei saatu rakennettua todellisen julkaistavan sisällön pohjalta ja lopputulos jäi loppukäyttäjälle ontoksi.

Toinen synti koskee vastuualueiden vääränlaista jakamista toimijoiden kesken. Hyvin tavanomainen tapaus on se, että verkkoviestinnän asiantuntijalta pyritään kustannusten matalana pitämiseksi tilaamaan vain ”alusta”, jonka päälle suunnitellaan ja kirjoitetaan sisältö.

Tämä lähestymistapa on toiminut tyydyttävästi alussa esitellyn verkkopalveluiden lyhyen historian tietovarastovaiheessa. Nyt kuitenkin rakennetaan tuloksellista palvelua, ja asiantuntijan osaaminen on tärkeää. Monesti tällöin kannattaa säästää omia resursseja ja antaa asiat asiantuntijan tehtäviksi. Diagrammiin piirreltyjä viivoja siis siirrellään pystysuunnassa. Joskus tilanne voi olla myös päinvastainen, yritetään tavoitella kuuta taivaalta kun puuhun pitäisi kiivetä tyvestä.

Yhteistyö on poikaa

Tämän diagrammin esityksen tarkoituksena ei ole kakuttaa kutakin esitettyä riviä vain eristyksissä toimivan asiantuntijaryhmän asiaksi. Hyvin tavanomaista on, että sisällönsyöttö esimerkiksi tehdään ainakin tietyiltä osin asiakkaan projektiryhmän toimesta. Oleellista tällöin kuitenkin on, että kyseiset henkilöt ovat itse mukana myös suunnittelemiseen ja asettelemiseen liittyvissä vaiheissa, ideoimassa, kritisoimassa ja kuulemassa perusteluja. Koska projektien luonne vaihtelee hyvinkin dramaattisesti, rajat voivat siirtyillä villistikin.

Sukelletaan vähän syvemmin aiemmin hahmoteltuun perisyntiin. Sisältö tehdään myöhemmin – periaatteessa ihan hyvä idea. Mutta mitä siihen vaaditaan? Tarvitaan ihmekone.

Kaikkivoipa järjestelmä, jonka toiminnot voidaan määritellä vasta kun se on jo valmis on hyvä resepti silloin, kun halutaan toteuttaa projekteja, jotka ylittävät annetut budjetit aika- ja kustannuspuolella jopa 1 000%:lla.

Nykyään on jo melko tavanomaista, että teknisten määrittelyjen lisäksi halutaan kiinnittää huomiota myös sisällölliseen suunnitteluun. Työn tulee silloinkin kuitenkin pohjautua merkitykselliseen, todelliseen sisältöön. Pelkkä abstraktien kokonaisuuksien pyörittely saattaa johtaa yllätyksiin, kun konkreettista tietoa ryhdytään laatimaan.

Tässä ollaan jo hieman tekemisissä kaksiteräisen miekan kanssa, ja huomiota kannattaa kiinnittää erityisesti tapauksiin, joissa vanha sisältö on huonoa ja se halutaan korvata kokonaan paremmalla. Tällöin rakenteen ja sisällön muodon vaatimuksia on hyvä hahmotella ennen varsinaista sisällöntuotantoa. Käyttökokemuksen on kuitenkin turha odottaa olevan täydellistä ellei sisältö ole sen viimeistelemisen kohdalla valmiina.

Jotta tuotettava sisältö olisi hyvää, tulee sitä tekevän tietää mihin tarkoitukseen sitä tarvitaan. Olemassa olevia tekstejä ei todennäköisesti voida käyttää sellaisinaan. Printtiesitteessä ja verkkosivulla voidaan käyttää hyväksi erilaisia kerronnan keinoja, ja kuhunkin kanavaan sisältöä tekevän on syytä varautua niiden eroihin.

Vastuussa olevan sisällöntuottajan on oltava perillä tarpeesta, mahdollisuuksista ja rajoituksista. Vain niin saadaan tyydyttävää sisältöä.

Kiteytetään sisällöntuotannon haasteet näin: Sisällön suunnittelu on oma suunnittelutyön vaiheensa, johon tulee varautua. Sisältö on laadittava, ja käyttökokemus on rakennettava sen päälle. Käyttäjää ei kiinnosta sivuston konsepti tai sen asettelu, käyttäjää kiinnostaa siitä saatava sisältö.

Kolmas ja viimeinen synti liittyy kehitysprojektin tavoitteiden asetteluun. Kovin monesti tavoitteena tuntuu olevan ”sivusto on vanhentunut” tai ”järjestelmä ei vastannut odotuksiamme”. Nämä saattavat molemmat olla tosia, mutta ne eivät toimi hyvänä tavoitteena tehokasta kehitysprojektia tavoiteltaessa.

Tavoitteen asettaminen on ainoa keino saada tuloksellisuutta.

Mistä verkkopalvelun budjetti tulee ja mistä se koostuu? Tavallisimmin se koostuu käynnistyskustannuksista (sisäiset resurssit, mahdolliset ostetut asiantuntijapalvelut), toteutuskustannuksista (kehitysprojektin aikana tapahtuva suunnittelu ja toteuttaminen) ja ylläpitokustannuksista (teknisen palvelun kiinteät kustannukset, sisällön ylläpitäminen).

Tavallisin malli on kuvattu yllä keltaisella käyrällä. Käynnistyskustannukset pyritään pitämään pieninä, toteutuskustannuksiin panostetaan, mutta käyttöönoton jälkeen odotetaan kustannusten lähestyvän nopeasti nollaa. Tällöin tavoitteen seuraaminen ja reagoivat toimenpiteet, joihin törmätään käyttöönoton jälkeen, joudutaan pitämään minimissään tai jättää tekemättä.

Toinen vaihtoehto voisi olla yllä olevassa kuvassa sinisellä käyrällä kuvattu versio. Tarpeeseen vastataan asianmukaisella vakavuudella ja tarvittavat sisällölliset, tekniset ja projektinhallinnalliset haasteet kartoitetaan ja suunnitellaan. Liikkeelle pyritään lähtemään mahdollisimman pienesti ja ketterästi. Ennen julkaisua viimeistelyyn panostetaan ja julkaisu toimii vasta lähtölaukauksena varsinaiselle tuotannossa olevalle palvelulle. Käyttäjien toiveisiin voidaan reagoida nopeasti ja tehokkaasti, palvelun parhaiten toimivat osa-alueet tunnistetaan ja niihin panostetaan. Toimintaa seurataan ja tulosten syntyessä budjettia kasvatetaan.

Kolmas mahdollinen malli on kuvattu yllä violetilla käyrällä. Toimitaan kuten perinteisesti, mutta lähdetään liikkeelle kevyemmin ja ketterämmin, murto-osalla kustannuksista. Suurin osa budjettia on määritelty ja varattu julkaisun jälkeiseen ajanjaksoon, jolloin tiedetään tarkemmin ja faktaan perustuen mitä palvelulta odotetaan ja miten se toimii. Jos joku on rikki, se voidaan korjata tai korvata kokonaan toimivalla. Aikaa, rahaa ja muita resursseja on käytössä kun palvelu on toiminnassa.

Mikä näistä malleista toimii parhaiten? Harvoin ensimmäinen, vaikka se on tavallisesti se yleisin ja ensimmäinen vaihtoehto. Miksi kukaan haluaisi toimia näin tehottomasti?

Tavallisin motivaatio on hetkellisen ratkaisun tavoittelu. Tämän vuoden budjettiin sopii vielä tämä. Vanha sivusto on jo viisi vuotta vanha. Käyttäjät toivovat uudistusta. Hoidetaan tämä homma pois alta ja ongelma unohtuu.

Oikea toimintatapa on määritellä verkkopalvelun tavoite hyvin etukäteen. Kullakin organisaatiolla ja verkkopalvelulla on erilainen tavoite. Joskus tavoitteen ja tuloksen välinen yhtälö on hyvin suoraviivainen, tavallisimmin kun sivusto toimii suoraan palvelun tai tuotteen myyntikanavana. Siirryttäessä markkinoinnillisista tavoitteista jäsentenhankintaan, viestintään, näkyvyyteen tai mielikuvaan mitattavuus vaikeutuu, mutta realistisen tavoitteen asettaminen kertoo, mitä ollaan tekemässä.

Tavoitteen ja oikeanlaisen budjetoinnin yhdistelmällä päästään maaliin. Kokonaisuuden hahmottamiseksi pitää vielä tehdä välitoimenpiteitä ja seurata palvelun kehittymistä kehityksen, julkaisun ja seurannan sykleissä.

Kaiken lähtökohta on arvon mittaaminen. Mitattavat asiat vaihtelevat verkkopalvelusta riippuen, mutta tavanomaisia asioita ovat käyttäjän arvo, vierailun arvo, keskimääräisen ostoksen arvo, yhteydenoton arvo ja viestinnän levittämisen arvo tai tehokkuus. Toisinaan ei ole selvää, missä näiden käyttöastetta ja arvon kehitystä voi seurata. Jos verkkopalvelussa esimerkiksi jaetaan asiantuntijoiden tai myyntihenkilöiden yhteystietoja, tulisi niiden toimivuutta seurata puheluiden tai sähköpostiyhteystietojen perusteella. Tähän ei esimerkiksi perinteinen verkkoanalytiikka silloin auta.

Kun investoinnin kohteiden arvoa voidaan seurata, pystytään tekemään perusteltuja ratkaisuja budjetin ja resurssoinnin osalta. Mikäli verkkopalveluun tehty investointi osoittaa kannattavuutensa, voidaan jatkaa siihen panostamista tuottavuuden nimissä. Kannattavuutta taas voidaan arvioida suhteuttamalla saatua mitattavaa hyötyä tehdyn investoinnin suuruuteen, perinteisiin viisauksiin nojaten.

Tero Parvinen
suunnittelupäällikkö

Ota yhteyttä, ehdota tapaamista tai pyydä tarjous.

Ota yhteyttä