Fiksu toimittaja aikatauluttaa toimitusprojektin asiakkaalle sopivaksi. Siihen ei vaikuta, onko toimitettava tuote valmisohjelmisto vai yhteiskehittämiseen perustuva ohjelmisto, jonka ominaisuuksia voidaan muuttaa (toimitamme). Suurin hankintayksikön hankintapäätökseen vaikuttava aikataulu-ero voisi olla, jos koodataan asiakkaalle kaikki tyhjästä, koska asiakas haluaa koodin (emme toimita näitä) tai koska toimittaja ei halua ylläpitää palvelua ja jatkokehittää sitä (me haluamme).
Yhteiskehittämisessä etsitään asiakkaalle sopivin IT-ratkaisu. Se voi tarkoittaa, että täysin uusien näkymien ja toiminnallisuuksien sijasta vain konfiguroidaan ohjelmisto. Muutetaan esim. asetuksia, yhdistellään komponentteja tai vielä ylemmällä tasolla niin, että liitetään kokonaisuudeksi työkaluja ja muutetaan brändiväri. Yhteiskehittämisen resurssit ohjataan näissä tilojen, statusten, metatietojen, kategorioiden, oikeusasetusten ja oikeusryhmien sopimiseen asiakkaan kanssa ja varsinaisiin käytännön kokeiluihin, joissa asiakas pääsee vaikuttamaan lopputulokseen.
Kun ohjelmisto on lähempänä valmisohjelmistoa kuin ohjelmistoprojektia, merkittävin resurssi tarvitaan toimintamallien ja työprosessien sujuvoittamiseen hankintapäätöksen jälkeen. Kun ne on saatu päätettyä, on järjestelmän toimittaminen jo melko helppoa ja vie vähemmän aikaa.
Kokeilevissa yhteiskehittämisen toimitusprojekteissa on kunnollinen määrittelyvaihe, mutta se jakautuu osin myös kokeilujaksoille.
Määrittely lähtee yhtiön tai organisaation omista toimintamalleista ja niiden hiomisesta kuntoon. Kannattaa tunnistaa, mitä ollaan muuttamassa ja miksi ennen kuin muutokset tehdään. Aseta tavoitteet.
Ikävä kyllä yhteiskehittämisestä puhuminen voi joskus olla myynnissä jopa vaarallista! Se kuulostaa työltä eikä ostaja halua ostaessaan kuulla, että ohjelmiston toimitusprojekti yhdistettynä käyttöönottoprojektiin aiheuttaa aina työtä. Ihan niin kuin maratonille tai pikamatkalle treenauskin, kun haluaa olla huippuhyvä eikä keskiverto tai huonompi.
Mitä paremmin saadaan selvitettyä, mitä halutaan saada aikaan (vaatimusmäärittely), sen helpompi on yhteiskehittämiseen perustuvan ohjelmiston toimittajan ymmärtää, mitä ollaan ratkaisemassa ja miksi. Toisaalta yhteiskehittämisessä kaikkea ei tarvitse olla heti alussa selvillä. Riittää, että näkemys selkityy kokeiluissa ja että hankkeessa on toimittajalle resursseja varattuna niin, että kokeilujen aikana löydetyt muutostoiveet voidaan vielä toteuttaa ylittämättä alkuperäistä budjettia.
Ei ole ollut yksi tai kaksi kertaa, että asiakas vaatii esimerkiksi massiivisten Excelien latausmahdollisuutta, kunnes huomataan, että todellinen tarve onkin suodattaa ja hakea tietoa niin, että on helppo tarkastella tilastoja. Ei siinä ole oikeasti paras ratkaisu toteuttaa ladattavia Exceleitä, vaan varmistaa, että haku, filtterit, palvelun tietokannasta poimittu tieto taulukossa ja tilastografiikka toimivat.
Käyttötapaus avaakin silmiä usein paremmin kuin tekninen toiminnallisuudesta esitetty vaatimus.
Jotta palvelu tulee käyttöön, tarvitaan käyttöönottovaihe. Muista valita organisaationne sisältä henkilöt, jotka ovat valmiita muuttamaan asioita ja ne henkilöt, jotka osaavat innostaa ja neuvoa muita. Joskus yhdessä henkilössä on molemmat hyvät puolet, mutta ellei ole, laajenna tiimiä.
Yksi käyttöönottokoulutus on alku, mutta se ei ole koko käyttöönottovaihe, josta organisaatio ottaa aina itse suurimman vastuun. Johtajat tai valitsemanne henkilöt tai yksittäiset tiimit / yksiköt näyttävät esimerkkiä, jota muut seuraavat. Kun yksi tai kaksi mielipidejohtajaa ja vaikuttajaanne lipsuu ohjelmiston käytössä, ote kirpoaa lopuiltakin. Vältä tätä. Vaadi, motivoi ja johda. Näytä esimerkkiä itse.