Unngå at it-prosjektet blir et minefelt av konflikter
Altfor ofte hører vi om it-prosjekter som ender med uenighet og konflikter, der noen dessverre også blir mat for advokatene. Det er synd, for det er enkelt å unngå at prosjektet blir et minefelt av uenigheter. Her er mine tre tips til suksessfulle it-prosjekter.
Avtalen med kunden er
endelig signert og alle gleder seg til å sette i gang, men så kommer tvilen: Er
det lagt inn tilstrekkelig med buffer i estimatene? Er det tatt høyde for at
det vil gå med tid til administrasjon? Er det tenkt på infrastrukturkostnader?
Du blir usikker og begynner å se mulige fallgruver.
De fleste fallgruver i et it-prosjekt har sitt opphav i tvetydighet. Kunden vil som regel ha forutsigbarhet på de to parametre som i it-verden blir stadig vanskeligere å ha kontroll over: omfang og kostnad.
Men hvordan skal man navigere i dagens omskiftelig teknologisk landskap med høy grad av usikkerhet og hyppige endringer uten at prosjektfallgruvene blir et minefelt? Min erfaring, etter mange år som leder for større produktutviklingsteam, er at det er særlig tre faktorer som avgjør om et it-prosjekt blir en suksess eller konfliktfylt.
1. Forventningsstyring
Det viktig at partene går inn i prosjektet med realistiske forventninger. IT-utvikling er innovasjon og man må derfor omfavne usikkerheten den bringer med seg. Har man ikke råd til å feile, bør man heller ikke starte et digitaliserings- og utviklingsprosjekt. Både leverandør og kunde må være villig til å akseptere en viss grad av risiko før man setter i gang prosjektet. Og det er helt normalt at nye risikoer dukker opp underveis, men de må synliggjøres for alle og håndteres i fellesskap.
2. Tydelige forbehold rundt kostnader og tidslinjer
Knapt noen kan sette i gang et prosjekt uten å ha en formening om hva det vil koste. Derfor er det vanlig å estimere en pris på det som skal utvikles, men det er viktig å ha tydelige forbehold rundt estimatene. Det er naturlig at prosjekt utvides, men man må vite når det utvides og gjøre dette klart for alle parter. Videre er det er viktig å tydeliggjøre forskjellen på et prisestimat og en fastpris. Et estimat er bare en pekepinn på omfang og kompleksitet. Fastpris bør man kun velge dersom alle behov og byggeklosser er kjente. I typiske utviklingsprosjekter bør man unngå dette fordi det gjør det vanskelig å håndtere endringer. Det betyr likevel ikke at man ikke skal ha rammer når man driver utvikling. En et budsjett gjør at man har kontroll på kostnadene.
3. Riktige avtaler der alle forstår sitt bidrag
Ingen IT-prosjekter går bra med mindre alle parter er dedikerte og har like mye eierskap til leveransene. Derfor er det viktig at partene kjenner innholdet i leveranseavtalen godt. Sett 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.Disse områdene kan få store merkantile konsekvenser. En god idé er å ha med seg en nøytral juridisk part inn i møtet.
