urakkapalkka

Niin, pitää määritellä millaiseen tuotteeseen se urakka päättyy. Sen jälkeen asiakkaalla on velvollisuus tehdä vastaanottotarkastus, jonka jälkeen asiakkaalle räpsähtää lasku ja siirrytään ylläpitovaiheeseen. Ylläpitovaiheen laskutuksen periaatteetkin on hyvä kirjata valmiiksi: "korjaan vastaanottotarkastuksen läpäisseitä bugeja xx euroa/tunti".

Ja vastuurajoitus mistä tahansa, 15% urakkasummasta.

"Meneekö helposti riitelyksi asiakkaan kanssa?"

Ei, kun on kirjattu yksityiskohtaisesti mitä ollaan tekemässä ja kirjattu, että muista projektin aikana esille tulevista asioista sovitaan uusilla sopimuksilla. Ja että asiakkaalla on rajallinen aika tehdä vastaanottotarkastus.

Melkein aina asiakas on motivoitunut ottamaan työn vastaan. Jollei ole, niin syynä on melkein aina, että sillä on rahat loppu. Jos se on henkilökysymys niin ohita kyseinen tulppa.

Vuoden vaihteen jälkeen kävi sillä tavoin, että erään suuryhtiön tilaaja alkoi vänkäämään jälkikäteen laskusta, kun niiden viimeinen neljännes oli mennyt huonosti, ja ilmeisesti budjettia oli kiristetty.

Eräs vähemmän luotettavana tunnettu pienyrittäjä halusi ehdottomasti toimituksen ensin ja maksun vasta sitten. Se kyllä meni sitten käteismaksulla :-)

Erään amerikkalaisen suuryrityksen Tanskan haarakonttori oli maksuhaluton kunnes niille kerrottiin, että etsimme sopivaa perintätoimistoa Tanskasta.

Jos pienyrityksessä vastapuolena on pahimmassa tapauksessa joku pikkurikollista liiketoimintatavoiltaan muistuttava niin samanlainen riesa on joku tahvo suuryrityksessä.

Kiinteän hintainen urakka on siinä mielessä hankala, että se vaatii tilaajalta systemaattista ajattelua sekä omien tarpeiden ymmärtämistä. Pahimmillaanhan vastapuoli ei edes pyri hyvään yhteistyöhön,vaan jopa leipomaan sopimuksiin erilaisia miinoja tarkoituksena kiristää ylläpitoa samaan sopimukseen.. "ulkoistamaan ongelmat"
On myös täysin inhimillistä, että helpompi arvostella valmista työtä kuin speksata mitä softalta todella halutaan.

Vastapuolen päättäjänä on yllättävän usein joku business-henkinen tuotepäällikkö tms taho, jolle syy- ja seuraussuhteet eivät ole aina täysin selviä.. Esim jos koodataan ylitöinä (intiaaneilla) purkka- ja liimavirityksillä, niin mitä siitä seuraa.

Summa summarum: onnistuu jos vastapuoli on riittävän ammattitaitoinen