Du bruger dit review forkert, hvis du først påberåber din kontraktuelle ret til et uvildigt review, når din styregruppeformand, Ulla mister tålmodigheden og for femte gang siger “Det er simpelthen uacceptabelt!…”.
Statusrapporteringen på jeres projekt har længe været “grøn”, så gik den i “gul” og var efter yderligere uger i “rød”. Når først projektet er gået i rødt og Ulla handler på baggrund af, hvad hun ser som et svigt i leverancen, bliver det uvildige review et værktøj til at få leverancen tilbage på sporet. Men et review kan også – når det bliver brugt rigtig – være et værktøj, der holder leverancen på sporet, så I undgår ”røde” statusrapporteringer, konflikter og dyre tvister. Læs mere om, hvad et review er her.
Hvorfor skal du reviewe (før det går galt)?
Det enkle svar: Fordi du har ret til det, og leverandøren har godt af det. OG så kan det spare dig for forsinkelser og fordyrelser.
Et godt gennemført review, der initieres rettidigt – dvs. før styregruppeformanden, Ulla mister tålmodigheden – er din sikring af, om projektet er kommet godt afsted og om it-leverancen er som forventet. Og ikke mindst: Reviewet giver en indsigt, der kommer i tide, så styregruppen fx kan gribe ind og leverandøren har en chance for at ændre sit løsningsforslag.
Men kan de ikke bare lave det der it ordentligt fra starten af? Jo, selvfølgelig skal du stille gode krav til kvalitet, test, dokumentation osv. Og du skal huske at lave gode kontrakter, der gør disse krav forpligtende og mulige at følge op på. Men det er sjældent et forkert semikolon, der får projektet til at vælte.
Klassiske problemer
Klassiske problemer med forsinkelser og fordyrelser til følge …
Ved systemleverance
- (Nedarvet) teknisk gæld fra eksisterende kodebase eller integrationer.
- Mangelfuld dokumentation eller dokumentation, der ikke er retvisende.
- Store skift i arkitektur og/eller teknologi uden tilstrækkelig dokumentation eller begrundelse.
- Scope creep og scope drifting. At den udviklede funktionalitet fraviger fra den ønskede – men måske ikke specificerede – forretningsfunktionalitet.
Ved projektet
- Manglende forståelse og overensstemmelse mellem funktionelle krav (kundens forretningskrav), løsningsdesignet og de planlagte test.
- Svag leverandørstyring. Ofte pga. scourcing-strategier, der er gået “for dybt”, så kundesiden stort set har mistet de nødvendige kompetencerne for at være “den gode bestiller”.
- Det agile vandfald. Et ønske om at være agile med sprint osv. uden modenheden eller styrringsredskaberne til at efterleve det.
Erfaringsmæssigt dokumenterer reviews ofte, at der er en langt større og ulogisk vilje til at smide nye penge efter at lappe på dårligt konstruerede systemer fremfor at afskrive det gamle og starte forfra. Fx vil et rettidigt gennemført review af systemets arkitektur og tekniske design tidligt kunne afdække, om der er truffet valg, der er uhensigtsmæssige for platform og it-arkitektur set i forhold til dine (måske nye) behov eller nye teknologier på markedet. Nogle gange er en mindre afskrivning af en udviklingsindsats – og “at smide kode i havnen” – det bedste og billigste scenarie.
Fordi reviews ofte gennemføres for sent kommer resultaterne også på bordet (for) sent i processen, og så sker der med stor sandsynlighed et tab af tillid mellem dig og leverandøren – en tillidskrise, der kan være svær at komme over. Derfor bør du lægge review-aktiviteten ind i projektets økonomi- og betalingsmodel som en tydelig og eksplicit post. Fx som en fælles – og dermed delt – aktivitet, som skal foregå ved fx kritiske faseovergange i projektet.
Sådan bruger du dit review rigtigt
Alene det at muligheden for at anvende reviews og rammerne er aftalt fx i kontrakten, gør det nemmere at udtrykke ønske eller krav om et review, så det ikke opfattes som en eskalation og et kampskridt. Nedenstående er tre bud på, hvordan du allerede fra i morgen kan begynde at indføre og anvende reviews mere strategisk og aktivt i dine projekter.
- Tjek din kontrakt. Måske har I allerede aftalt muligheden for på udpegede tidspunkter eller ved faseovergange at iværksætte et review eller en inspektion. Se om der i jeres vilkår er angivet årsager, der kan/skal initiere et review, og se om der i kontrakten allerede er formuleringer om parternes krævede bidrag til gennemførelsen.
- Sæt jer om bordet. Det kan være en god idé at samle sit team eller projekt omkring bordet og afstemme forventningerne til reviews. Fx kan det være godt, hvis både den indkøbsansvarlige, bestilleren (forretningsrepræsentanten) og den it-udviklingsansvarlige kender til mulighederne, som et review giver. Og at de forstår deres rolle og bidrag, hvis et review skal indføres og gennemføres.
- Læg din strategi. Hvis I står overfor at skulle lave en aftale eller en kontrakt omkring en it-leverance, så overvej i projektet, hvor og hvordan I evt. vil anvende reviews og typen af reviews. Endelig bør I overveje, om reviews skal indgå som en fast bestanddel af jeres standardkontrakt.
