2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011” och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.

Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!

Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel. Nu är det allt fler som förespråkar att Pust Java återinförs

Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?

Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.

Vi är insiders. Håkan Rydman var anställd som testledare på RPS i 7 år, deltog i Pust Java och hade direkt insyn i Pust Siebel. Henrik Kniberg är lean/agile konsult och deltog i Pust Java som coach. Arbetssättet (baserat på Lean + Agile) anses var en av framgångsfaktorerna för det projektet, och har beskrivits i en bok.

Utöver vår egen erfarenhet som deltagare så har vi läst interna rapporter från Pust Siebel (häpnadsväckande läsning!) och pratat med många andra projektdeltagare. Vi är arga och ledsna över att RPS bränner våra skattepengar och försämrar polisverksamheten, och med det riskerar ett otryggare samhälle.

Det har skrivits mycket om Pust, både i pressen och i påkostade analyser internt på RPS. Men de viktigaste lärdomarna går ofta förlorade i bruset.

Så vad hände egentligen?

Efter den lyckade lanseringen av Pust Java togs ett strategiskt beslut att övergå till s.k. standardsystem. Avsikterna var goda, att minska förvaltningskostnaderna.

Tyvärr gjordes ett dåligt teknikval – Siebel. CIO på RPS och konsulter från Oracle (leverantören av Siebel) övertygade RPS ledning om att det skulle vara billigt och enkelt att bygga om systemet i Siebel. Deras förstudierapport[1] var en orgie i önsketänkande. IT avdelningen protesterade högt, både muntligt och skriftligt[2][3]. De ansåg att Siebel var en mycket olämplig teknikplatform för Pust, och att användarnyttan offras till förmån för en hypotetisk kostnadsminskning. Till deras stora chock togs beslutet ändå.

Dessutom gjordes ett dåligt processval – att bygga och releasa hela systemet på en gång istället för börja med en mindre pilotrelease till en begränsad användgrupp. Tidiga pilotreleaser var en viktig framgångsfaktor för Pust Java. En pilot hade bevisat (tidigt och billigt) att Siebel var fel teknik, och man hade kunnat avbryta projektet eller utforska ett nytt spår. Men nu byggde man istället klart och släppte Pust Siebel till hela Sverige på en gång, och först då blev det bevisat att systemet var på gränsen till oanvändbart.

Vid det laget var det mycket svårt och dyrt att fixa felen, eftersom systemet var byggt på en olämplig teknikplattform i grunden. Målet var att minska förvaltningskostanden, men resultat blev värre än motsatsen – en sämre produkt, ursinniga poliser, försämrad rättssäkerhet, och ökade förvaltningskostnader![4][5]

Här finns en mer detaljerad redovisning av händelseförloppet från två av deltagarna.

Lärdomarna som behöver spridas är:

1) Ta aldrig viktiga tekniska beslut utan att blanda in de som ska bygga systemet. I RPS-fallet fick teamet ge input, men beslutet var redan taget innan så det gjorde ingen skillnad.

Risken för felaktiga och därmed kostsamma tekniska beslut minskar radikalt om man följer denna lärdom. Men risken finns alltid, därför måste man också:

2) Jobba iterativt i samråd med riktiga användare. Släpp tidiga och begränsade pilotversioner till riktiga användare. Förbättra produkten kontinuerligt utifrån deras feedback.

Punkt 1 minskar risken för dåliga beslut.

Punkt 2 minskar konskevensen av dåliga beslut, eftersom man upptäcker problemen tidigt.

I kort: IT projekt som inte gör detta bör aldrig finansieras!

Om alla IT beslutsfattare tillämpar denna beslutsregel, så minskar risken för nya stora haverier. Projekt kommer fortsätta att misslyckas ibland, men det blir små misslyckanden istället för stora katastrofer.

Pust Siebel är bara ett av många exempel på varför detta är så viktigt.

Iterativ systemutveckling är inget nytt. Det är grunden i både Lean och Agile och bygger på över 50 års branscherfarenhet. Men iterativ utveckling är varken enkelt eller smärtfritt – det krävs ett aktivt engagemang från verksamheten under hela projektet, och att man vågar släppa tidiga, ofärdiga versioner till pilotanvändare som vågar testa i fält. Man upptäcker sina felaktiga antaganden och tekniska problem tidigt, och förbättrar produkten kontinuerligt utifrån riktig användfeedback.

Detta var en av de största framgångsfaktorerna för Pust Java. Så varför fick inte teamet fortsätta jobba iterativt och kontinuerligt förbättra Pust Java?

Det är en komplex fråga som handlar om mjuka faktorer som politik, ego, organisationskultur och ledarkompetens. Inga enkla problem ett fixa, troligtvis behövs ett helt nytt ledarskap.

Men denna artikel handlar inte om vad RPS ska göra, utan om vad alla andra företag och myndigheter kan lära sig.

Systemutveckling är alltid riskabelt och komplext. Iterativ utveckling minskar projektrisken radikalt. Pust Siebel-fiaskot är ett dyrt exempel på hur man inte ska bedriva projekt, men om lärdomarna sprids så har de förlorade skattemiljarderna åtminstone kommit till någon nytta.

–Henrik Kniberg & Håkan Rydman

Feb 2014

Referenser

