Ekstraregninger er en af de hyppigste kilder til strid i IT-projekter. Leverandøren mener, at et arbejde lå uden for aftalen og skal betales ekstra. Kunden mener, at det var en del af den faste pris eller en rettelse af fejl. Hvem der har ret, afhænger af, hvad der er aftalt, og af, om ændringen blev bestilt og godkendt på den måde, aftalen kræver. Det kan kun afgøres, hvis I har holdt styr på ændringerne, mens projektet kørte.
Artiklen er til projektlederen, IT-chefen og økonomiansvarlige, der godkender fakturaer. Den handler om de rutiner, der gør det muligt at dokumentere ændringer bagefter.
Hvorfor ændringer bliver til tvister
De fleste IT-aftaler har en ændringsprocedure. Statens standardkontrakter til IT-projekter har det, og leverandørernes egne vilkår har det som regel også. Proceduren beskriver typisk, at et ønske om ændring skal fremsættes skriftligt, at leverandøren skal beskrive konsekvenserne for pris og tid, og at ændringen først er aftalt, når begge parter har accepteret den.
I praksis bliver proceduren ofte ikke fulgt. Ændringer aftales på et statusmøde, i en chat eller i en kommentar i projektværktøjet. Ingen skriver et ændringsbilag, og ingen taler om pris, før fakturaen kommer. Så står parterne med hver sin hukommelse.
Typiske situationer
- En medarbejder hos jer beder udvikleren om “lige” at lave en ekstra rapport.
- Leverandøren siger på et møde, at en ændring “nok ikke betyder noget for prisen”.
- Et krav er formuleret uklart, og leverandøren mener, at jeres forståelse er en udvidelse.
- Leverandøren fakturerer timer til fejlrettelser som ændringer.
- Tidsplanen skrider, og leverandøren forklarer det med ændringer, som I ikke opfatter som ændringer.
Alle fem er almindelige. Ingen af dem behøver at være ond vilje. Men de bliver dyre, hvis der ikke findes et spor.
Ændringsloggen
Det vigtigste værktøj er en ændringslog, som jeres projektleder fører fra første dag. Den kan ligge i et regneark eller i projektværktøjet.
- Nummer · Fortløbende, så der kan henvises entydigt
- Ønsket af · Navn og rolle, hos jer eller leverandøren
- Dato · Hvornår ønsket blev fremsat
- Beskrivelse · Hvad skal ændres, med henvisning til kravet
- Type · Ændring, fejlrettelse eller præcisering
- Pris og tid · Leverandørens estimat og konsekvens for tidsplanen
- Status · Afventer, godkendt, afvist, gennemført
- Godkendt af · Navn, dato og hvor godkendelsen står
Feltet “type” er det vigtigste. Det er her uenigheden opstår. Skriv jeres opfattelse ned med det samme, og hvis leverandøren er uenig, så skriv også det. En uenighed, der er noteret undervejs, er langt lettere at håndtere end en, der dukker op på fakturaen.
Fastpris eller timepris
Hvordan ekstraregninger skal vurderes, afhænger meget af prismodellen. Ved fastpris er spørgsmålet, om arbejdet lå inden for det aftalte omfang. Ved timepris er spørgsmålet oftere, om timerne var nødvendige og faktisk brugt. Mange projekter blander de to, fx fastpris på en grundleverance og timepris på ændringer. Notér i ændringsloggen, hvilken prismodel hver ændring hører under, og gem leverandørens tilbud og estimater sammen med ændringen. Et estimat, der blev overskredet uden varsel, er et andet spørgsmål end en ændring, der aldrig blev prissat.
Faste regler for jeres egne folk
Mange ekstraregninger skyldes, at kundens egne medarbejdere bestiller ting uden at vide, at de gør det. Lav nogle få klare regler:
- Kun navngivne personer må bestille ændringer hos leverandøren.
- Alle ønsker går gennem projektlederen og ind i ændringsloggen.
- Ingen ændringer aftales mundtligt. Bliver noget aftalt på et møde, skal det fremgå af referatet og af loggen.
- Pris og tid skal kendes, før arbejdet begynder, også når beløbet er lille.
- Fejlrettelser er ikke ændringer. Er I i tvivl, så skriv det i loggen som omstridt.
Fortæl også leverandøren, hvem der må bestille. Så har leverandøren svært ved bagefter at fakturere arbejde, som en tilfældig medarbejder bad om.
Fakturaerne
Gennemgå hver faktura mod ændringsloggen, før den betales. Spørg skriftligt til timer, der ikke kan henføres til et godkendt ønske. Betaler I uden indsigelse, kan det senere blive brugt som et tegn på, at I accepterede arbejdet. Betaler I med forbehold, så skriv forbeholdet i en mail samme dag.
Bed om timeopgørelser med beskrivelse af opgaven, ikke kun antal timer. Er timerne registreret i leverandørens projektværktøj, kan det være relevant at bede om et udtræk. Hvis I har mistanke om, at der er faktureret timer, der ikke er brugt, er det beskrevet for sig. → Leverandøren har faktureret timer, der ikke er brugt
Gem sporene i værktøjerne
Ændringer efterlader spor mange steder: i mails, i chats, i sager i projektværktøjet, i kodehistorikken og i versioner af kravspecifikationen. Sørg for, at det hele bliver bevaret.
- Gem alle versioner af kravspecifikationen, ikke kun den seneste.
- Eksportér sager fra projektværktøjet med kommentarer og ændringshistorik.
- Gem referater med dato og deltagere.
- Bed leverandøren om at bevare kodehistorikken, hvis I ikke selv har adgang.
Et versionsspor i et dokument kan vise præcis, hvornår et krav blev ændret, og af hvem. → Versionshistorik: hvem ændrede kontraktudkastet?
Hvem gør hvad
- Projektleder · Fører ændringsloggen og godkender ønsker
- Medarbejdere · Sender ønsker til projektlederen, ikke direkte til leverandøren
- Økonomi · Holder fakturaer op mod loggen
- IT-chef · Sikrer eksport fra projektværktøjer og kodehistorik
- Ledelse · Godkender større ændringer og budget
Det må I ikke gøre
- Godkende ændringer i en chat og glemme at føre dem ind.
- Slette gamle versioner af kravspecifikationen.
- Betale stille for timer, I mener er fejlrettelser.
- Lade uenigheder ligge til projektets afslutning. Tag dem op, mens de er små.
- Skrive, at “alt er i orden” i en mail, hvis der er åbne spørgsmål om pris.
Når regningen allerede er kommet
Står I med en stor ekstraregning, og har I ikke ført en log, så er det ikke for sent at samle sporene. Gå baglæns gennem mails, referater og projektværktøjet, og byg loggen op med henvisninger til dokumenterne. Markér, hvad der er rekonstrueret. En ærlig rekonstruktion er bedre end ingen. → IT-projektet er gået galt: jeres første skridt
Hvornår skal I have hjælp udefra?
Når uenigheden handler om, hvad der teknisk er en ændring, og hvad der er en fejlrettelse, eller om timerne svarer til det udførte arbejde. En uvildig IT-sagkyndig kan holde kravspecifikation, kodehistorik og sager op mod hinanden og vurdere de tekniske spørgsmål. Nielco IT er uvildig og sælger ikke produkter. Den juridiske side af IT-kontrakttvister er beskrevet for advokater. → IT-kontrakttvister og digitale beviser
Læs også: Overtagelsesprøven fejlede: hvad nu? · SaaS-leverandøren lever ikke op til SLA’en: kundens dokumentation
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
