Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed

Mon ikke du mener "Minimum viable product" og ikke "Least viable product"? Jeg kender ikke mange der ville vælge det sidste :-)

Ellers er jeg meget enig i det meste.

Juristerne kunne ikke se hvad vi dog skulle bruge koden til.

Men måske er løsningen, bare at fyre og lukket hele SKAT. Det kan sagtes lade sig gøre, der går jo ikke år imellem at hele styrelser eller ministerierne bliver flyttet, sparet væk, omrokeret eller lagt sammen.

Også starte med TOPPEN, med ny ledelse og struktur, alle medarbejder under et hvis level kan selvfølgeligt, søge arbejde i det nye styrelse. Men ingen som har haft deres hænder i denne sag, heller ikke firmaer eller leverandør må være genganger.

Det er bare så synd hvordan topstyringen fra politiker, med en ledelse som har slikket dem i r.... (men for gode penge) har ødelagt SKAT. De var på forkant med EDB løsninger man skiftet til frivilligt, fordi det var nemmere, og hurtigere. Men succes steg nok ledelsen til over hovedet, og da de lavest hængene frugter var plukket, så fældet man træet for at komme til resten.

Udfordringen ved statslig IT er vel oftest at scope (og nogen gange også go-live dato) er fastlagt ved lov. Så er det svært at lave agil udvikling hvor der fx justeres på scope for at kunne nå en given go-live dato.

Ahhh, men staten vil have at alle 3 parameter er kendte, derfor vandfaldsmodellen, at det tit ikke holder, betyder mindre, det viser bare at projektet ikke har været styret godt nok (i teorien, altså)

Hvis man har brug for en acceptance-test, så vil man automatisk køre vandfald. Der vil være sat en deadline for hvornår udviklerne leverer et skrabet system til accept-test (og data-import-test). Man kan kalde det små vandfald, men man slipper ikke for en godkendt aflevering.

Hvad udviklerne så vælger at gøre for at nå denne deadline kan de selv bestemme, om det er pisk, gulerod eller SCRUM.

Det er jo kun ved inhouse systemer at man måske kan regne med at udviklerne kan finde ud af at gennemføre continous integration, og vedligeholde regression tests. Ved udbud kan man kun stole på sin egen accept-test, specielt fordi man vælger det billigste tilbud.

For mig tager implementering af fejl-håndtering, unit-test, integration-test normalt tager længere tid end den egentlig forretnings logik. Hvorefter værdien af udbud pludselig udvandes hvis det er nyudvikling af et komplekst system.

Generelt er det et stort problem, at Staten alt for ofte bruger (store og dyre) konsulentfirmaer og leverandører, der har en interesse i at gøre projekterne så dyre som mulige i (blind?) tro på at de vil hjælpe dem sikkert i mål!

Min erfaring i forbindelse med tilbudsarbejde er nu ellers det modsatte. Som leverandør er der et konstant fokus på at få kompleksitet og pris ned, så man har en chance for at vinde opgaven. Det er rigtigt at kundens rådgivere nogle gange går skævt af opgaven og stiller krav til en løsning, som er for høje i forhold til behovet. Den slags kan godt være svært at adressere ved offentlige udbud, da kravene som regel er mindstekrav. Jeg har været ude for at vi via spørgsmål/svar har fået en kunde til at tilpasse kravene (dette gælder så naturligvis for alle som byder), men det er sjældent.

Derfor sælges de de dyre Enterprise pakkeløsninger uanset om det reelt er det kunden har brug for.

@Rolf Præcis! Problematikken omkring prototyper angriber jeg som et punkt i næste artikel der giver bud på bedre løsningsmodeller ;)

I øvrigt er det offentlige igang med en omstilling over til Agile Development og mere agile projektmodeller generelt. Denne artikel beskrev forholdene i ca. 2008.

Generelt er det et stort problem, at Staten alt for ofte bruger (store og dyre) konsulentfirmaer og leverandører, der har en interesse i at gøre projekterne så dyre som mulige i (blind?) tro på at de vil hjælpe dem sikkert i mål!

Samme strukturelle problem har jeg set i bl.a Council of Europe, som teknisk projektleder "indefra". Der er en kraftig tendens til "kammerateri" i forholdet mellem kunde og leverandør og deraf "vennetjenester". Det er helt almindeligt at man spiser frokost sammen, eller andre sociale arrangementer...

Jeg har desuden selv arbejdet for (dyre) konsulentbureauer som pre-sales/teknisk konsulent. I den rolle er der selvklart en personlig (bonus) interesse i at sælge mest muligt til kunden. Derfor sælges de de dyre Enterprise pakkeløsninger uanset om det reelt er det kunden har brug for. Kunderne (herunder offentlige organisationer) forstår sjældent hvad de har brug for og køber derfor oftest hele "katten i sækken" for at være på den sikre side.

Det er ganske irriterende at man bare ved at næsten alt erfaring er væk. Det sker at prototyper ender i havet, selvom nogen kan være dyrt købte. Desværre med udbud, så er værdien af prototypen også forsvundet, da det næste udbud igen starter forfra med nye eksterne konsulenter.

@Henrik Der er flere måder at benytte Open Source. Det kan give stærkt øget transparens, hvor hele IT danmark løbende kan følge med, f.eks hvis det offentlige vælger at offentligøre de enkelte moduler/systemer der udvikles i offentlig tilgængelige repositories. En anden model er bare at benytte visse Open Source løsninger i en ellers lukket udviklingsmodel. Det sparer kun lidt penge til licenser og evt. udviklingsomkostninger.

PS: Senest har Bulgarien meldt ud at de vil kræve at offentlig IT bliver open source:

http://www.techweekeurope.co.uk/projects/public-sector/bulgaria-open-source-public-sector-194723

@Henrik Helt enig. Vi bør klart se på hvordan de gør i Estland og England og lære af deres erfaringer.

@Henrik Jeg har svært ved at se at flere Jurister skulle hjælpe. Vi var også i tæt kontakt med SKATs Jurister under hele EFI forløbet. Det gik helt galt på et tidspunkt, hvor Juristerne (uden at rådføre sig med IT afdelingen), skrev under på, at vi ikke fik koden som en del af løsningen. Juristerne kunne ikke se hvad vi dog skulle bruge koden til. Denne beslutning betød endnu en gang et "black box" system med vendor lock-in.

England og Estland, som har gjort noget væsentligt anderledes end os mht. offentlig it

Vi bliver nød til at een gang for alle at få konstateret at big-bang vandfaldsprojekter ikke nytter på de store komplekse statslige it-projekter.

Det har være kendt / dokumenteret minimum siden Bonnerup rapporten som må antages at have været kendt i minimum 10 år.

At blive ved at fastholde den eksisterende måde at udføre projekterne på, kan alene begrundes i dyb inkompetence / manglende lytten til branche / eksperter eller imod bedrevidende. Jeg har aldrig hørt en leverandør eller en leder i en statslig it-indkøber udtrykke andet end at anlægsparadigmet er dybt godnat.

Da der er en lov, der foreskriver at it-projekterne skal ske som et anlægsprojekt. Step 1A, være at de ansvarlige til at forstå problemstilling / acceptere at få lavet den lov om!

Herefter kan man så, f.eks. ved at lytte til gode erfaringer fra udlandet, få tilpasset vores lovgivning til den virkelighed som er forbundet med it-projekter.

Det kunne være udulige konsulenter der bare har haft snablen nede i statskassen. Lad os kalde det byggesjusk eller ikke håndværksmæssigt korrekt udført.
Det nemmeste er at skylde skylden på politikkere - og helst dem fra en tidligere regering. Jeg mener at skylden i høj grad skyldes dårligt udført arbejde.

men jeg opfatter dem mere som rettet mod lagene over IT-konsulenterne, de lag (helt op på ministerniveau?), som tilsyneladende ofte vælger at overhøre IT-konsulenternes gode råd og advarsler.

Men det aner vi vel dybest set ikke noget om? Det kunne være udulige konsulenter der bare har haft snablen nede i statskassen. Lad os kalde det byggesjusk eller ikke håndværksmæssigt korrekt udført. Det nemmeste er at skylde skylden på politikkere - og helst dem fra en tidligere regering. Jeg mener at skylden i høj grad skyldes dårligt udført arbejde.

Infrastrukturen bliver typisk bygget på dyrt indkøbt Enterprise software, fra Oracle, BEA, IBM og Microsoft, hvilket uundgåeligt giver vendor lock-in. Der findes altid Open Source alternativer der er langt mere fleksible og overskuelige. Ofte er der kun behov for en brøkdel af funktionaliteten i et dyrt indkøb Enterprise system.

Jeg kan ikke rigtig se, at det har nogen relevans om softwarestakken er proprietær eller Open Source. Der er lavet - og bliver fortsat lavet - fantastiske løsninger på software under begge forretningsmodeller.

Der er vel ikke mange, der vil påstå, at Open Source er en særlig slags woodoo software, som får alle projekter til at lykkes eller at brug af Microsofts eller IBMs software er lig med at dødsdømme et projekt fra fødslen...??

På samme måde er der næppe tale om et større eller mindre vendor lock-in ... er løsningen baseret på PostgresSQL (Open Source) med en stribe add-ins fra forskellige udviklere, så sidder man lige så meget i saksen, som hvis man havde valgt Oracle eller noget andet købe-software.

Der findes dygtige folk i alle lejrene, som hver især kan få deres foretrukne platform til at yde max. og som er i stand til at løse de mest komplekse tekniske udfordringer.

Jeg tænker, at svaret derfor næppe findes i valget mellem den ene eller den anden platform eller i brugen af Open Source eller ej.

Jeg noterer til gengæld, at anvenderne (brugerne), forretningen og rammebetingelserne (fx kompleks lovgivning) kun i begrænset omfang bringes ind i debatten.

Kigger man mod England og Estland, som har gjort noget væsentligt anderledes end os mht. offentlig it, så er det netop disse forhold de har haft fokus på og som de tilsyneladende har succes med at sætte i centrum.

UK har lavet en offentlig projektmodel med brugeraccept som det centrale omdrejningspunkt i de forskellige projektfaser og betinget, at anvenderne siger god for resultatet af en fase, før man kan fortsætte (og få penge) til den næste fase.

I begge lande (med Estland som nok er længst fremme) har man taget skridt til at tilpasse, forenkle og modernisere lovgivningen, hvilket bl.a. har medført stærkt reduceret snyd med bl.a. moms.

Herhjemme er der dog også gode initiativer i gang. Justitsministeriets chefjurist har sammen med Digitaliseringsstyrelsen sat fokus på, at der fremover skal jurister med i hele forløbet omkring nye løsninger - fra idé til færdig kørende løsning.

Formålet er, at juristerne skal være med til at sikre at løsningen ikke bare er teknisk fungerende, men at de processer den understøtter også er lovmedholdelige. Netop den manglende lovmedholdelighed var det som væltede EFI i sidste instans.

Jeg er helt overbevist om, at vi kan gøre mange ting bedre og fx Henrik Mikael Kristensens indspark om at starte småt (least viable product tankegangen) er givetvis et skridt i den rigtige retning.

Måske vi kunne forsøge at pege på og debattere de gode løsningsdele?

Hvilke andre tiltag har du oplevet som værende succesfulde i de projekter du har deltaget i, og hvilken værdi skabte de?

/Henrik

Disclaimer: Jeg er ansat som Enterprise Arkitekt hos KMD, men skriver i egenskab af privatperson. Alle kommentarer og holdninger jeg giver udtryk for, er derfor mine egne og er således ikke et udtryk for KMDs holdning til - eller opfattelse af - et givent emne.

Det kan være, at det er mig, der misforstår diverse indlæg, i så fald beklager jeg, men jeg opfatter dem mere som rettet mod lagene over IT-konsulenterne, de lag (helt op på ministerniveau?), som tilsyneladende ofte vælger at overhøre IT-konsulenternes gode råd og advarsler.

Og derudover som en faglig diskussion om, hvad der er bedste måde at gribe denne slags projekter an på. Det er vel helt legalt at have divergerende meninger om, især når der er tale om groft kuldsejlede projekter.

Når man læser alle ovenstående indlæg om hvordan det kunne have været gjort, så er det imponerende at staten gang på gang laver kontrakter med nogen der tilsyneladende intet fatter mht. styring af projekt, tid eller økonomi.

Der må sidde 500 IT-konsulenter derude et sted og føle sig nedgjort. Hvornår tager de til genmæle?

Problemerne er dybt strukturelle og grunder ikke i manglende specifikationer, planlægning eller styring men i for meget bureaukrati, kompleksitet og deraf manglende fleksibilitet, transparens og IT forståelse. Ok lad os tage udgangs punk i at det er nogenlunde rigtigt. Man forstår godt at folk løber skrigende bort fra det offentlige, men man må arbejde, med hvad man har. Og der er absolut muligheder her, som ikke findes i det private.

1. Muligheder for samarbejde på tværs af flere offentlige instanser; hvis vi under en størrer it-projekt, skal bruge eksempelvis; en sikker og simple tilgang til CPR registeret for at checke dit eller dat. Kan det måske være en god ide at snakke med andre afdelinger som måske kan tænkes at skal bruge en ækvivalent løsning på dette problem, kan et samarbejde her måske vær en ide, da det giver mulighed for at lave en fælles indkøb, eller et fælles mini projekt(billiger)
2. Korrekt opdeling af projektet; vi ser af 1) at den rigtige opdeling af projektet er yders vigtig. Og brugen af standardiseret produkter fra leverandør også kan have en indflydelse på snit fladerne i projektet. Brugen af OpenSource løsninger her ligger lige for, og er absolut en god løsning der kan intrigeres i projektet , og kan bruges som API snit flade.
3. Legasy kobling; hvis det er muligt at tilgå et eksisterende system eller dele af dette. Kan det også være en fordel, da det give mulighed for en gradvis udrulning af projektet.
4. Gradvis implementering; hvis man har opdelt projektet, som 1) 2) 3), behøver man ikke en store kontrakt, men en masse små, som give mulighed for at bremse et projekt før det bliver at for dyrt. Og penge er ikke spildt hvis man har samarbejdet med andre, offentlige instanser. OSV...

Jeg vil nu stille mig tvivlende overfor at du altid kan få de ønskede features til en fast pris, blot man lader release date flyde.

Duke Nukem Forever ?

K ;-)

Det er 1 for lidt, så nej. Politikerne vil vide hvad de får, hvornår de får det og hvad det skal koste. Og i mange tilfælde er de alle 3 bestemt af en lov.

Jeg vil nu stille mig tvivlende overfor at du altid kan få de ønskede features til en fast pris, blot man lader release date flyde.

Det kunne man dengang der var inflation.

Fokus er tit - forståeligt - på de mislykkede projekter - skandalerne. Det er nærliggende at ønske disse dissekerede, og det synes jeg da også er en god ide.

Men måske skal man oprette en "evalueringsinstitution", som analyserer både de kuldsejlede projekter og de succesfulde, som ifølge tidligere kommentarer i andre tråde også findes i det offentlige?

På hvilke måde ligner de succesfulde og de mislykkede projekter hinanden? På hvilke områder adskiller de sig? Er der særlige træk ved de succesfulde projekter, som kunne overføres til de mislykkede, så disse kunne være blevet vellykkede? Er det størrelsen, der adskiller dem? Måden, projektet er organiseret på? Styresystemet? Ressourcerne/økonomien? Politisk indblanding? Ledelsesstil? Projektkultur (agil eller kravspecifik eller kollison mellem disse)?

Kan vi ikke lære en masse af de vellykkede projekter, som kan genbruges i andre store projekter, og som det derfor også er vigtigt at få indkredset, i stedet for kun at analysere de mislykkede projekter?

Man må starte med et meget beskedent sæt features, som f.eks. det 3 mand kan udvikle på en måned, hvor der er relativt stor sikkerhed for, at man får de one-liners, man skal have.

Desuden må man så fortælle politikerne, at nu er vi blevet godt våde af at stå i den her vandfaldsmodel. Artiklen kunne være skrevet for 15 år siden uden ret mange ændringer.

Der har været statistisk evidens for at vandfaldsmodellen ikke virker for software i en hel del år efterhånden.

At blive ved med at gøre det samme og forvente at resultatet af sig selv bliver bedre, er i bedste fald fra stædighed. Til gengæld kan man ikke bruge det, at en metode fejler, til at mene, at en anden vil være bedre (uden at pege på, hvor den vil gøre en forskel).

Og præcis her er jeg bange for, at der ikke er tale om, at opgaven bliver løst på den forkerte måde, men at der er tale om den forkerte opgave til at starte med. Selv den bedste metode i universet må give fortabt overfor den forkerte opgave.

Jeg vil nu stille mig tvivlende overfor at du altid kan få de ønskede features til en fast pris, blot man lader release date flyde.

I bund og grund er jeg sådan set lige glad med hvilke modeller og mønstre der benyttes - hvad jeg ser som problemet her er ikke vandfaldsmodellen. Ja ja - jeg ved godt - vi udviklere har vores religioner og ting vi kan lide og ikke lide.... Men det reelle problem her er et system der forsætter på trods af advarsler igen og igen i det offentlige; projekt efter projekt. (Og ja, der er sikkert mange private virksomheder der fejler, men der er det ikke skattekroner, der er virksomheden kun ansvarlig overfor deres interessenter)

Hvis ikke der lyttes og reageres på input fra dem der ved noget og sidder med fingrene i maskinrummet; så kunne hvilken som helst udviklingsmodel - også de agile - blive benyttet mens resultatet sandsynligvis ville være det samme.

Og at det så sættes i drift på trods af tilsyneladende massive advarsler, understreger blot at på toppen ledes der med skyklapper på.

Politikerne vil vide hvad de får, hvornår de får det og hvad det skal koste.

Problemet er jo blot, at det ofte ender med een ting = SKANDALE. (i stedet for et Kinderæg)

Det er 1 for lidt, så nej. Politikerne vil vide hvad de får, hvornår de får det og hvad det skal koste. Og i mange tilfælde er de alle 3 bestemt af en lov.

I agile kan du låse dig fast på to ud af tre punkter:

Release date Pris Features

Så det kan sagtens lade sig gøre at styre økonomien.

Hvordan styre du økonomien i et projekt hvor du ikke ved hvor du økonomiske ender. Dette er ikke et spørgsmål, men mit bedste svar på dit spørgsmål.

Hvornår kommer folk i fængsel for at skade Danmark?

Der har været statistisk evidens for at vandfaldsmodellen ikke virker for software i en hel del år efterhånden.

Hvorfor kan statsansatte så trumfe igennem at det skal foregå på den måde, uden at det har konsekvenser

Er det mon fordi det ikke endnu er 110% klart, at komplekse it-projekter ikke kan håndteres som anlægsprojekter eller er der nogen der insisterer mod bedre vidende?

Hos Digitaliseringsstyrelsen fremgår det af at det er et lovkrav at Den fællesstatslige it-projektmodel benyttes til at gennemfører it-projekter (se: http://www.digst.dk/Styring/Projektmodel/Lovkrav-til-it-projekter). Denne medfører så bla. brug af standard kontrakterne (K01, K02, K03)

Hvorfor er det et lovkrav og hvorfor bliver det ikke lavet om?