Et vandfalds-sammenbrud til 149 mio?

Så er den gal igen. Sent i fredags fortalte SKAT at de hævede to store kontrakter med IBM. Tilsammen havde IBM åbenbart budt 149 mio. kr. på de to opgaver.

SKAT angiver at årsagen er:
Citat:

Vi har gennem de seneste måneder haft intense drøftelser med IBM om udviklingen af de to systemer. Vi tror ikke længere på, at det kan lade sig gøre for IBM at løfte opgaven på hverken en tidsmæssig eller økonomisk holdbar måde. Derfor har vi nu hævet aftalen, siger told- og skattedirektør Ole Kjær.

Skatteministeren himself siger i samme pressemeddelelse at
Citat:

Jeg har fulgt sagen kvartal for kvartal i redegørelserne til Finansudvalget og er enig i SKATs vurdering af, at IBM ikke ville kunne komme i mål her. Derfor har vi besluttet at hæve aftalen med IBM omkring Digitalt Motor Register og Én Skattekonto

IBM er blevet forsinket fra en oprindelig leverance i slutningen af 2008, senere skulle projekterne være klar ved slutningen af 2009 og nu mener IBM at de først kan levere i 2011. Design-fasen, som efter den oprindelige tidsplan skulle være færdig allerede fire måneder efter kontraktsindgåelse (dvs. i marts 2007) er endnu ikke færdig, som Jesper Kildebogaard skrev på version2 i fredags.

Projekterne er dog blevet naturlig forsinket da deres forudsætning, infrastruktur-platformen fra CSC, også blev forsinket. Hvor mange måneder CSC blev forsinket melder historien ikke noget om, men SKAT ville i hvert fald have 23 mio kr. fra CSC som følge af forsinkelsen (hvilket var den maksimale erstatning, kontrakten tillod).

Hvordan IBMs udlægning ser ud, ved vi ikke endnu.

Men hvorfor er det gået så galt? IBM er jo ikke dummere end andre folks børn og deres kompetencer må antages at være på plads når det gælder. SKAT er en af de mest professionelle indkøbere af it i landet, hvis ikke dén mest professionelle.

Emnet er ikke nyt og rækken af problemfyldte it-projekter er en ren leporello-liste. (Leporello er Don Juans tjener i Mozarts opera af samme navn ? og Leporellos liste er noget mere opløftende for den heteroseksuelle mandlige it-professionelle, nemlig den næsten uendelige liste over Don Juans erobringer.)

Mit personlige bud er at problemet måske ikke så meget er aktørerne, men mere udviklingsmetoden. Kontrakter som disse bygges nemlig typisk op over en vandfaldsmodel. Fordelen ved vandfaldsmetoden er den klare ansvars-deling mellem kunde og leverandør og dermed er den (relativt) nem at håndtere fra et juridisk synspunkt. Men fra et it-fagligt synspunkt er den jo fyldt med faldgruber.

Så hvis denne sag på 149 mio. skyldes (endnu) et sammenbrud i vandfalds-modellen, hvad er så løsningen' Og hvordan gøres løsningen juridisk spiselig'

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jørgen Elgaard Larsen

Jeg tror ikke, at det her har noget med udviklingsmodeller at gøre. Det handler mere om det offentliges forhold til deres leverandører.

SKATtebassen siger selv, at det er første gang, de hæver en kontrakt. IBM har i forvejen fået lov til at udskyde leveringen, tilsyneladende uden de store konsekvenser.

Min formodning er, leverandører til det offentlige ikke er vant til at skulle stå til regnskab for deres sløseri. Uanset om det handler om IT-projekter, tog, broer eller andet, er det næsten forventeligt, at store, offentlige projekter bliver forsinkede og fordyrede. Det skyldes som regel dårlig ledelse fra det offentliges side.

Problemet er tre-leddet: Først og fremmest er mange offentlige institutioner ikke opmærksomme på, at kontrakter bør indeholde bestemmelser om, hvad der sker, når kontrakten ikke overholdes (f.x. mht. leveringsfrister).
For det andet er ledelsen ofte for forsigtige til at håndhæve evt. kontraktforpligtelser.
Og endelig har man i det offentlige en irriterende vane med at betale forud, for at holde udgifterne i et bestemt budget-år. Det gør det svært at true leverandøren med at stoppe betalingen.

Den juridisk spiselige løsning er enkel:
1) Gør det pligtigt, at både jurister og fagfolk (f.x. dataloger, ingeniører, alt efter hvad der skal leveres) kigger kontrakten igennem inden den underskrives. Og sørger for at få de nødvendige forbehold og krav med.

2) Lav de relevante love om, så offentlige institutioner får mulighed for at deponere udbetalinger fra år til år. Altså så de budgetmæssigt bliver brugt i ét år, men ikke nødvendigvis udbetales til leverandøren med det samme.

3) Sørg for, at ledere i det offentlige bliver holdt ansvarlige for deres beslutninger. Man kunne starte med at fyre dem på gråt papir i stedet for at belønne dem med et gyldent håndtryk...

Heldigvis har SKAT lidt bedre styr på tingene end den gennemsnitlige offentlige institution. Det lader til, at de både har sørget for at få konsekvenser med i kontrakten, og at de rent faktisk vil håndhæve dem. Se, det kunne DSB lære noget af....

  • 0
  • 0
Lars Hansen

En af anbefalingerne i Bonnerup-rapporten (om offentlige IT-projekter) var at større IT-projekter bør splittes op i flere del-leverancer. Disse del-leverancer kan implementeres trinvist. Den nye standardkontrakt for længerevarende IT-projekter (K02) skulle vist netop åbne op for mere fase-opdelte projektaftaler. K02 er dog vedtaget senere end aftaleindgåelsen mellem Skat og IBM.

Jeg ved ikke hvilke muligheder der er for leverance-opdelte IT-projekter efter den gamle standardkontrakt (dvs. om den i sig selv har været en hindring for mere smidige projektforløb).

  • 0
  • 0
Jan Flodin

Jeg tror ikke det nytter meget at se på juraen i dette tilfælde - og IBMs kommentar dd tyder da også på at min hypotese er rigtig.
Man starter et projekt med en given kravspec - den skal så tilpasses yderligere - og sørme om ikke den pludselig skal ændres. Sandsynligvis fordi der lige skal justeres i den lov, som systemet er tænkt til at administrere.
Hvordan vil man gøre det i en stram kontrakt?
Agil udvikling vil måske være en god model, men beklageligvis er fleksibel udvikling lidt som at købe elastik i metermål - og det passer jo ikke med en stram kontrakt.
Så måske skal det offentlige starte et helt andet sted. Stop lovgivningsarbejdet i 3 år - eller tving lovgiverne til at lave love, som kan administreres af strukturerede systemer.

  • 0
  • 0
Lasse Nielsen

Det lyder alt for genkendeligt når Skat selv siger
»Vi mangler stadig en godkendelse af designet på det ene projekt. IBM er ikke begyndt at kode endnu,«

Ja, det er vandfaldsmodellen. Det kan godt virke, men hvis man har et hold (både kunde og udvikler) der kan gennemføre det, men så kunne de sikkert også genneføre det med den ene hånd bundet på ryggen, og på den halve tid med en anden udviklingsmetodik.

Vandfaldsmodellen virker kun hvis man kan samarbejde om at omgå den. Fx ved at godkende et designdokument selv om ikke alle i'er er prikkede og t'er krydsede - og så finde ud af det hen ad vejen. Eller ved at begynde at kode før design-dokumentet er godkendt. Men det kræver gensidig tillid, og man skal kun vifte med kontrakten/kravspecifikationen/statsadvokaten en gang før det bliver "arbejd efter reglerne" fra begge sider.

Og hvis der er en ting der kan stoppe et vandfalds-projekt, så er det folk der ikke tør godkende noget før det er helt forgyldt. At true dem med flere sanktioner vil næppe gøre dem modigere.

/L

  • 0
  • 0
Peter Mechlenborg

Antaget at vandfaldsmodellen virker, og at CSC's platform var færdig designet, hvordan kan designfasen af SKAT's systemer så blive forsinket af at et andet system mangler implementerings delen? Er det netop ikke en af grundpillerne i vandfaldsmodellen, at man kan adskille design fra implementering?

Måske CSC's platform slet ikke var færdig designet, så hele SKAT's projekt afhang af en endnu ikke færdig designet platform... Det må da lyse klart op på risikoanalysen, som noget man skal have fokus på ved projekt start. (Hvorfor overhovedet bruge en ny platform?).

  • 0
  • 0
Peter Mechlenborg

Jeg har aldrig arbejdet på et stort offentligt projekt, og har meget svært ved at forstå kompleksiteten af disse systemer. Hvis der er nogle af jer som har flere detaljer på kravene til SKAT's systemer, eller lignende projekter, må I meget gerne skrive.

Jeg har på fornemmelsen at fx Ruby On Rails aldrig ville kunne komme på tale til en sådan opgave, men hvorfor egentligt ikke? Er der nogle af de tekniske krav som forhindre dette?

Hvor ligger den komplekse del af koden? Er de fleste nye offentlige systemer ikke primært database opgaver, med et relativ tyndt webinterface, hvor kompleksiteten ligger i at holde databasen konsistent og hurtig. Hvis ja, hvorfor så en helt ny infrastrukturplatform i SKAT's tilfælde?

Det er en skam at fejlslagne projekter er så tabu belagte. Vi kunne spare rigtig mange penge hvis vi var bedre til at lære af vores fejl. Hvad skulle fx. forhindre mig i lave de samme fejl som IBM (eller SKAT...) har gjort, hvis jeg engang kommer på et offentligt projekt, med mindre de kan fortælle mig hvad de har lært på godt og ondt. Specielt fra det offentliges side må dette være interessant, men man får indtryk af at det ikke finder sted...

  • 0
  • 0
Lars Hansen

Det er en skam at fejlslagne projekter er så tabu belagte. Vi kunne spare rigtig mange penge hvis vi var bedre til at lære af vores fejl. Hvad skulle fx. forhindre mig i lave de samme fejl som IBM (eller SKAT...) har gjort, hvis jeg engang kommer på et offentligt projekt, med mindre de kan fortælle mig hvad de har lært på godt og ondt. Specielt fra det offentliges side må dette være interessant, men man får indtryk af at det ikke finder sted...

Rapporten "Erfaringer fra statslige IT-projekter - Hvordan gør man det bedre" (også kaldet Bonnerup-rapporten) er faktisk et forsøg på det. Rapporten bør være pligtlæsning for dem der beskæftiger sig med offentlige IT-projekter (eller store IT-projekter i det hele taget). Den er dog temmelig gammel efterhånden (2001) så det er nok ikke alt der længere foregår som beskrevet. Eller... det må man ihvertfald håbe, for det er ret voldsomt kritik der rettes mod de offentlige organiationers evne til at gennemføre store IT-projekter.

Men den er ihvertfald god at lære fra.

Se mere her:
http://www.tekno.dk/subpage.php3?article=357

  • 0
  • 0
Peter Nørregaard Blogger

Det er en meget interessant vinkel, Peter Mechlenborg kommer med: Hvor sker der en systematisk opsamling af erfaringer fra såvel succesfulde som kuldsejlede it-projekter? Måske burde der være et stående "Bonnerup-udvalg". Min hustru forsker og i den verden publiceres alt for ofte kun succes-historierne med den konsekvens at der rundt omkring sidder forskergrupper, der gang på gang laver de samme fejl som andre allerede har været igennem.

Mht. flere detaljer, så er det ikke uset at de større udbud oplister 400+ kunde-krav som skal opfyldes af en leverance 12-18 måneder senere. Hvert kunde-krav nedbrydes i et antal løsningskrav så den totale kravliste ender på et sted mellem 1.000 og 5.000 krav. Kompleksiteten af den slags projekter er eksponentielt større end et projekt, hvor én mand kan overskue sammenhængen i alle krav.

Den lange tidshorisont i store projekter giver nærmest pr. automatik ændringer i kundens situation og behov undervejs. Samtidigt er der ofte kommet nye versioner af stort set alt programmel som løsningen benytter. Og leverandøren bliver også selv hele tiden klogere på opgaven.

Tilsammen giver det en betydelig usikkerhed hos begge parter som bedst håndteres i en atmosfære af gensidig forståelse og tillid. Når alt kommer til alt er det måske her den største udfordring ligger.

  • 0
  • 0
Jakob Veje Hansen

Inden vi kaster os over en slagtning af vandfaldsmodellen, vil jeg mene det er på sin plads at beskue situationen fra fugleperspektivet. Jeg ved forsvindende lidt om den konkrete sag, men sikkert er det vist, at IBM er blevet fyret på grund af bristede forventninger. Det er derfor sagen overhovedet er en historie.

Lad mig uddybe: Som jeg har forstået det, var der en aftale mellem Skat og IBM om at leverancen skulle falde ultimo 2008 og prisen skulle være 149 mio kr? Jeg vil gætte på at aftalen er endog meget fast i kødet hvad angår både leverancedato og pris, hvilket førte til forventninger hos Skat om, at både pris og deadline også ville holde i praksis. På bagkant har vi nu set, at deadline overhovedet ikke holdt. Jeg ved faktisk ikke om prisen gjorde?

Hvis man på aftaleindgåelsestidspunktet havde identificeret at deadlinen var behæftet med stor usikkerhed, og kunne være alt fra 1,5 til 4 år, så havde der slet ikke været en historie her. Deadlinen var skredet, og det havde været helt ok med både IBM og Skat – for den usikkerhed var identificeret på forkant (og håndteret).

Nu ved vi ikke hvorfor denne usikkerhed ikke var identificeret og aftalt på forkant. Det kan skyldes at ingen havde evnet at identificere den (hvilket jeg ikke tror på), eller at den var identificeret af enten den ene eller den anden part, men fortiet og/eller negligeret.

Men lad os nu sige den VAR identificeret og bragt for projektets ledelse på begge sider af bordet. Hvor attraktiv havde big-bang leverance metoden så været for kunden? Jeg er overbevist om at jeg som kunde ville have ønsket en mere drypvis leverance, så jeg løbende kunne verificere, at der kom virkelige resultater ud af min investering. Men det kan være at holdningen hos Skat har været en anden? Vandfaldsmodellen kan give et falsk indtryk af sikkerhed. Eller rettere sagt: et falsk indtryk af kundens sikkerhed. Leverandøren skal nok komme igennem med skindet på næsen, men vandfaldsmodellen gør ikke meget for at sikre kunden i de tidlige faser.
Generelt tror jeg alternativerne til vandfaldsmodellen (mere generelt: big-bang) ville se meget mere attraktive ud, hvis tilbud på projekter kørt efter blev akkompagneret af realistiske usikkerhedsvurderinger. Med en økonomisk usikkerhed på f.eks. 50% af projektets værdi på 150 mio og en usikkerhed på f.eks. 2 år, kan man jo spørge sig selv, om man ønsker at få leveret papirtigre for 30 mio, inden den usikkerhed er mitigeret ned til et tåleligt niveau.

  • 0
  • 0
Peter Nørregaard Blogger

@Jakob, du har en god pointe i at valdfalds-drevet udvikling ville se mindre attraktivt ud hvis der til et hvert større projekt bliv knyttet en usikkerheds-faktor – for den endelige pris bliver helt sikkert påvirket af usikkerheden. Om ikke andet bliver kundens interne businesscase kraftigt påvirket da en forsinkelse betyder senere afskaffelse af dyre manuelle arbejdsgange.

Problemet med den drypvise tilgang er dog at mange projekter indeholder en motor af en slags som udgør en rimelig stor bid af kompleksiteten. En motor leveret "drypvis" (fx et par stempler + en knastaksel) giver ingen værdi som delleverance.

  • 0
  • 0
Peter Mechlenborg

Peter N: "En motor leveret "drypvis" (fx et par stempler + en knastaksel) giver ingen værdi som delleverance".

Jeg læser drypvise leverancer som fx. hver måned. Hvis det er det du tænker på, er jeg uenig. Kan du give et konkret eksempel som ikke kan deles op i bidder af ca en måneds arbejde, så alle bidder giver kunden værdi (jeg kan ikke komme på nogle eksempler).

I mine øjne er den eneste måde en kunde kan få en rimelig indsigt i et systems status, kørende kode. Denne blog omhandler et projekt hvor designfasen har taget 5 gange længere end først beregnet. SKAT opsiger kontrakten fordi de simpelt hen ikke aner hvornår systemet bliver færdig. Hvis jeg var projektansvarlig for en køber af et stort IT-system, og ikke kunne dele projektet ind i bidder af ca. en måneds varighed, så tror jeg ikke jeg ville tage jobbet. Kørende kode er det som giver gennemsigtighed i projektet, og hvis der opstår problemer, så bliver dette synligt allerede ved førstkommende dellevering. Som nævnt tror jeg at alle projekter kan køres på denne måde.

  • 0
  • 0
Lars Bjerregaard

SKAT er en af de mest professionelle indkøbere af it i landet, hvis ikke dén mest professionelle.

Det ville jeg også give dig ret i, indtil for et år siden. Der gik SKAT i drift med et system, eIndkomst, som er et tvunget indberetningssystem for virksomheder. Det er et ganske ufærdigt og tåbeligt system, vist leveret af CSC, som får mig til at tro at "noget har ændret sig i SKAT".

  • 0
  • 0
Marc de Oliveira

Faldt lige over denne debat. Undskyld den sene reaktion...

Min erfaring er at det ikke er "moteren", der ikke kan leveres drypvis (feks månedsvis), men i stedet data. Hvis der er tale om en væsentlig omstrukturering af data, så vil det sjældent være muligt at sætte systemet i drift i mange faser, da SKAT skal kunne drive deres forretning frem til det nye system er klart. Hvis data skal konverteres i forbindelse med overgangen til det nye system, så vil man ofte være nødt til at konvertere alt-eller-intet, hvilket igen betyder, at så snart al data er konverteret, så vil ingen af de gamle systemer længere kunne køre på de nye data, man er derfor nødt til at have hele det nye system klar på een gang.

I visse tilfælde kan man dele data op i nogle får uafhængige dele, der kan konverteres uafhængigt af hinanden, men det hører til sjældenhederne - eller også drejer det sig om små uinteressant dele af systemet, der ikke har berøring med hovedsystemet.

Hvis man leverer eet helt nyt system, er situationen selvfølgelig en anden. Så kan man dele projektet op i så små bidder, som man vil, men i denne sag vil jeg tro at SKAT har rigtig mange data, som de ikke havde tænkt sig at miste.

En anden grund til at SKAT også kan have reageret så kraftigt er at de gerne vil skifte til det nye system i forbindelse med et nyt skatteår. Dvs, hvis de ikke får leverencen inden 2009, så kan de ikke bruge en leverence til noget igen før 2010.

  • Marc de Oliveira
    Simplify Systems
  • 0
  • 0
Log ind eller Opret konto for at kommentere