Hallitse tuotekehitystä

Julkisuudessa näkyy silloin tällöin kertomuksia kehityshankkeista, jotka ovat ’lähteneet lapasesta’ – eli karanneet käsineestä.

Katso kauhutarina vaikka täältä https://www.kauppalehti.fi/uutiset/13-epaonnista-suomalaista-it-projektia-naihin-hassattiin-miljoonia-euroja/jQkpLdMY.

Ennen kuin syvennymme tarkemmin siihen, miten kehitystyötä voi – ja pitääkin – ohjata, heitän ilmaan kysymyksen: Mihin verrattuna näiden varoittavina esimerkkeinä toimivien hankkeiden aikataulu ja kustannukset olivatkaan ylittyneet?

• Kilpailijoiden tekemiin tarjouksiin nähden…?
• Realistiseen ja objektiiviseen arvioon verrattuna…?
• …vai ylioptimistiseen toiveeseen verrattuna?

Monet näistä esimerkeistä ovat laajoja ohjelmistokehityshankkeita, joissa sekä työhön osallistuvien sidosryhmien että tarvittavien toimintojen määrä on suuri, joten kaupan kohteen määrittely on ymmärrettävästi vaikeaa. Voi olla, että joissain tapauksissa sen paremmin ostaja kuin myyjä eivät ole kyenneet riittävän hyvin hahmottamaan sopimuksen kohdetta – ts. itse tehtävää. Näin tarjouspyynnön, tarjouksen ja hankinnan kohde on enemmän tai vähemmän yksilöimätön, erittelemätön ’möhkäle’.

Suunnittelu-, toteutus- ja käyttöönottovaiheen jälkeen onkin sitten ilmeistä, että niin lopputulos kuin kustannuksetkin poikkeavat ajatellusta.

Oli kyseessä sitten ohjelmisto tai fyysinen tuote, tuotteen kehitys on hallittava prosessi. Työn ei tarvitse olla epätoivoista painimista ylittyvien kulujen kanssa. Tarvitaan vain maalaisjärkeä, luotettava kumppani ja realistinen mieli. Näin pääset tavoitteeseen odottamallasi tavalla.

Ensimmäinen vinkki: Ulkoista vain se minkä sisäistät

Perehdy omaan asiaasi kunnolla ennen kauppoihin ryhtymistä. Selvitä itsellesi, mikä hankkeessa on helppoa ja mikä vaikeaa. Vaikeat osa-alueet sisältävät yleensä myös suurimmat riskit. Vaikeimpien osa-alueiden toteuttamisessa on tavallisesti myös vähemmän vaihtoehtoja kuin helpoimmissa.

Ellet onnistu selvittämään vaikeita osa-alueita omin voimin, keskustele potentiaalisen tuotekehityskumppanisi kanssa: hyvä kumppani kertoo sinulle avoimesti ja liioittelematta, missä riskit piilevät, mikä on vaativaa ja mikä ei. Näin sinulle syntyy parempi käsitys hankkeestasi.

Kokonaiskuvan muodostettuasi jatkokeskustelu niin teknisestä toteutuksesta ja riskeistä kuin hankkeen kustannuksista ja aikatauluistakin on helpompaa kuin optimistisen tai jopa virheellisen käsityksen perusteella.

Toinen vinkki: Halvin ja kallein tarjous eivät aina ole yhteismitallisia

Kaupallisen toiminnan perusteet: Myyjä pyrkii tekemään tarjouksen, jolla kauppa saadaan syntymään. Vastaavasti ostaja havittelee edullista – jos nyt ei aina edes halvinta mahdollista – tarjousta samasta aiheesta.

Saamiesi tarjousten hinnat todennäköisesti poikkeavat toisistaan. Tämä ei välttämättä tarkoita sitä, että eri yritysten hinnoittelu olisi toisistaan merkittävästi poikkeava. Kuten sanotaan: ’Devil is in the details’.

Todellisuudessa tarjousten sisältö ei välttämättä vastaa toisiaan, olkoonkin että saat tarjouksen tehtävästä tuotteesta. Asiaa sivuttiin jo tämän kirjoituksen alussa: Tuote voi olla monimutkainen tai moniulotteinen kokonaisuus, jonka tarkka kuvaaminen etukäteen (määrittely) on käytännössä hyvin vaikeaa tai jopa mahdotonta.

Sinulla on yksi mielikuva lopputuloksesta, tarjoajilla omansa. Näin saat monen hintaisia vaihtoehtoja samasta asiasta – et samaa lopputulosta eri hinnoilla.

Analogiana: pyydä tarjous kylpyhuoneen remontista…takaan, että saat monta erihintaista tarjousta, joiden sisältö on totta tosiaan erilainen. Olkoonkin, että kaikissa tarjotaan sinulle remontoitu kylpyhuone.

Kolmas vinkki: Keskustele, keskustele, keskustele

Tarjouspyyntöjen lähettelyn sijaan voi olla parempi strategia valita uskottava toimija ja huolehtia hyvän ja luottamukseen perustuvan yhteistyön muodostamisesta (yhteistyökumppani) – ja pyrkiä yhteisymmärryksessä laatimaan ’hyvä kehitysprojekti’ – syntyy siitä sitten lopulta hanke tuotteen kehittämiseksi tai ei.

Tarjoajat voivat rakentaa tuotteen (suunnittelu) monin tavoin ja eri lähtökohdista, esimerkkeinä vaikkapa

• Ensimmäinen perustaa tarjouksen vanhaan tekniikkaan. Valmiin ratkaisun voimin tarjouksen hinta saadaan alas ja aikataulu lyhyeksi. Sinä saat edullisen tarjouksen ja jo valmiiksi vanhahtavaan tekniikkaan perustuvan tuotteen.
• Toinen haluaa käyttää tarkoituksenmukaisia ratkaisuja eduksesi. Se ei ole nopein tie valmiiseen tuotteeseen, sillä uuden tekniikan käyttöönotto maksaa ja hankkeen hinta on korkeampi. Sinä maksat hankkeesta enemmän mutta sen käyttöarvo ja elinkaari ovat pidempiä.
• Kolmannella on meneillään kehityshanke toiselle asiakkaalle. Tarjoaja haluaa käyttää samoja ratkaisuja myös sinun tuotteessasi hankkeen kustannusten alentamiseksi. Sinä saat tuotteen ihan kohtuullisella hinnalla mutta tuotteen toteutustapa on kaukana tarkoituksenmukaisesta. Tuotteen valmistushintakin voi olla tarpeettoman korkea.
• Neljäs rakentaa tuotteen teknologiainnostusta tihkuen: Vain paras on hyvää, ja parhaan voi korvata ainoastaan kallein ja monimutkaisin ratkaisu… Hanke maksaa ja suunnittelu kestää. Mutta saatpa tosi hienon ratkaisun tarpeeseesi, ehkäpä liiankin hienon. Niin tuote kuin sen ylläpitokin maksavat.
• …

Käymällä avointa keskustelua valitsemasi tuotekehityskumppanisi kanssa pääset oikeimpaan lopputulokseen niin valittujen ratkaisujen kuin kehityskustannustenkin osalta. Ymmärrät samalla, mistä hinta muodostuu, mitkä ovat riskit – ja mitä etuja ja haittoja kustakin valinnasta seuraa sinulle. Kyseessähän on sinun tuotteesi.

Samalla myös tuotekehityskumppanisi välttyy kustannuksiltaan tarpeettoman kalliin tai sinun kannaltasi vääräsisältöisen tarjouksen laatimiselta. Jos tarjoajalla ei ole riittävästi tietoa käytettävissään, arvauksiin perustuvasta ja tarpeettomat riskit sisältävästä tarjouksesta tulee kallis.

Neljäs vinkki: Kiinteä hinta ei ole aina paras vaihtoehto

Koska tuotekehitykseen liittyvien asioiden hallinta tuntuu vaikealta, kiinteän kauppahinnan pyytäminen tuntuu usein selvimmältä ja vähiten riskejä sisältävältä tavalta hallita kehitystyötä.

Joskus näin onkin – usein kuitenkaan ei: kiinteällä kauppahinnallakin on hintansa. On eri asia tilata kiinteällä hinnalla tontille 10 kuormaa soraa kuin tilata kiinteällä hinnalla uusi tuote, jollaista ei ole vielä nähtykään.

Soraa on tavallisesti varastossa, kuljetusta on harjoiteltu kymmeniä vuosia, kuorman koko ja kuljetuskustannukset tiedetään matkaan perustuen. Näin hinnan määrittely soraerälle on sangen suoraviivaista.

Tuotekehityksen osalta lähtökohdat ovat erilaiset:

• Sinun tuotteesi on tekijälle useimmiten uusi tuttavuus, josta ei ole aiempaa kokemusta
• Tavallisesti työssä käytetään uusia osia, komponentteja, tekniikoita, ohjelmistokirjastoja, joiden toiminta, käyttöönotto ja mahdollisten ongelmien selvittelyn helppous ja nopeus riippuvat mm. näiden osien toimittajan ja valmistajan kyvykkyydestä – ei varsinaisen suunnittelutyön tekijän omista toimenpiteistä
• Tekijä ei tiedä ennalta, miten paljon ylimääräistä työtä ja viiveitä ostajan oma toiminta, päätöksenteon hitaus tms. aiheuttavat
• Työhön sisältyy vaiheita (prototyyppi, muutettu prototyyppi, ensimmäinen testilaite…), joiden määrää ei tunneta ennalta ja jotka vaikuttavat paitsi työmäärään myös aikatauluun ja tarvittavien osien määrään testaaminen, mittaaminen, viranomais- tai hyväksyntävaatimusten täyttäminen onnistuu kerralla – tai sitten nämä vaativat muutoksia
• Haluat varmasti sanoa sanasi vaikkapa tuotteen ulkomuotoon, ohjelmien käyttöliittymiin jne. Epäselvää on kuitenkin se, miten paljon ja moneen kertaan haluat näihin muutoksia

Kun tämä lopultakin epämääräinen sisältö paketoidaan koviin kuoriin (kiinteän hinnan ja aikataulun muotoon), tarjoaja joutuu väistämättä sisällyttämään tarjoukseen riskejä ja varautumaan, jos nyt ei ihan worst case ‑vaihtoehtoon, ylimääräiseen ja ennakoimattomaan työhön. Lisäksi kehitystyön tarjoaja joutuu tavalla tai toisella huolehtimaan, että työ etenee omalta kannaltaan viivytyksittä.

Mahdollisia työnaikaisia muutoksia, viiveitä voidaan hallita jossain määrin vaikkapa erityisen muutoksenhallintaprosessin ja mahdollisten sanktioiden avulla. Usein tästä muodostuu kuitenkin kankea, hankala ja enemmänkin työn edistymistä haittaava kuin sitä kehittävä prosessi.

Lopuksi

Tuotteiden kehitystyö on aina luottamuksellista toimintaa, jossa tarvitaan hyvää yhteispeliä tuotteen omistajan ja sen kehittäjän välillä. Usein tämä yhteistyö kannattaa aloittaa jo hankkeen alkumetreillä: kehitysprojektin etenemisen, aikataulun ja kustannusten hahmottelun sekä potentiaalisten riskien kartoituksen yhteydessä.

Näin voit varmistaa, että puhut samaa kieltä yhteistyökumppanisi kanssa, tiedät mistä kustannukset ja aikataulu muodostuvat ja tiedät miten työ etenee. Näin on myös helpompi ymmärtää kehitystyön vaiheet ja edistyminen. Hyvin harvoinhan uuden kehittäminen tapahtuu etenemällä suoraviivaisesti pisteestä A pisteeseen B.

Jos olet harkitsemassa uuden tuotteen kehitystä, aiemman parantamista tai ideasi kaupallistamista, haluan rohkaista sinua avoimeen keskusteluun hyvän yhteistyökumppanin kanssa tarjouskilpailun järjestämisen sijaan. Laadukas toimittaja pystyy auttamaan sinua monin tavoin asiasi edistämisessä, ja pääset varmasti parempaan lopputulokseen kuin lähettelemällä tarjouspyyntöjä eri suuntiin.