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
- [1] Förstudierapport för implementation av Pust i Siebel.
- Johan Söng (Oracle) m.fl. diarenr ITS-179-5044/11
- [2] Kommentarer till förstudierapport
- Tomas Alsterlund, Projektledare PUST Java. Diarnenr PVS-171-3001/09
- [3] Granskning av förstudie – implementation av Pust i Siebel
- Jan Sahlander (IT arkitekt, UFE, RPS). 2011-10-14
- [4] Siebel Project Review – Slutrapport för Rikspolisstyrelsen
- Simon Mills (IBM) m.fl. 2013-04-29
- [5] Utvärdering av ärendehanteringssystemet SiebelPUST
- Ernst & Young, 2013-10-01
Jag håller med om din slutsats.
Men det är viktigt att belysa att båda dina två punkter drar med sig helt andra problem som också måste manageras och kan skapa lika mycket problem.
1) Att det finns teknik och plattformskramar på IT-avdelningarna är ett faktum. Det är inte säkert att de alltid är bäst lämpade att ta beslut om teknisk plattform för nyutveckling. Det här ser man både bland java och .net-utvecklare samt tex Notes och SharePoint specialister. Ibland behöver folk skakas om och tvingas att byta spår.
2) Det du beskriver här är smärtfritt vid green-field utveckling. Det är mer komplicerat vid samexistens. Piloter är svåra för data som är viktig och måste vara del i ett större flöde. Ta exemplet kassa-system. Att köra pilot på några kassor kan ju funka ur ett användarperspektiv, men vad ställer det tex för krav på beslutsstöd eller integrationer. Skall de produktionssystemen anses vara en konsument av piloten och riskera felaktigheter?
Så även om jag håller med att dina två punkter är önskvärda, det är sällan så svart eller vitt som du beskriver här.
Det var ju inte “green-field” som var skillnaden mellan de två ansatserna.
Just att de två ansatserna var så lika i utgångspunkt gör detta till ett mycket intressant fall att studera.
Ditt exempel med kassa-system, vart leder det? Varför skulle inte det gå? Varför är det värre att fel i en begränsad pilot än i ett större “big-bang” lanserat system?
Det är svart eller vitt. Antingen försöker du minimera riskerna genom att minimera releaserna eller så rullar du ut en stor release.
Att påstå att det är svart eller vitt är ganska naivt.
Att uttrycka att en modell funkar bäst i alla lägen utan att ens sätta sig in i förutsättningarna är ganska naivt.
Det är romantiserande ideologi.
Så fort det du skall bygga måste vara en del i ett större system och inte en isolerad ö skapar strategin med en “pilot” merarbete och risk som måste hanteras.
I just exemplet kassasystem finns det många komplicerande faktorer för de flesta butikskedjor. Som supply chain management, logistik-optimering, bokföring och revisions-compliance.
Att få till små iterationer med piloter i de läget visar sig ofta ganska snabbt inte bli särskilt små eller särskilt snabba för att kunna hålla sig till lagkrav.
Och igen, jag säger inte att korta iterationer är fel och att big bang är bättre. Vad jag säger är att man skall passa sig för att ge generella råd baserat på ett isolerat exempel. Särskilt som man bara sitter på förstahandsinformation i ett av de två fall man tycker sig “bevisar” tesen.
Lean är ju inte i första hand en modell eller ett verktyg utan baseras på principer. En princip är att tät återkoppling (korta iterationer, små lager etc) minskar risken för att göra på fel sätt för länge. En ganska enkel princip som de flesta kan förstå.
Problemet är att många tror att agilt/lean är ett verktyg som man till punkt och pricka måste följa.
I ditt fall med kassasystemen så skulle ju användargränssnittsdelen kunna utvecklas med korta iterationer, och integrationsdelen med längre iterationer (men samtidigt söker man efter sätt att minska även denna återkopplingstid).
I fallet med lagkrav och hur de kan påverka så är det ju klart att det ställer krav som kanske inte går att anpassa sig till. Detta medför ju i sin tur en ökad risk för fel och en ökad risk för ett fördyringar eller ett misslyckande. Denna olyckliga konsekvens är något man tyvärr får köpa i just detta fall.
Allt handlar om kompromisser med principerna som ett grundläggande stöd. Det gäller alltså att förstå skillnaden mellan principer, metoder och verktyg. Att anpassa metoder efter principerna och att anpassa verktyg efter metoderna.
För att tillägga,
Jag kan göra samma jämförelse med ett big-bang (tom vattenfall)-projekt som lyckade och ersatte ett agilt-projekt som gått åt skogen innan.
Betyder det att vi kan dra en slutsats att vattenfall är bättre i alla lägen och att oavsett förutsättningar och krav så kommer det alltid att lyckas med vattenfall bättre än agilt?
Troligtvis inte.
Dogmatism är farligt.
Japp. Om det hade varit lätt att jobba iterativt så hade kanske alla gjort det. Men att det är svårt är ingen ursäkt för att skippa iterationer. Det finns gott om metoder och erfarenhet om hur man kan göra.
I Pust Java levererade vi en pilot till Östergötland med stöd för bara 1-2 brottstyper, och itererade tillsammans med de poliserna tills systemet var bra nog att sprida vidare. Release varann månad med direkt feedback från riktiga användare. Byggde gradvis ut till flera län och la till flera brottstyper, för att på så vis säkerställa användarnyttan. Visst kostar det på att ha en sån tät feedbackloop och så många releaser och förändringar. Men att rulla ut ett oanvändbart system är ännu dyrare.
Att bedriva IT projekt med statliga medel utan att jobba iterativt bör vara ett straffbart brott!
Det är den typen av dogmatism som får projekt att misslyckas. Om det var något som jag trodde var genomgående i Lean så var det att inte låsa fast sig vid en modell för alla projekt.
I just PUST-fallet var det rätt modell. Men det stämmer inte i alla fall.
Genomgående i Lean är fokus på användarbehov och kort feedbackloop. Icke-iterativa Big Bang projekt är motsatsen till Lean. Det finns tillräckligt många exempel på havererade big-bang projekt att det är rimligt att kalla det “malpractice”. Iterativt är ingen silver bullet, de projekten havererar också ibland. Men poängen är att de havererar snabbare, så det blir inte lika dyrt.
Jag säger inte emot dig i att iterativa processer failar snabbare.
Vad jag säger är att det finns situationer där den typen av pilotverksamhet du nämner inte är möjlig. Där att köra dubbla system är dyrt, svårt och utsätter verksamheten för en risk, som ibland inte ens är förenlig med gällande lagstiftning.
Att envist hävda att en modell är det enda som skall gälla och fungerar bäst för allt i alla situationer rimmar illa. Särskilt om man gör det med Lean som argument.
Att köra dubbla system är dyrt, svårt och utsätter verksamheten för en risk. Så långt är jag med.
Att göra en big-bang riskerar att bli ännu dyrare, är definitivt svårare och utsätter verksamheten för en ännu större risk. PUST Siebel är exempel på just detta. Återstår då lagstiftningen.
Kan du ge ett exempel på ett projekt som har hindrats från att köra iterativt på grund av lagstiftning?
Ett hypotetiskt fall där lagkrav kräver stor bang, skulle kanske vara t ex en pace maker – den måste ticka. Inkrementella releaser med bättre funktioner skulle givetvis vara möjligt och kunna ersätta mjukvaran, eller tillåta två versioner så man kan boota om med den äldre versionen om den nyare inte upplevs som bättre.
Men, det är klart det finns fall att hitta på båda ändar av skalan. Om man är ute efter att ha en åsikt att hävda, så är väl det intressanta att fokusera på den stora massan i mitten? Hur ser medianarbetet ut med systemutveckling – är det i allmänhet väl känt vad man behöver göra, kan personer i allmänhet beskriva det på bra sätt med ord, kanske i skrift, är vision och mål tydligt, finns tillräcklig transparens för att kunna styra?
(Lite intressant finner i alla fall jag att Avanade som Löwendahl företräder, nyligen uttalat strategiskt partnerskap med Scrum.org, i syfte att förbättre branschen.
http://www.avanade.com/us/about/avanade-news/press-releases/Pages/avanade-teams-with-scrum-org-to-improve-software-development-page.aspx
)
Vi har varit nära scrum länge och har seniora trainers och dylikt som jobbar tight med organisationerna bakom metodiken.
Vi jobbar oftast iterativt och nära kunde, ibland gör vi som Kniberg föreslår. Ibland går det inte att göra så.
Men genom att ha verksamheten med i processen konstant så går det bra ändå. Det är inte frekvensen av bygg och deploy eller hastigheten ut till produktion som avgör om projektet är lyckat eller inte.
Inom kort hoppas jag att vi kan presentera hur vi med hjälp av iterationer och innovationsarbete hjälpt en bransch att i stort färändra sitt arbetsätt med hjälp av tekniksa framsteg. Som exempel. Det har varit en extremt iterativ process men med risk för konkurrensutsättning har det inte varit några piloter i verksamheten.
Jag påstår inte att lagkrav förbjuder iterativ utveckling i någon form.
Vad jag säger är att det finns lagkrav som både försvårar och till och med hindrar att du kör dubbla system i någon form av pilotinförande.
SOX compliance och en bunte andra påbud från finansinspektionen är sådana. Redovisningslagen är en annan sådan. PCI-Compliance gör det också svårt rätt ofta.
Min poäng är inte att iterativ utveckling är sämre än något annat. Min poäng är att man skall akta sig för att uttala sig med bestämdhet vad som är bäst för alla alltid. Att till och med argumentera för att annat än iterativ utveckling borde vara brottsligt.
Sådan avsaknad av ödmjukhet inför olika situationers förutsättningar gör det helt enkelt inte trovärdigt.
Jag håller med, men det är ändå på plats att slå ihjäl en myt.
Pust/Java, hur bra det än var, gav inte polisen en möjlighet att rapportera anmälningar snabbare. Den möjligheten fanns nämligen redan med de gamla systemen, problemet var snarare mer att polisen inte “jobbade så”. Avsaknad av mobila enheter kan ha varit en orsak till det, men tekniskt sett var det inga hinder.
Det är märkligt hur detta påstående till slut blev en sanning.
Om du med “gamla systemen” menar RAR/DurTvå, så gick det troligtvis snabbare att rent fysiskt knacka in en anmälan i RAR (Systemet för anmälansupptagning och diariet), då det är kommandobaserat, men det är inte det som var poängen med Pust-java utan den följde PNU=Polisens Nationella Utredningskoncept, att slutföra utredningen på plats och skicka direkt till åklagare elektroniskt. Med andra ord optimera flödet, precis som i Lean. Poliserna kunde även göra slagningar direkt ute i fält, utan att behöva sitta i telefonkö till LKC.
Förut fick Poliserna skriva in för hand i anteckningblock och sedan batch-knacka in anmälningarna på Polisstationen, för att de sedan ligger på hög= i balans på väntan på FU-beslut och eventuellt inleda FU. I Pust-Java skedde allt detta direkt, vilket fick ledtiderna att drastiskt minska.
Sedan har det också kommit kritik om att uppkopplingen mot 3G-näten var så usla, speciellt på landsbygden, men jag menar att det fortfarande var en enorm skillnad mot RAR/DurTvå, då Poliserna oftast kunde låna nätverkskoppling då det gällde snatterier (mängdbrott) och kunde slutföra utredningen på plats.
En annan stor skillnad från de “gamla systemen” var att Poliserna fick juridisk handledning av systemet för att minimera risken att utelämna något i anmälan, som senare måste kompletteras. Det fanns inte i RAR/DurTvå eller Pust-Siebel.
Att jämföra de gamla systemen med Pust/Java var inte min poäng. Jag ville bara slå hål på en myt.
Att man gick från 78 till 9 dagar vad gäller genomströmning av en anmälan är fantastiskt men att sådan inneboende tröghet skulle finnas de gamla systemen är ju bara nonsens.
Det fanns ialla fall inga tekniska hinder att polisman själv fick inleda och slutföra FU i de gamla systemen.
Pust/Java blev däremot ett incitament till ett förändrat arbetssätt för poliserna vilken jvar bra och på tiden.
Men allt detta är marginalklotter. Viktigare är frågan hur PUST/Siebel-haveriet kom till.
Tack för klargörandet!
/Henrik
Intressant diskussion. Min uppfattning är att man inte ska fastna och bli “dogmatisk” vad gäller praktiska detaljer som exakt hur man ska blanda in verksamheten i iterationerna. Ett annat exempel (till skillnad från pilotverksamhet) på hur man kan testa det man utvecklar på riktiga användare är att bjuda in riktiga användare till att testa det system man utvecklar i en testmiljö.
Man måste självklart anpassa sig till verkligheten. Jag tror inte det är svart eller vitt (feedback eller bigbang). Men om man inte strävar mot mer och bättre feedback så strävar man åt fel håll anser jag.
Det ena utesluter inte det andra. Vi testade både i testmiljö och poliserna fick använda systemet ute i verksamheten. Det är, i princip, omöjligt att emulera en produktionslik miljö inne i ett testrum med enbart testklienter.
Det känns så snävt och förutsägbart att avsluta med att iterativ utveckling är nyckeln till allt, och att i förbigående nämna att ledningen nog behöver bytas ut. Som om den omhuldade Processen i sig skulle ha något att sätta emot personligheter, internpolitik och antalet kockar i soppan.
(Med Processen menar jag givetvis den process en given person förespråkar, inte någon specifik.)
Är folk villiga och bemedlade att bry sig, utvecklas och förändra spelar det ingen roll vilken process man på pappret bekänner sig till
Varför är det inte en självklarhet att ta med slutanvändaren när man utvecklar ett system? Jag jobbar inom apoteksbranschen. Som ni säkert känner till släpptes monopolet 2009. 2010 kom det första nya receptexpeditionssystemet. Jag har testat tre av de nya systemen. Inget av dem har haft med en farmaceut i utvecklingen! Jag förstår om tidspressen gjorde att man inte hann köra pilot, men man hade tjänat sååå mycket på att låta en farmaceut vara med i utvecklingsfasen!
Jag fick höra “Men alla var ju anställda av Apoteket AB”. Det är väl inget argument? Folk byter väl arbetsgivare hela tiden?
Efter fyra år är systemen fortfarande inte helt intuitiva eller så användarvänliga som man borde kunna kräva att system som används samtidigt som man har en sjuk människa framför sig borde vara.
Om inte användarna är med i projektet spelar det ingen roll om processen är iterativ eller inte, det kommer misslyckas ändå.
Det finns fler sätt att involvera verksamheten än att köra “piloter”.
Kan bara säga att jag känner igen hela problematiken från en annan utvecklingsprocess i försäkringsbranschen med ett gemensamt kundsystem där Siebel skulle användas. Efter enormt mycket utvecklingarbete med enorma kostnader så blev resultatet ändå ganska bra. Men vägen dit!
Stora konsultfirmor lever på att sälja halvdana kilotimmar till stora inkompetenta kunder. Trängselskattesystemet kostade mer än kostnaden för att placera IBM-konsulterna direkt vid vägtullarna med penna och papper. En smula erfarenhet och sunt förnuft hade tillsammans med vilken utvecklingsprocess som helst gett ett bättre resultat än Pust/Siebel.
Dogmatism är alltid farligt. Att använda “vattenfall” som skällsord när alla modeller innehåller små “vattenfall” blir sekteristiskt. De flesta oerfarna utvecklare blir upphetsade över den första modellen de lär sig och tror de sett ljuset, 10 år senare börjar de inse att allt är hopkok av tidigare ideer och erfarenheter, kryddat med någon ny del samt destillerat till en koherent modell. Oftast lite bättre än det som fanns förut, men som har sina nackdelar ety det har alla modeller. Vilket är ok om man medger dem och inte blir religös (t o m Mekanförbundet modifierade “vattenfallsmodellen” med iterationer ganska snart efter att den introducerats eftersom verkligheten inte visade sig gå ihop med Sovjetiska 5-årsplaner). För att säkerställa att allla blir lika irriterade låt mig sluta med en något tillspetsad sammanfattning:
Vattenfall: Sovjetisk 5-årsplan
IIerativ: Fillipinskt hyreshus som till allas förvåning rasar ihop då den 11:e våningen byggs på den från början två våningar höga byggnaden
Rekursiv: Verklighetens iterativa modell
Spiral/Prototyp: “om jag fick skriva om allt idag skulle det bli helt fantastiskt”
Scrum/Agile: “vad bidde det då?”, “det bidde en vante”. Alternativa taggar: Förfinad Rekursiv
I would be very interested in an english version of this article, I think this is a lesson from which not only swedish speaking people could learn,
thanks,
Philipp
English version coming soon. Stay tuned.
Svaret på varför PUST blev en flopp beror inte enbart på byta av tekniskt plattform. En del av det skapades långt tidigare under utvecklingstiden av PUST Java. Jag hade äran att vara med i ett tidigt skede, då PUST Java utvecklades av ett fantastiskt projektteam. Men det som inte fungerade var att beställaren hade en annan tidsplan än projektet. Senare leveransdatum än vad beställaren kommunicerat var vid det skedet inte förhandlings bart och inte heller omfattningen (scopet). Det skulle bara levereras eftersom beställaren hade lovat att ett nytt modernt system till ett visst datum. Lösningen på problemet var enligt beställaren att tillsätta fler resurser eller rättare sagt producera mer timmar i proejktet. Gapet mellan projektets tidsplan och beställarens tidsplan skulle reduceras med fler resurser till projektet. Det går bra till en viss gräns men därefter blir det kvalité brist. Och det är vad jag tror hände, man fick aldrig tid att kvalité säkra produkten/systemet. Man hann nog inte leverera det man hade för avsikt att göra. Och när man valde att konvertera till en ny plattform som har sämre tekniska egenskaper, så kan det bara bli dåligt….. Jag skriver “nog” eftersom jag inte var med så länge utan valde att lämna en, i mina ögon, osund organisation.
Man kan återigen bli fascinerad av Oracles säljkompetens. Där kan vi ha posivtiva lärdomar att dra. Nu måste jag öppna en burk gröt till frukost.
Det är troligt att Pust Java också hade havererat om den finge fortsätta på agila sättet med SCRUM eller Kanban. Att realisera några få användningsfall brukar inte vara något problem oavsett arbetssätt, men att få en koherent och sammanhängande arkiktektur där samtliga användningsfall ska realiseras i ett komplext system går bet utan mycket grundligare förarbete. Detta “tänkande” innan exekvering har tappats bort inom den agila världen. Tänk Lean istället där detta tas till vara.
Att det ofta är svårt att få till samtliga funktioner i en koherent och underhållbar arkitektur till mera komplexa uppgifter var anmärkningsvärt påtagligt i TDD Coding Dojos där ytterligare utökning av funktionsmängden började visa exponentiell tidsåtgång.
Som en notis kan jag nämna att Kanban är en term för felläge där det naturliga flödet eller processen har havererat. Man måst så att säga föra över delar av flödet genom att fylla och tömma behållare efter varandra istället för som tidigare låta det flöda på. Fundera på vad det innebär att Kanban i stort har infört där SCRUM använts tidigare samt att man vidmakthåller felläget.
Jo, iterativ utveckling i fler iterationer än en kommer, av rent matematiska och psykologiska skäl, alltid att slå utveckling som vilar på endast en iteration. RSI även för ett hyfsat välplanerat vattenfallsprojekt ligger runt 30%. Under utvecklingens gång görs alltså insikter som förändrar en knapp tredjedel av den information som lösningen bygger på. Dessa insikter görs i så fältmässiga omständigheter som möjligt. Etc.
Intressant läsning! Sitter och nickar medhållande när jag läser.
Projekt riskerar att haverera, kraftigt försenas eller bli mångfaldigt dyrare (eller alla tre) när:
…tekniska beslut tas av personer som inte förstår implikationerna av vad som är teknikmässigt rätt och och vad som potentiellt leder till stora problem. Eller ännu värre, beslut som har sin grund i prestige.
…systemets andemening uttrycks av personer som helt enkelt till varje pris låter sina egna ord väga tyngre än just slutanvändarnas (eller inte låter dem komma till tals överhuvudtaget).
…tekniska personer låter teknikintresset gå före systemets andemening och dess användare.
…man å det snaraste inte byter kurs när man upptäcker att man är på väg åt fel håll. Vore det inte trevligt om alla projekt vore som duktiga systemutvecklare, fast i makroformat; Oops det blev fel där, gör om, gör rätt. Det tjänar vi in snabbt i förlängningen.
Det är också så att vi systemutvecklare (och övriga projektmedlemmar/delar), måste lära oss att sälja in våra argument när vi ser att det barkar åt skogen. Har i många projekt hört mutter bland projektdeltagare om hur “fel” ditt och datt kan vara. Kvantifiera och gör något åt det, “Don’t ask for permission, ask for forgiveness”. 😉
Jag har också sett personer vägra byta åsikt eller ståndpunkt av ren prestige. Det har helt enkelt gått så långt att man skulle förlora ansiktet om man gjorde en pudel.
PUST är knappast det enda projektet som havererat till stor ekonomisk förlust, men har kanske blivit ett av de mer kända, tack vare TV och övrig media.
Det lilla positiva ur detta är kanske att det låter sig bli en läxa för andra.
Utan att ha tagit del av utredningen kan jag undra hur mycket man skulle kunna kapa förvaltningskostnaderna då standardsystemet uppenbarligen krävde en hel del utveckling och därmed inte längre är ett standardsystem!? Hela iden att myndigheter skall beställa standardsystem, det är ju det som är det verkliga feltänket.
Idéen med standardsystem är bra, det gäller bara att inse i vilka domäner ett visst standardsystem passar i. Siebel är ett CRM-system och det var ganska tydligt redan från början att detta är helt olämpligt för Pust. Hade man gjort en enkel pilot (och satt i produktion) hade man kunnat bevisa detta snabbt. Men nu insisterade ledningen på att köra big bang, så det blev som det blev.
Sen gäller det att inse att standardsystem ofta inte är så standard som man tror – oavsett vad säljaren säger. Extra knasigt i detta fall när en konsult från Oracle skrev själva förstudien som användes som beslutsunderlag av RPS.
Hej!
Intressant läsning. Jag är lite intresserad av varför man valde att bygga ett helt nytt system. Om förvaltningskostnaderna (vilket är den enda anledning jag ser nämns) för Pust Java var så höga att man ansåg sig kunna räkna hem en total omskrivning av hela systemet säger det en del om Pust Java också tänker jag, eller fanns det även andra orsaker till att man beslutade om en omskrivning?
Det var ett övergripande strategiskt beslut att övergå till standardsystem, målet var att minska mängden olika system och förenkla i IT-floran. En vettig målsättning, men det fanns tyvärr en övertro på standardsystem. Beslutet hade inget att göra med Pust specifikt. Pust råkade bara vara första offret för beslutet.