Miksi työmääräarviot ja projektikustannukset yleensä ylittyvät?

Esimerkkinä digitaalisen palvelun kytkeminen asiakkaan järjestelmän tuottamasta datasta

Vaihe 1. Myynti

Palvelutoimittaja pääsee tapaamaan asiakasta. Myyjällä on asiakkaasta jotain alkutietoja ja oletuksia. Myyjä yrittää saada asiakkaan kertomaan tapaamisessa tarpeistaan tarkemmalla tasolla. Käynnin jälkeen myyjä tarjoaa asiakkaalle ratkaisua. Samalla käydään läpi mitä palvelu pitää sisällään. Asiakas kiinnostuu. Myyjä tekee tarjouksen. Syntyy kaupat. Sopimuksen liitteenä on palvelukuvaus. Palvelu on myyty asiakkaalle kiinteällä hinnalla, tietyillä ennakkotiedoilla ja työmääräarvioilla. Myyjä muistuttaa asiakasta, että palvelun toteutustiimiin projektipäällikkö vahvistaa lopullisen työmäärän ja projektikustannukset.

Vaihe 2. Projekti käynnistyy

Toimittajan projektipäällikkö tapaa asiakkaan. Käydään läpi sopimuksen sisältö, alustava työmäärä ja kustannusarvio sekä palvelun sisältö tarkemmalla tasolla. Projektipäällikkö selittää asiakkaalle mitä tietoja ja aineistoja asiakkaalta tarvitaan palvelun toteuttamista varten. Keskustellaan myös aikataulusta. Palvelu toteutetaan ns. vesiputousmallilla, eli perinteisellä projektimallilla.

Määrittelyjä läpikäydessä käy selväksi, että palvelu, joka sopimuksessa mainitaan, ei vastaa täysin asiakkaan tarpeita. Tarvitaan palvelun räätälöintiä. Tässä vaiheessa toimittajan projektipäällikkö ilmoittaa, että alkuperäinen työmääräarvio ei tule riittämään, koska projektin sisältö muuttuu räätälöinnin takia. Näin ollen tarvitaan x määrä lisää työtä. Alkuperäiset projektikustannukset tulevat ylittymään.

Asiakas on ihmeissään ja vähän nyreissäänkin. Nyt hän joutuu käymään sisäiset keskustelut ja perustelut, jotta ekstra raha irtoaa projektiin. Palvelu on kuitenkin hänelle tärkeä. Asiakas hyväksyy lisäkustannuksen.

Vaihe 3. Toteutus 

Toimittajan projektipäällikkö päivittää projektisuunnitelman ja toteutuksen työmääräarviot sekä aikataulun. Aikataulussa on huomioitu myös mitä tarvittava räätälöinti tarkoittaa toteutuksen lisäksi testauksessa. Hän arvioi teknisen tiiminsä kanssa, että x määrä tunteja tarvitaan. Tärkeää on myös, että aineisto täyttää testaukselle vaaditut laatuvaatimukset. Laatuvaatimukset on läpikäyty asiakkaan kanssa projektin määrittelyvaiheessa. Palvelun toteutus voi alkaa. Toteutus valmistuu määräaikaan mennessä.

Vaihe 4. Testaus

Päästään testaamaan. Asiakas ilmoittaa, että heillä ei ole mahdollisuutta sittenkään testata sovitulla syklillä ja myös testiaineiston toimituksessa on ongelmia. Aikataulu venyy.

Aineisto saapuu toimittajalle. Ensimmäisen testikierroksen jälkeen todetaan, että aineisto ei täytä testaukselle sovittuja laatuvaatimuksia. Tarvitaan sekä lisäaikaa, että lisäkierroksia testaukseen. Projektipäällikkö nostaa esille taas muutoksenhallinnan. Perusteluna aikataulun venyminen ja projektikustannusten ylittyminen, koska alkuperäinen testauksen määrä ei riitä. Muutoksenhallinnassa on uusi arvio työmäärästä, kustannuksesta ja aikataulusta. Asiakas käy jälleen kerran sisäiset keskustelut projektikustannuksista ja pyytää lisärahoitusta.

Minkä takia työmääräarviot eivät pidä paikkaansa ja kustannukset ylittyvät?

Yllä mainittu tilanne kuvaa projektikustannusten määrittelyn haasteellisuuden niin myyntivaiheessa, projektin alussa ja jopa sen aikana.

No minkä takia?

Myyntivaiheessa voi olla haastavaa saada asiakkaalta kaikki tarvittava tieto. Asiakkaan ostava taho ei ehkä tunne tarpeita kovin tarkkaan tai hänellä ei ole tietoa tai ymmärrystä lähtöjärjestelmästä tarvittavan detaljilla tasolla. Toimittajan myynnillä voi olla rajoittuneet tiedot palvelun teknisistä riippuvuuksista.

Projekteissa tilanteet elävät usein. On useita osapuolia. Asiakkaalla voi olla vaikeuksia tuottaa tarvittava aineisto, tässä tapauksessa luoda testiaineistoa laadukkaasti. Tämä voi johtua siitä, että asiakkaalla ei ole aikaa tehdä aineistoa. Asiakkaan järjestelmän testiympäristö voi olla puutteellinen tai vanhentunut. Se ei vastaa täysin tuotannossa olevaa järjestelmää ja tämän takia aineiston laatu ei ole tarpeeksi hyvää.

Palvelun räätälöinti asiakkaalle voi vaikuttaa myös asiakkaan lähtöjärjestelmään. Asiakas voi joutua tilaamaan muutoksia omalta järjestelmätoimittajalta. Tällä voi olla vaikutusta niin aikatauluun kuin projektikustannuksiin.

Kiinteällä hinnalla ja perinteisellä projektimallilla toimitettu palvelu tai tuote sisältää aina tiettyjä oletuksia. Lähtötiedot perustuvat pitkälti olettamuksiin ja projektin toteutus perustuu määrittelyissä läpikäytyihin ja saatuihin tietoihin. Tämän takia työmääräarviot ja projektikustannukset usein ylittyvät alkuperäisestä.

Mikä tähän olisi ratkaisu? Nappaa vinkit  edellisistä artikkeleista ja pysy kuulolla. Seuraavassa artikkelissani kirjoitan ketteristä menetelmistä.

 

Close Menu