Jos ei tee mitään, ei tapahdukaan mitään, ei edes virheitä. Toivottavasti kuitenkin osaamme ottaa virheistä opiksemme, sillä päätä ei kannata paukuttaa seinään saman erheen takia kovin montaa kertaa. Kokosimme tähän kirjoitukseen tuotekehityksen yleisimpiä virheitä ja kerromme, mitä olemme oppineet niistä.
Projektilla on aina olemassa jokin tavoite. Tavoitteeseen pääsee monella eri tavalla, mutta työmäärään ja kustannuksiin vaikuttaa suuresti, mitä vaatimuksia projektissa kehitettävälle tuotteelle määritellään.
Vaatimusten määrittely muodostaa raamit ratkaisulle. Se toimii myös tarkistuslistana, johon projektin tuloksia voi verrata. Vaatimusmäärittely on siis listaus, josta selviää tuotetta koskeva informaatio, vaatimukset ja toiveet.
Otetaan esimerkiksi kirves. Projektin tavoitteena on kehittää tuote, jolla voidaan pieniä pölkkyjä klapeiksi. Kirves-nimiseen tuotteeseen voidaan määritellä halkaisukyvyn lisäksi muitakin ominaisuuksia. Siinä täytyy olla hyvä terä, tukeva varsi sekä pitävä kädensija. Lisäominaisuudeksi määritellään iskuvoiman analysointi ulkoisen näytön liitännällä.
Mikä meni pieleen?
Se, mitä vaatimuksia kirveeseen määritellään, eli speksataan, kannattaa puntaroida tarkasti tuotteen haluttuja ominaisuuksia vastaan. Onko hyvä terä tarpeen, jotta saavutetaan hyvä halkaisukyky? Kyllä. Entä tukeva varsi ja pitävä kädensija? Kylläpä kyllä. Mitenkäs on iskuvoiman analysoinnin kanssa, ulkoisen näytön liitännällä?
Niinpä niin.
Lisäominaisuuksien suhteen tulee olla hyvin kriittinen, sillä lisätyt ominaisuudet merkitsevät lisättyjä kustannuksia.
Jos ylimääräisiä ominaisuuksia lähdetään toteuttamaan ilman liiketaloudellisia perusteita, kustannukset karkaavat helposti käsistä. Pahimmassa tapauksessa kirves on iskuvoima-analysaattorin takia niin kallis, ettei sen tuotto riitä kattamaan kehityskustannuksia koko elinkaaren aikana.
Vältä siis virhe numero yksi siten, että pidät projektin tavoitteen kirkkaana mielessä ja pysyttelet vaatimusmäärittelyssä. Älä innostu rönsyilemään yli speksien!
Olemme useasti ylioptimistisia aikataulun suhteen. Ajattelemme työn sujuvan suit sait sukkelaan aikataulun mukaan tai jopa sen edellä. Mutta raaka totuus on, että jos Murphyn laki voi toteutua jossakin, niin se todennäköisimmin toteutuu aikataulussa.
Projektissa on niin monta muuttujaa, että väistämättä aina tapahtuu jotakin odottamatonta. Jos oman tiimin työ sujuu ilman viivytyksiä, viive todennäköisesti tapahtuu jossakin toisessa kohtaa toimitusketjua.
Projektin aikataulu on äärimmäisen tärkeä osa viestintää. Se kertoo, kenen vastuulla mikäkin asia on, kuka työn tekee, milloin se tehdään ja miten paljon työtä mihinkin vaiheeseen liittyy. Avoin vuorovaikutus ja säännölliset statuspalaverit ovat hyväksi havaittu keino varmistaa, että koko projektiorganisaatio on tietoinen mahdollisista muutoksista aikataulussa.
Summa summarum: vältä virhe numero kaksi olemalla realisti aikataulun suhteen – jossakin se kyykkää, ihan varmasti. Siksi aikatauluun kannattaa laittaa pelivaraa aina kun se on mahdollista. Mieluummin ollaan etuajassa kuin myöhässä!
Ottakaamme esimerkiksi yksinkertaien kuluttajatuote. Projektin budjetti täytyy jakaa niin, että se kattaa esiselvitykseen, muotoilun, elektroniikka-, ohjelmisto- ja mekaniikkasuunnittelun lisäksi komponenttien hankinnan, prototyyppien rakentamisen, testauksen, dokumentoinnin, hyväksynnät ja projektinhallinnan – ja kenties vielä jotain muuta?
Minkä tahansa projektin budjetointi ja kustannusten hallinta on tasapainottelua projektin laajuuden, aikataulun ja laadun kanssa. Kuten aikataulunkin kanssa, yllätyksiä tuppaa putkahtelemaan ja rahaa pitäisi riittää myös odottamattomiin kuluihin.
Mikä siis avuksi?
Virheen numero kolme voit välttää tekemällä inhorealistisen budjetin. Vertaa toteutuneita projekteja ja tutki, mistä kustannukset ovat todellisuudessa koostuneet. Erittele kaikki tekeminen ja niihin liittyvät kustannuserät. Seuraa toteutuneita kustannuksia säännöllisesti ja pidä projektiryhmä tietoisena tilanteesta.
Jos vaikuttaa, että budjetti ei riitä jossain osa-alueella, eikä lisärahoitusta ole saatavilla, muuta suunnitelmia. Lukujen viilaaminen ei auta.
Joskus voi käydä niin, että projekti ei etene oikealla tavalla henkilöistä johtuvista syistä. Heillä ei kenties olekaan juuri kyseiseen projektiin tarvittavaa osaamista tai eteen tulee henkilöstä itsestään riippumattomia syitä, jotka estävät tai hidastavat työskentelyä. Tällöin tilanne vaatii korjaavia toimenpiteitä.
Projektin henkilöstön vaihtaminen ei ole ihan yksinkertaista, sillä se voi johtaa budjetin ylittymiseen tai vaarantaa aikataulun. Tuotekehityksen asiantuntijat usein kiinni jossain toisessa (ja kolmannessa ja neljännessä) projektissa, jolloin yhden projektin uudelleen aikatauluttaminen voi johtaa muidenkin projektien aikataulujen muuttumiseen. Eteen voi tulla myös yllättävää kustannusten kasvua, jos jo aikaisemmin tehtyjä töitä täytyy tehdä uudelleen.
Projektinhallinnassa on suurimmaksi osaksi kyse ihmisistä ja heidän tekemänsä yhteistyön toimivuudesta. Projektipäällikön rooli on keskeinen projektin menestyksen kannalta. Hän huolehtii, että tiimihenki on hyvä ja porukka työskentelee hyvin yhteen. Vähintään yhtä tärkeä on projektipäällikön toinen tehtävä projektin operatiivisena johtajana, joka varmistaa, että tavoitteet saavutetaan olemassa olevilla resursseilla.
Kullakin asiantuntijalla täytyy tietysti olla tarvittavaa kompetenssia ja monialaisesta osaamisesta on paljon hyötyä, koska silloin henkilöiden on helpompi katsoa asioita laajemmasta perspektiivistä. Ja vaikka projektipäällikön merkitys on suuri, projektitiimissä kaikilla on vastuu hyvän yhteishengen luomisesta, uusien ideoiden miettimisestä, tulosten raportoinnista ja aikataulujen noudattamisesta.
Virhe numero neljä on siis taklattavissa oikeilla henkilövalinnoilla, hyvällä tiimihengellä ja avoimella keskustelulla.
On viisasta tunnistaa tarvitsevansa apua, kun omat resurssit eivät riitä. Ota yhteyttä myyntiimme, niin jutellaan, kuinka voimme auttaa sinua.
Tarjoamme asiantuntijapalveluina mm. ohjelmistosuunnittelua, sulautettuja järjestelmiä, elektroniikka-, mekaniikka- ja automaatiosuunnittelua (PLC) sekä lämpö- ja mekaniikkasimulaatioita.