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.