Avtalen med kunden er endelig signert og etter flere iterasjoner med kunden, er du og teamet ditt endelig i klar for å starte. Alle gleder seg til å sette i gang, men så kommer tvilen. La vi inn tilstrekkelig med buffer i prisestimatene? Tok vi høyde for at det også vil gå med tid til administrasjon? Har vi tenkt på infrastrukturkostnader? Du blir usikker og istedenfor å glede deg over en signert avtale, begynner du allerede å se mulige fallgruver.
De fleste fallgruver i et IT-prosjekt har sitt opphav i tvetydighet.
Kunden vil som regel ha forutsigbarhet på de to prosjektparametre som i IT-verden blir mer og mer vanskelig å ha kontroll over; omfang og kostnad. I et omskiftelig teknologisk landskap, kan disse to aspektene være svært tidkrevende å få kontroll over. I noen tilfeller tar sikringen av scope og kost så lang tid at behovet som opprinnelig skulle løses, har endret karakter og man må tilbake til start. Derfor ser vi en gryende trend at flere velger en FoU-tilnærming (forskning og utvikling) til IT-utvikling. Med en FoU-tilnærming aksepterer man høy grad av usikkerhet og hyppige endringer. I en mer tradisjonell prosjekttankegang er dette elementer man helst vil minimere. Uansett hvilken tilnærming du velger, finnes det fallgruver, men om du navigerer riktig fra start, kan du unngå store minefelt.
Det viktig at begge parter går inn i prosjektet med realistiske forventninger. IT-utvikling er innovasjon og man må derfor omfavne usikkerheten den bringer med seg. Om man ikke har råd til å feile, da bør man heller ikke starte et digitaliserings- og utviklingsprosjekt. Både leverandør og kunde må være omforent om at det alltid vil være forhold som ikke er avdekket. Begge må være villig til å akseptere en viss grad av risiko før man setter i gang prosjektet. Et godt sted å starte er å etablere en risikomatrise i starten av samarbeidet som aktivt brukes gjennom prosjektet. Ikke bli overrasket om det kommer nye risikoer til underveis. Det er helt normalt, men de må synliggjøres for begge parter og håndteres i fellesskap.
#MeetOurTeam – bli bedre kjent med Maria som har skrevet denne bloggposten. >
De fleste virksomheter kan ikke sette i gang et prosjekt eller utviklingsløp uten å ha en formening om kostnad. Derfor er det vanlig å estimere hva det koster det som skal utvikles, men om man skal oppgi estimater, så er det viktig å ha tydelige forbehold og antagelser rundt estimatene. Det er naturlig at scopet utvides, men man bør vite når det utvides og synliggjøre dette for begge parter. Dersom tid er den mest kritiske faktoren for leveransene, så er dette helt essensielt for bevisstgjøring av konsekvensene for tidslinjene i prosjektet.
Videre er det er viktig å tydeliggjøre forskjellen på et kostnadsestimat og fastpris.
Et estimat er ikke en fastpris, det er en pekepinn på omfang og kompleksitet. Fastpris bør man kun operere med dersom alle behov og byggeklosser er kjente. I typiske utviklingsprosjekter bør man unngå denne prismodellen, fordi den vanskeliggjør endringshåndtering som ofte fører til uenighet.
Det betyr likevel ikke at man ikke skal ha rammer når man driver utvikling. En tidsramme eller et budsjett åpner for en FoU-tilnærming til IT-prosjekter samtidig som man har kontroll på kostnadene.
Jeg tør påstå at ingen IT-prosjekter går bra med mindre partene er dedikerte og har like mye eierskap til leveransene. Noen avtaletyper ivaretar dette bedre enn andre. Det er viktig at partene kjenner innholdet i avtalen godt og er enige om risikoen ved oppstart. Sett derfor opp et halvdagsmøte for å gå gjennom avtalen og sørg for at dere har samme forståelse av punktene som omhandler omfang, fremdriftsplan og prisbestemmelser. Vanlige oppdragsavtaler håndterer også kritiske områder som test, produksjonssetting og godkjenning. Dette er områder med potensielt store merkantile konsekvenser. En god idé kan derfor være å ha med seg en nøytral juridisk part inn i møtet.
Dersom det er viktig å komme raskt i gang med prosjektet og det er aksept for utvikling under fail fast-prinsippet, er bistandsavtalen mye bedre egnet enn de klassiske oppdragsavtalene.
I Cegal leverer vi tjenesten Project Office Service. Dette er et fleksibelt rammeverk som hjelper deg og bedriften din til suksess.Tjenesten støtter ulike virksomheter med å prioritere hvilke prosjekter de bør initiere for å kunne levere på selskapets visjon og optimalisere porteføljen for maksimal avkastning. Dette innebærer bedre styring over risikoer, ressurser, kvalitet, tid og scope. Project Office Service tilbyr kundene våre et fleksibelt rammeverk for prosjektplanlegging, ledelse og gjennomføring av IT-leveranser. Basert på hvor din bedrift er med hensyn på digitalisering, tilpasser vi verktøy, metode og grad av styring. Våre konsulenter er sertifisert innenfor kjente leveranseformer og vi tilbyr variert erfaring og kompetanse innen prosjektledelse, teamledelse, smidig ledelse og produktledelse.
Les om hvordan Cegal leverer vellykket prosjekter uavhengig av størrelse eller kompleksitet. >
Les hva Computerworld skriver om saken her >