Ketteryydessä ei ole mitään uutta. Päinvastoin, ketterät kehitysmenetelmät ovat olleet olemassa paljon pidempään kuin moni muu IT-alan kuuma puheenaihe. Ne tarjoavat vaihtoehdon perinteisille vesiputousprojekteille, jotka tukeutuvat vahvasti etukäteen tai hyvin varhaisessa vaiheessa laadittuun dokumentaatioon. IT-hankinnoissa hyödynnettävien ketterien menetelmien yhteinen nimittäjä on perinteiseen projektitoimitukseen verrattuna vähäisempi dokumentaatio ja projektin kohteen täsmentyminen osapuolten yhteistyön edetessä.

IT-markkinaa tuntevan juristin on helppo todeta, että ketterän kehitysmenetelmän projektisopimuksiin törmää huomattavasti harvemmin kuin perinteisiin vesiputousprojekteihin. Mistä tämä johtuu? Ei ainakaan ketterien menetelmien vähäisestä käytöstä. Väitämme, että ketterien projektisopimusten karttamiseen liittyy kaksi juurtunutta käsitystä:

  1. Ketterä projekti ei tarvitse sopimusta, koska juristin laatima sopimus tappaa kaikki ne hienot tavoitteet, joihin ketterän kehitysmenetelmän valinnalla on pyritty.
  2. Jos sopimus on pakko laatia, sen pitää olla mahdollisimman suppea. Vanhat sopimusarkistot ovat täynnä pohjia projektia varten.

Molemmat väitteet ovat pielessä. Vesiputousprojektiin laadittu sopimus ei taivu ketteräksi nimeä muuttamalla. On totta, että liian yksityiskohtainen sopimus poistaa koko ketteryyden, mutta liian joustava sopimus tai sopimukseton tila etenee ketterästi kohti kaaosta. Juristin näkökulmasta ongelmana ei ole sopimuksen jäykkyys, vaan vääränlainen sopimus. Mietitty, projektiin soveltuva sopimus tukee oikeanlaisen toimittajan löytämistä hankkeen toteuttamiseen ja sitouttaa oikeat asiantuntijat projektiin.

Ongelmana vakiintuneen sopimuskäytännön puute

Asiaan perehtymättömälle ketterän sopimuksen laatiminen voi olla haastava tehtävä, koska ketterille projekteille on olemassa vasta vähän vakiintunutta sopimuskäytäntöä. Konkreettinen esimerkki ovat nykyisin voimassa olevat IT2010- ja JIT2007-vakioehdot, joiden uusiin versioihin suunnitellaan ketterien projektien sopimusehtoja vasta nyt, vaikka ketterät kehitysmenetelmät tulivat noin 15 vuotta sitten.

Sopimusta valmisteltaessa tulisi huomioida ketterien projektien erityispiirteet. Ketterät sopimukset ovat omanlainen maailmansa, jossa viljellään erityistä agile-terminologiaa: puhutaan esimerkiksi sprinteistä, backlogista, DoD:stä ja scrum masterista. Termistöä tärkeämpää on kuitenkin ymmärtää, miten nämä käsitteet heijastavat ketteryyttä tai miten niiden pitäisi vaikuttaa sopimuksen sisältöön. Sopimuksen tulisi kuvata, miten projekti etenee, miten päätökset tehdään ja miten lopputulokset hyväksytään. Sopimuksessa olisi myös syytä käyttää ketterälle kehittämiselle ominaista termistöä.

Asiakas on aktiivisessa roolissa ketterän projektin edetessä

On selvää, ettei projektin onnistuminen riipu pelkästään sopimuksen hyvyydestä (tai huonoudesta). Ihanteellisessa ketterässä projektissa osapuolina ovat sitoutunut asiakas ja osaava toimittaja.

Suurimmat virheet saatetaan tehdä jo hankintavaiheessa, ellei sopivan toimittajan ja oikeanlaisen projektitiimin valintaan panosteta riittävästi. Laiminlyönnillä voi olla vakavat seuraukset, sillä ketteryydessä on kyse tiimityöstä. Ihannetapauksessa yhteistyö johtaa siihen, että projektissa saavutetaan tavoitellut tulokset, jotka mukautuvat asiakkaan tarpeisiin, ja päästään eroon raskaasta dokumentaatiosta. Muutostarpeet huomioidaan niiden ilmaantuessa, eikä resursseja tarvitse uhrata tarpeettomiin muutoksenhallintamenettelyihin.

Toisaalta ketteryydessä on kyse nimenomaan tiimityöstä. Ketterä projekti vaatii asiakkaalta huomattavasti enemmän osallistumista ja asiantuntemusta kuin perinteinen projekti. Toisinaan asiakkaalta puuttuvat tarvittava tietotaito ja resurssit. Asiakkaan toiveissa saattaa olla joustava, asiakkaan tarpeisiin mukautuva projekti, jossa tulokset toimitetaan avaimet käteen -mallilla. Ketteryys ei ole mahdollista, ellei asiakas osallistu projektitoimintaan aktiivisesti ja säännöllisesti tai ehdi antaa palautetta ja havainnoida muutostarpeita. Asiakkaan osallistumisen lisäksi tärkeää on, että asiakasorganisaatiossa on projektiin omistautunut henkilö, jolla on ajantasainen tieto projektin etenemisestä ja joka pystyy valtuuksiensa rajoissa tekemään asiakkaalta vaadittavat päätökset ja linjaukset asiakkaan puolesta. Vesiputousmallinen projekti tulee asiakkaan pöydälle hyväksyttäväksi kerralla tai korkeintaan muutamassa osassa. Ketterä projekti sen sijaan edellyttää jatkuvaa hyväksymismenettelyä ja samalla selkeää päätöksentekomenettelyä.

Toisinaan vastapuolen hyväntahtoisuuteen luotetaan jopa sokeasti kumppanuushenkeen ja ketteryydelle ominaiseen epämuodolliseen yhteistyömalliin vedoten ja keskeisiä asioita jätetään kirjaamatta sopimukseen. Myöhemmässä vaiheessa toimittaja hankkii ehkä rahakkaamman projektin eikä kumppanuuslupauksilla ole enää niin suurta merkitystä. Ketterässä projektissa tärkein resurssi ovat osaavat asiantuntijat. Jos oikeita asiantuntijoita ei sitouteta projektiin, voi yksikin vaihdos tehdä aikaansaaduista tuloksista jopa käyttökelvottomia. Ketteryys ja sen edellyttämä osaaminen on henkilösidonnaista.

Luottamus osapuolten välillä on tietysti tärkeää, mutta projektiin sitoutuneen osapuolen ei pitäisi arkailla kumppanuushengessä luvattujen asioiden kirjaamista sopimustekstiin.

Rahalle vastinetta?

Oma kysymyksensä on myös sopimuksen kohde. Toisinaan ketterissä projekteissa ajaudutaan ongelmaan, jossa osapuolet ryhtyvät toteuttamaan projektia vailla tarkempia määrityksiä ja asiakas maksaa toimittajan laskut kuukausittain käytetyn työajan perusteella. Tällöin kyse ei välttämättä ole enää projektitoimituksesta, vaan yhteistyö saattaa muistuttaa ennemminkin asiantuntijakonsultointia, vailla mitään lopputulosvastuuta.

Asiakkaan näkökulmasta projektitoimituksen etuna on lähtökohta toimivien lopputulosten syntymisestä. Jos kohdetta ei ole määritelty millään tasolla, riskinä on, ettei projektin lopputuloksiin tyytymättömän asiakkaan ole mahdollista saattaa toimittajaa vastuuseen pieleen menneen projektin sisällöstä.

Toisaalta herää kysymys siitä, miten sopimuksen kohde ylipäänsä määritellään, kun jo ketteryyden ideologian mukaan sopimuksen kohde täsmentyy projektin edetessä. Lähtökohdaksi projektin kohteen määrityksessä voidaan ottaa esimerkiksi tietty vähimmäistaso, joka lopputulosten on täytettävä ja jonka täytyttyä voidaan sopia jatkokehityksestä asiakkaan toiveiden ja resurssien mukaisesti.

Sopimuksesta pitäisi käydä ilmi, mitä ostaja on ostamassa ja mitä myyjä on myymässä. Monissa ketterissä sopimuksissa näin ei ole. On vain haavekuva ketteryydestä, joka ratkaisee kaikki ongelmat.

Hybridisopimuksessa on piirteitä molemmista malleista

Ketteryyden määrä ei ole projekteissa vakio. Käytännössä tehdään paljon hybridisopimuksia, joissa otetaan aineksia sekä ketteristä että perinteisistä projekteista. Syynä voi olla esimerkiksi se, että hankkeen liiketoiminnalliset intressit edellyttävät tiettyjä vesiputousmallin mekanismeja. Väärinkäsitysten välttämiseksi käytettävän menetelmän kuvaukseen olisikin syytä panostaa ja huolehtia, että molemmilla osapuolilla on yhteisymmärrys siitä, mitä ketteryydellä kyseisessä projektissa tarkoitetaan.

Jos ketterää menetelmää ei määritellä riittävän selvästi, jos projektin edellyttämästä dokumentaatiosta tai osapuolten välisestä kommunikaatiosta tingitään tai jos osapuolilla ei ole riittävää tietotaitoa ketteryydestä, ajaudutaan helposti ns. lumivyöryongelmaan. Tavoitellaan ketteryyttä, mutta tosiasiassa toimitaan perinteisen projektin mukaisesti. Tämä voi pahimmillaan johtaa molempien menetelmien huonoimpien käytäntöjen soveltamiseen.

Sopimusta laadittaessa tulee huomioida riittävä tasapaino ketteryyden, ennustettavuuden ja muiden liiketoiminnallisesti tärkeiden intressien välillä. On kuitenkin muistettava, että ketteriin projekteihin liittyy paljon muitakin kuin sopimusteknisiä pulmia.

Ketteryys ei sovi kaikkiin projekteihin

Ketterää projektia harkittaessa on mietittävä, voiko kyseisen projektin toteuttaa ketterästi. Kysymys liittyy ensisijaisesti siihen, kuinka bisneskriittinen projekti on ja mikä on hankkeen taloudellinen arvo. Ketterää sopimusta (kuten muutakin IT-sopimusta) laadittaessa tulee harkita huolellisesti, onko yhtiöllä riittävästi resursseja ja osaamista projektin toteuttamiseen ketterästi ja kestääkö projektin kohde ketteryydelle ominaisen iteratiivisuuden.