Alkusyksystä Suomen IT-skenellä on vellonut keskustelu siitä, missä määrin ohjelmistohankkeet ovat muuttuneet henkilöstövuokraukseksi, ja kenen kannattaa ostaa toimitusprojekteja. Otapa kupponen kahvia, niin kerromme Devisioonan ajatuksista.

Herkullisen diskurssin käynnisti Perttu Tolvasen Vierityspalkki-blogin kirjoitus ”Iso osa kotimaisesta ohjelmistoalasta on henkilöstövuokrausta”. Kirjoituksen perusviesti on yksinkertainen: Moni ohjelmistotalo on vähentänyt projektivastuiden kantamista, ja monet asiakkaat ostavat yhä isomman osan kehitystarpeistaan valitsemalla tiimeihinsä sopivia tekijöitä ja johtamalla työtä itse.

Olemme seuranneet aiheesta syntynyttä keskustelua mielenkiinnolla. Omien projektikokemustemme lisäksi meillä on taustaa myös vajaan 20 vuoden ajalta erilaisista auditoinneista, hankintakonsultoinnista ja ongelmatilanteiden ratkomisista. Olemme nähneet varsin monenlaisia pieleen menneitä projekteja ja ärhäkäksi äityneitä toimittajariitoja. Tämän kokemuksen perusteella tuntuu siltä, että moni keskustelija on valmis vetämään mutkia suoraksi aika ronskisti, vaikka itse aihe on hyvin monisyinen. Otetaanpa asiaan siis vielä yksi näkökulma, historiasta lähtien.

Agile-markkina synnytti lihakaupan

Kun ketterät kehitysmenetelmät otettiin vähitellen käyttöön viimeisen vuosikymmenen aikana, hyväksyttiin samalla ajatus siitä, että projektisuunnittelun lähtökohtana ei olekaan kiinteä vaatimusmäärittely – alan termein siis sovelluksen toteutuslaajuus eli scope. Kiinteä hankebudjetointikin sai tällöin kolauksen: jos scopen sallitaan muuttua matkan varrella, kustannusten ennakointi muuttui vaikeaksi. Jos tähän vielä lisäksi yhdistetään yleinen käsitys siitä, että agile-projektit tuplaavat aina kestonsa, niin ei ihme, että asiakkaiden kokemus IT-hankeohjauksesta on kärsinyt melkoisen kolauksen.

Millä keinolla siis saada projektit pysymään lapasessa? Kun ketterän filosofian ytimessä tunnetusti ovat ihmiset, osa markkinasta muutti luontevasti muotoaan lihakaupan eli kauniisti sanottuna bodyshoppailun suuntaan: valitaan parhaat CV:t, ja kyllähän niistä nyt kai hyvä tiimi tulee. Toimittajan tehtäväksi jää etsiä hyviä tekijöitä ja hinnoitella ne oikein. Tekemisen kehittäminen ja tuotteistaminen ei tapahdu projekteissa, vaan niiden ulkopuolella, osaajien oman osaamisen kehittymisen myötä.

Henkilöstövuokrauksen ja konsulttien myynnin terminologiaeroa voi hieroa maailman tappiin asti. Olennainen kysymys on se, mistä kauppaa tehdään. Valitseeko asiakas sopivat CV:t katalogista ja sen jälkeen vastaa näiden henkilöiden työllistämisestä, vai sovitaanko toimittajan kanssa tietyn palvelun tai projektin toimittamisesta? Sopimusteknisesti ero ei toki ole aina kristallinkirkas, vaan kyse on siitä, miten vastuu hankkeen valmistumisesta jakautuu käytännössä.

Vastuullinen ketteryys kunniaan

Aiheesta käytävä keskustelu polarisoituu helposti, koska minkä tahansa hankemallin ääritapaukset ovat aina karmaisevia, ja niistähän ne anekdootit syntyvät. Katastrofiprojektien auditointikeikoilla on nähty tolkuttoman riitaantuneita kiinteähintaisia hässäköitä, joissa yhteisymmärrys projektin sisällöstä on kadonnut projektin ensimmäisen kolmanneksen aikana ja myöhempi muutoshallinta on vetänyt sekä budjetit punaiselle että silmät mustaksi. Aivan yhtä lailla vastaan on tullut agile-säätöjä, joissa toimittaja on painellut ovesta sisään minimityömääräarviolla, mutta sprintit eivät vain ole koskaan ottaneet loppuakseen.

Agile-artisti.

Projektien onnistumisen kannalta mikään sopimusmuoto tai työmenetelmä ei takaa onnistumista tai epäonnistumista. Tärkeämpää on tekemisen laatu sekä osallistujien sosiaalinen rohkeus ja tiimityön toimivuus. Silti selvää on, että valtaosalle nykyprojekteista ketterä lähestymistapa sopii perinteistä vesiputousta paremmin, ja se mitä kustannusten ennakoitavuudessa menetetään, saadaan hinta/laatu-suhteessa takaisin.

Ketterä sprinttityö on tavallaan toimittajallekin ideaalinen ratkaisu: voi keskittyä tekemään päivittäin parhaansa, ja huolen kantaminen kokonaispriorisoinnista jää asiakkaan tuoteomistajan murheeksi. Vastuullinen toimittajan tiimi miettii silti asiakkaan etua jopa aggressiivisesti: miten tekemistä ja tiimiä kannattaa kehittää, miten asiakkaan vaatimuksia kannattaa haastaa ja miten retrospektiiveissä esiin nousseita ongelmia korjataan tehokkaasti. Pelissä on kuitenkin toimittajan maine ja asiakassuhteen jatkuvuus, vaikka hankkeen laajuuteen ja budjettiin liittyvät riskit olisivatkin asiakkaan tuoteomistajan vastuulla.

Kun ketterästä projektitoimituksesta siirrytään henkilöstövuokraukseen, tekijät eivät muutu tippaakaan sen vastuuttomammiksi, mutta suhde tekemiseen muuttuu: Kun rooli on nimenomaan olla tuntilaskutteisena toteuttajana asiakkaan työnohjauksen alaisena, toteutustyö on juuri se mitä tehdään. Työmenetelmiäkin voidaan kehittää vaikka miten paljon – kunhan asiakas pyytää. Mutta kuinka usein se pyytää? Meidän kokemuksemme on, että henkilöstövuokrauksen tyyppisissä asetelmissa menetelmäkehitys jää usein sivurooliin, koska yksittäisessä hankkeessa se on suhteellisesti kallista ja yleisellä tasolla vaikeaa: parhaat käytännöt pitäisi sitten jalkauttaa kaikkiin projekteihin, joiden tekijät on muodostettu välillä jopa eri organisaatioista CV-poimintamenetelmällä.

Tarkoituksemme ei ole missään nimessä moittia ketteryyttä tai edes henkilövuokrausta, vaan osoittaa niihin liittyvät fundamentaaliset haasteet. Teknisen tuotteistuksen, vakioitujen toimintamenetelmien ja kehitystyön menetelmäosaamisen kehittäminen vaatii tietoisia panostuksia, ja useissa tilanteissa luontevin panostaja on ohjelmistopalveluita ammattimaisesti tuottava yritys, joka pystyy toistuvien projektien myötä myös keräämään tästä työstä saatavan hyödyn – siis käytännössä tehokkuuden ja ennustettavuuden parantumisen.

Jos tämä tekninen toimitusvastuullinen taho jää pois yhtälöstä henkilöstövuokrauksen myötä, vastuu työtavoista tipahtaa joko bodyshopatuille konsulttiyksilöille tai asiakkaalle itselleen. Parhaassa tapauksessa asiakas saa tunnetulta konsulttitalolta hankkeeseensa valmiiksi yhteen sulautuneen tiimin, jolla menetelmät ja niiden kehittäminen ovat jo hanskassa. Valitettavasti tuntuu, että jokaista tällaista onnistumista kohden löytyy kymmenen tapausta, joissa hankkeeseen resursoidaan eri puolilta keräiltyjä palkkasotureita, jotka ryhtyvät projektin kuluessa etsimään yhteistä säveltä. Menetelmäkehitysvastuun voi kantaa asiakaskin, mutta sepä onkin vaikea laji, ja mestarit sitä myöten varsin harvassa.

Kuka kantaa vastuun projektista?

Asiakas lopulta tietysti vastaa kaikesta. Kysymys onkin siitä, kenellä taakka käytännössä on ja keiden kesken se voidaan jakaa. Asiantuntijat ovat niitä konkreettisia kuormankantajia, mutta jos vastuu alkaa tuntua epämiellyttävän raskaalta, he myös vaihtavat liukkaasti maisemaa. Henkilökeskeisessä kaupanteossa selkeä tilaaja-toimittaja-suhde yritystason toimitusvastuineen jää syntymättä.

Toimitusvastuu tarkoittaa sitä, että toimittajaorganisaatio kantaa jatkuvaa ja konkreettista huolta asiakkaan projektille asettamien tavoitteiden toteutumisesta. Selkeintä se on, kun hankkeen laajuudesta, aikataulusta ja kustannuksista on tehty kiinteä sopimus, ja neuvotteluiden jälkeen toimittajan tehtävä on vain suorittaa. Käytännössä tämä alkaa olemaan jo harvinaista, mutta ketterämmissäkin sopimusmalleissa toimitusvastuu voi toteutua monella tavalla.

Vaikka kyse olisi puhtaasta tuntikaupasta, nimellään ja kasvoillaan hankkeen kokonaisuuteen sitoutunut toimittaja kantaa hankkeesta aina jonkinlaista kokonaisvastuuta. Tämä näkyy usein mm. siinä, että toimittaja tekee oman ammattitaitonsa perusteella arviot tarvittavasta työmäärästä ja rooleista, pyrkien tunnistamaan hankkeen onnistumisen edellytykset. Henkilöstövuokrausmallissa asiakasorganisaatio ottaa täyden vastuun siitä, että valitut henkilöt tuottavat haluttua lopputulosta sallitun budjetin puitteissa.

Lukuisten projektien – niin toteutettujen kuin auditoitujen – pohjalta koemme, että useimmat hankkeet hyötyvät siitä, että niillä on kaksi vastuunkantajaa: asiakas ja toimittaja. Siinä missä asiakas pohtii liiketoimintatavoitteita ja sovittamista muihin yhtäaikaisiin hankkeisiin, toimittaja voi usein tarjota arvokasta näkökulmaa esimerkiksi ei-toiminnallisten vaatimusten (suorituskyky, saavutettavuus, tietoturva jne.) sekä laajemman roadmap-perspektiivin ja teknologian kehityksen huomiointiin.

Se, miten toimittajan vastuu näkyy käytännössä, riippuu toki tilanteesta. Jos toimittaja rynnii ovesta sisään optimistisilla työmääräarvioilla ja ryhtyy koodaushommiin heti kun mahdollista, käytännön toimitusvastuu tuskin toteutuu ilman tiukkoja sopimusmalleja. Toisaalta jos toimittaja pyrkii proaktiivisesti ja sitkeästi selvittämään asiakkaan perimmäistä tarvetta, itse hankkeessakin yleensä näkyy hyvin vahva sitoutuminen lopputulokseen – vaikka lisää tekemällä saisikin laskuttaa enemmän.

Mikään tässä ei tietenkään tarkoita sitä, etteikö in house -tiimi voisi tehdä timanttista työtä, mutta vain harva asiakasyritys pystyy resursoimaan ja johtamaan projektit niin hyvin, että tämä toteutuisi toistuvasti ja luotettavasti. Vaikka hankitut koodarit olisivat kuinka osaavia ja monia hankkeita nähneitä, heille asetettu rooli ohjaa usein ajattelua nimenomaan konkreettiseen, optimistiseen devausputkeen. Tästä meillä on kokemusta itsellämmekin, kun ajoittain on tullut tällaista bodyshopping-tyyppistä keikkaa heitettyä: kyllä siinä kova seniorikin on sosiaalisesti vaikeassa välikädessä, kun pitäisi alkaa liputtamaan hankkeen organisoinnin puutteista.

Otos konsultointiuralta kertoo karua tarinaa: Useimmissa auditoitavissa hankkeissa keskeinen retrospektiiviviesti on ollut se, että konkreettiseen työnjohtamiseen sekä riskien ja riippuvuuksien hallintaan käytettiin liian vähän aikaa. Vielä kerran toistaen: Sillä ei ole väliä, kuka tämän työn tekee, mutta toimittajan projektipäälliköt ja toimittajaorganisaation vakiintuneet toteutusmallit poistamalla paine siirtyy entistä enemmän asiakkaan tontille. Jos asiakas haluaa kantaa vastuun itse, kannattaa ainakin vakavasti miettiä ammattimaisen ja neutraalin rakennusvalvonnan ostamista hankkeeseen.

Tuleeko toimittaja aina kahleiden kanssa?

Yksi keskeisimmistä asiakkaiden klassisista peloista on liian sitova toimittajasuhde (vendor lock-in). Vierityspalkin kirjoitukseen irtosi vastaus mm. rekrytointi- ja konsultinvälitystoimisto Talentedilta, joka otsikoi blogipostauksensa raflaavasti: ”Osaavimmat ostavat konsultteja, heikommat jäävät toimittajaloukkuun”. Hurjia puheita!

Oikea kysymys on se, miten taataan luodun sovelluksen kustannustehokas ja luotettava ylläpito koko elinkaaren ajan. Toimittajaloukku on toki yksi uhka, mutta kunhan immateriaalioikeuskysymykset on neuvoteltu kuntoon, loukku ei välttämättä ole ollenkaan merkittävin haaste. Järjestelmän alkuperäisen tekijän ei toki pitäisi ikinä olla korvaamaton, on kyse sitten toimittajalta ostetusta ratkaisusta, sisällä virkatusta systeemistä tai vuokratekijöiden tuotoksesta.

Tärkeä ja vaikea aiheeseen liittyvä kysymys on tasapaino räätälöinnin ja valmistuotteiden välillä: jos tehdään täysin räätälöidysti, kustannusten ennakointi on haastavaa ja lopputulos on aina sataprosenttisesti omalla vastuulla – hyvässä ja pahassa. Jos taas projekti rakennetaan valmistuotekonseptien ympärille, menetetään osa joustavuudesta ja joudutaan murehtimaan tausta-alustan kustannuksista ja roadmapista, mutta vastineeksi saatetaan saada olennaisiakin kustannussäästöjä niin toteutus- kuin ylläpitovaiheissakin.

Jos valmisratkaisu perustuu tuotteeseen tai vaikka avoimen lähdekoodin tuotteen päälle rakennettuihin toimittajakohtaisiin laajennuksiin, onko täyttä toimittajavapautta mahdollista saavuttaa, ainakaan taloudellisesti järkevästi? Toisaalta mitä vähemmän toimittajaorganisaatiolla on roolia hankkeen suunnittelussa ja toteutuksessa, sitä todennäköisimmin kehittäjätiimit tuntuvat valitsevan täysin pitkästä tavarasta tehdyn ratkaisun. Tämä on ymmärrettävääkin: vahvasti tuotevetoinen kehitys vaatii yleensä hyvin vakiintuneita toimintatapoja ollakseen tehokasta, ja näitä tapoja on vaikea muodostaa, jos tiimillä ei ole ollut tilaa toistaa samoja projekteja riittävän usein.

2020-luvun toimittajan ei pitäisi tavoitella toimittajalukkoa, ja asiakkaalla on oikeus edellyttää sellaista sopimusta ja lopputulosta, joka mahdollistaa toimittajasuhteen hallitun päättämisen järjestelmää vaarantamatta. Tässä suhteessa kriittisintä ei kuitenkaan ole projektimalli, vaan tekemisen tapa: immateriaalioikeusongelmien jälkeen suurin vaikeus toimittajavaihdoksissa on sovelluksen toteutuksen laatu ja kunnollisen ymmärryksen puute.

Kyse ei ole pelkästään koodirivien kiillosta ja dokumentaation tasosta, vaan myös alkuperäisestä liiketoiminnan ymmärryksestä ja roadmap-ajattelun laadusta. Devisioonalla on kokemusta useiden järjestelmien menestyksekkäästä siirrosta sekä luovuttajana, vastaanottajana että kätilönä, ja kokemus on selkeä: uusien vastuunkantajien löytyminen on helpointa, kun vanhat ovat ymmärtäneet asiakkaan liiketoiminnan kunnolla ja mukauttaneet sovellusrakenteen vastaamaan sen tarpeita ja kehityssuuntia. Tämä pitää paikkansa yhtä lailla silloin, kun huolena ovat irtisanoutuneet in-house-tekijät, vaikeaksi osoittautunut Venäjän kehitystiimi kuin konkurssiin kompastunut koodiputkakin. Mitä teknisemmällä otteella järjestelmä on tehty, sitä vaikeampaa toimittajanvaihto on.

Ostajan ja myyjän pitäisi kantaa vastuuta koko elinkaaresta

Monien ongelmien ytimessä on lopulta se, että tietojärjestelmien elinkaariajatteluun on suhtauduttu liian kevyesti. Tyypillisesti valtaosa järjestelmäkustannuksista syntyy projektivaiheen jälkeen, ja sekä ostajat että myyjät keskittyvät usein lähes pelkästään toteutusvaiheen järjestelyihin ja hinnoitteluun. Tarina toki kuulostaa erilaiselta tehtäessä kolme vuotta elävää verkkopalvelua kuin 20 vuoden elinkaarelle suunniteltavaa tehdasohjausta, mutta myös lyhyemmän tähtäimen projekteissa kannattaa miettiä koko sovelluksen elinkaari läpi.

Uudestakin järjestelmästä tulee joskus vanha.

Yksi konkreettinen kompastuksen paikka on jatkuvan palvelun organisointi. Valtaosa CV-kaupoista perustuu enemmän tai vähemmän täysipäiväisten henkilöiden vuokraamiseen, mikä voi itse asiassa olla aivan ideaalista projektivaiheessa. Mutta entä kun järjestelmä on rakennettu siihen pisteeseen, että sen ylläpitoon tarvitaankin vain neljänneshenkilön työpanosta? Jos ostaja ottaa voimakkaan projektin organisointivastuun itselleen, hän ottaa samalla vastuun siitä, että projektin jälkeinen kalenteriajallisesti perin pitkä vaihe saadaan myös vietyä läpi tyylikkäästi. Kokonaistarjousta tekevä toimittaja miettii yleensä ylläpidonkin samaan pakettiin – ja vaikka ylläpitopalvelu ei olisi optimaalinen, tämä mietintä on kuitenkin tullut tehdyksi.

Elinkaaren aikana nousevat esiin myös muut ympäristöseikat kuten rakennettavan järjestelmän sopivuus kokonaisarkkitehtuuriin: mihin integroidutaan, missä ajetaan, miten koordinoidut GDPR-tarpeet hoidetaan, kuka vastaa mistäkin palikasta? Näissä kysymyksissä mikään yksittäinen projektijärjestely ei välttämättä ole toista parempi. Tärkeintä on, että suunnitelma on ja että asiakas kommunikoi sen niille, jotka konkreettista toteutusta tekevät, ja että nämä todella suhtautuvat saamaansa tietoon vakavasti.

Elinkaarikysymyksissä asiakkaan on joka tapauksessa tärkeää kantaa vastuuta itse, varsinkin resurssivuokrausmallilla edetessä. Vaikka lähes poikkeuksetta tekijät haluavatkin tehdä työnsä hyvin, hallinnolliset näkökulmat ovat vain harvan vahvuuksia. Jos toteuttavana osapuolena on ”vain” joukko teknisesti teräviä yksilöitä, hallinnointinäkökulman on tultava jostain muualta. Moni asiakas kokee haasteena sen, miten sitä saisi ostettua juuri sopivan määrän: täysipäiväiselle ei riitä töitä, osa-aikaista konsulttia on joskus vaikea saada riittävän syvälle omaan tekemiseen. Kokonaisvastuulliset toimittajaorganisaatiot pystyvät usein tarjoamaan siivua tähän erikoistuneesta seniorista osana projektimyyntiään, mutta toisaalta toimittajan arkkitehdin näkökulma ei koskaan vastaa täysin asiakkaan arkkitehtiä. Täysin optimaalista ratkaisua harvoin löytyy.

Tee miten teet, kunhan teet hyvin

IT-projektimaailma hakee vieläkin täydellistä toimintamallia, koska edelleen niin iso osa hankkeista epäonnistuu. Agilen ydinviesti on aivan oikea. Ihmisläheinen, nopea iterointi on lähes aina parempi kuin byrokraattinen suunnittelun ja toteutuksen kireä vaiheistus. Mutta ketteryydenkin kanssa tärkeimmäksi haasteeksi nousee vastuunkanto: Kuka on valmis tekemään sen raskaan ajatustyön, jota uuden järjestelmäkokonaisuuden vaatimusten kunnollinen määrittely vaatii? Kenen tehtävä on miettiä, miten vaadittu järjestelmä toimii kahden, viiden tai kymmenen vuoden päästä, kun muut järjestelmät ja liiketoiminta ympärillä muuttuvat? Onko paikalla aina joku, jolla riittää rohkeus puhaltaa pilliin, kun vaikuttaa siltä, että toteutus etenee väärillä raiteilla?

Ajatus siitä, että jokainen asiakas tekisi tämän työn sataprosenttisesti talon sisällä, omilla palkatuilla ihmisillään, on epärealistinen. Tekijöitä ei yksinkertaisesti riitä kaikille, ja vaikka niitä jotenkin maagisesti saisikin, vain harvalla suomalaisella organisaatiolla riittää resursseja ja projekteja myös ylläpitää osaamista tilanteessa, jossa pilvipalvelut, valmiskirjastot ja verkon käyttötavat uusiutuvat jatkuvasti.

Asiakkaat tulevat tarvitsemaan ulkoa ostamista, ja alan tekijät tulevat tarvitsemaan työpaikkoja, joissa useissa hankkeissa kiertäminen antaa heille monipuolisemman näkemyksen siitä, mitä kaikkea voi tehdä. Tämä monipuolisuus kääntyy pitkällä tähtäimellä myös asiakkaan eduksi. Vastapainona on tietysti ratkottava haasteita viestinnässä, asiakkaan toimialan opiskelussa ja organisaatiorajojen ylittämisessä.

Vaikka Devisioona onkin henkilöstövuokrauksen sijaan nimenomaan toimitusvastuullisten projektien tiellä, emme suinkaan pidä CV-kauppaa saati asiakasorganisaation omia devaajia mitenkään huonona mallina. Koemme kuitenkin, että Vierityspalkin avauksesta lähteneessä keskustelussa esiintynyt markkinauskoinen ”Toimittajathan tarjoavat vain sitä mitä asiakkaat haluavat”-liturgia on turhan optimistinen. Jutun ilmestymisen jälkeen useampikin kontaktimme on todennut, että mieluummin hän ostaisi projekteja toimitusvastuulla ja kunnon kumppanimallilla, saatavuudesta vain on pulaa.

Lopulta olennaista on toki tehdä laatua. IT-alan suurin vihollinen on huono IT ja siihen liittyvät dramaattiset epäonnistumiset. Useimmissa asiakasorganisaatiossa hankejohtaminen ja arkkitehtuuriajattelu hyötyvät ulkopuolisesta näkökulmasta ja toimittajan lisäkysymyksistä, riskiarvioista ja kyseenalaistuksista. Ennen sopimusmallin valintaa kannattaa huolella puntaroida, mihin omat rahkeet riittävät – sekä projektivaiheessa että elinkaaren myöhempinä vuosina.

Haluatko sparrailla toimitusmalleista? Kaipaatko valvontakonsulttia? Vai ehkä sitä ihan vastuullista toimitusprojektia? Ota yhteyttä!

Jouni Heikniemi

Jouni on 25 vuoden uransa aikana tehnyt kaikkea helpdeskistä henkilöstöjohtamiseen ja koodauksesta kolvaamiseen. Hänen erityisalaansa ovat Microsoft-teknologioiden käyttöönotot, monimutkaiset ongelmat sekä ohjelmistotuotannon laatukysymykset. Jouni on Devisioonan toimitusjohtaja ja yksi maailman 160 Microsoft Regional Directorista.