Dette indlæg er alene udtryk for skribentens egen holdning.

Er fejlslagne IT-projekter et politisk valg?

Af Georg Strøm5. februar 2012 kl. 15:4416
Artiklen er ældre end 30 dage

Der er ikke nogen som bevidst vælger at et system til 400 millioner – som Polsag der netop er blevet droppet – skal slå fejl. Til gengæld må der være en årsag til at det ene IT-projekt efter det andet bliver lavet på måder som næsten garanterer at de slår fejl.

Årsagen kan være politiske beslutninger som har utilsigtede konsekvenser.

Vi ved at faren for at et stort IT-projekt slår fejl er langt større end for at et lille gør det, så det giver mening at lave systemer i små bidder. Risikoen for at den enkelte bid slår fejl er langt mindre, og selv hvis det sker er skaden isoleret og tabet ikke så stort.

Til gengæld er det politisk sikrere at søge om penge til et stort projekt, end at skulle ud hvert år og søge om penge til næste fase, så både kunden og leverandøren har gode grunde til at satse på et stort samlet projekt.

Artiklen fortsætter efter annoncen

Der er brug for en gnidningsløs integration mellem de forskellige dele, hvis et IT-system skal give en væsentlig gevinst. Hvis systemet skal udvikles i mindre bidder, kræver det at der fra begyndelsen ligger standarder for informationsformater og grænseflader, så det er muligt at udvikle delene uafhængigt af hinanden og bagefter koble dem sammen.

Sådan en udvikling af standarder er kompleks og tager tid. Den giver ikke det samme synlige resultat som udviklingen af ny software, og den har ikke den samme prestige og gennemslagskraft i en organisation. Samtidig kan leverandøren have en forståelig modvilje mod at lave software med klare grænseflader som giver andre adgang til at udvikle dele til det samme system.

Selv om der er lavet en detaljeret kravspecifikation, kniber det ofte med at lave systemer som kan anvendes i praksis. Kravspecifikationerne er nogle gange skrivebordsarbejde, og ikke baseret på pålidelige studier af brugernes behov. I værste fald kan de så ligefrem blokere for et godt design.

Når projektet skal levere et resultat til en bestemt tid og en bestemt pris, har ledelsen en interesse i ikke at bruge tid på at afklare, hvad der faktisk er brug for, og i stedet regne med at brugerne er nødt til at acceptere det færdige system. Det kan endda være helt ubevidst, hvis der ikke undervejs er nogen med gennemslagskraft som kan tale brugernes sag.

Der gælder noget tilsvarende for brugen af prototyper og hurtige afprøvninger af arbejdsprocesser i udviklingen af et nyt system. De kan blive opfattet som forsinkelser, selvom de kan være afgørende for om systemet kan anvendes i praksis.

Endelig er risikoen for at store IT-projekter går galt så stor, at de ansvarlige har en forståelig modvilje mod oplysninger som tyder på risici i løbet af projektet. De gennemfører risikoanalyser eller reviews, men formålet er måske mere at forsikre sig selv og andre om at alt er i orden, end at gøre en aktiv indsats for at afdække problemer som kan betyde at projektet mislykkes.

16 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
16
9. februar 2012 kl. 11:21

Som offentlig myndighed SKAL man sende større opgaver i udbud. Et antal leverandører prækvalificeres og slutkvalificeres, og alle skal afgive tilbud på præcis det, som den pågældende myndighed har beskrevet de vil have. Og selv samme myndighed har en forpligtelse til at vælge det billigste tilbud.

Konsekvensen heraf er, at der IKKE er plads til en dialog mellem den pågældende myndighed og den valgte leverandør om væsentlige ændringer i tilgangen til opgaven, hvilket betyder at enhver ændring skal komme til projektet EFTER aftalen er underskrevet.

Mellem en professionel, kompetent køber og en tilsvarende professionel, kompetent leverandør bør dette ikke være et problem.

Vi kan blot som borgere konstatere, at dette i en række tilfælde ikke har været situationen... Spørgsmålet er om der er politisk vilje til at lære af dette.. eller det som sædvanligt skal udvikle sig til en skyttegravskrig mellem på den ene side landspolitikerne, på den anden side køberne, og på den tredje side leverandøren.

Og skal vi lære af fortiden, så husker jeg ikke tilfælde, hvor leverandøren reelt set har tabt.

15
6. februar 2012 kl. 18:25

Udmærket indlæg, og er enig i at der nok er nogle indbyggede mekanismer der gør at de her ting går galt igen og igen. Det hjælper ikke på det at der er nogle mennesker der stadig tror at vandfaldsmodellen er en god model at følge.

Jeg er dog lidt uenig i præmissen i følgende, ikke at man kan tænke på den måde, men mere at det giver mening at tænke på den måde:

"Der er brug for en gnidningsløs integration mellem de forskellige dele, hvis et IT-system skal give en væsentlig gevinst. Hvis systemet skal udvikles i mindre bidder, kræver det at der fra begyndelsen ligger standarder for informationsformater og grænseflader, så det er muligt at udvikle delene uafhængigt af hinanden og bagefter koble dem sammen."

Man kan godt koble tingene sammen gradvist. Gevinsten ved faktisk at have noget op at køre overstiger langt ulempen ved måske at have spildt lidt tid på at skulle ændre på nogle ting, især hvis man tager i betragtning af hvad det at der er noget der virker kan spare af detaljefikserede forhånds-navlepillerier. :)

14
6. februar 2012 kl. 17:58

Nu er vi jo lidt hårde her, på det her forum. Der findes jo en del materiale allerede om hvordan man kan/bør/skal starte et projekt op etc.:

http://www.digst.dk/Statens-projektmodel/IT-projektmodellen/Download

Det jeg så helt specifikt har efterlyst her er en stillingtagen, som går ud over det du snakker om. Jeg mener helt specifikt, at man skal lave valg på en hel del områder, således at man ikke skal starte forfra hver gang man laver et nyt projekt. Behøver man mere end f.eks. mere end 3/4 database platforme ? På x86 hardware behøver man vel kun en hardware leverandør ?

Hvor mange forskellige udviklings platforme behøver man ? Højst en kodestandard per sprog, burde vel være nok ? etc etc etc..

Det tror jeg ville gøre tingene billigere, nemmere at vedligeholde, og skære kraftigt i projekt tiden.

Tja ja.

// Jesper

13
6. februar 2012 kl. 14:10

Min pointe med SBI, er netop at man ikke burde have dem internt for hvert sted - men at staten som helhed, burde gå foran og udarbejde nogle regler for hvad der skal leves op til og anvise hvordan det kunne gøres - ligesom SBI laver anvisninger. Deres anvisninger, skulle så nok være baseret på datamateriale fra alle de offentlige software udviklingsprojekter der finder sted, og erfaringer og konklusioner herfra, krydret med relevant viden og erfaring.

Sådanne krav der skal leves op til, kunne baseres på de mange gode råd, og indeholde sådan noget som:

  • ICD (og krav til dennes indhold)
  • Kravspecifikation (og krav til hvad den må og IKKE må indeholde - også hvad angår detaljegrad)
  • Krav til opdeling af projekter i dele som kan stå "for sig" og så samarbejde/fungere med andre dele, vha. et godt interface (som er åbent for alle - og sikrer konkurrence, frihed fra monopoler osv.) osv.
12
6. februar 2012 kl. 13:44

@Klavs Klavsen.

Min pointe er sådan set bare, at på netop POLSAG havde man jo en masse eksterne firmaer inde for at reviewe. Og da det nu ikke hjalp, så må det per definition have været de forkerte folk. Man kan så undre sig over, at en af grundstenene i Statens IT-råd så netop er ekstern review, måske endda af de samme firmaer, som har været inde over POLSAG. Det kan man jo så tænke lidt yderligere over, men det er jo en anden snak.

Jeg er meget enig med det du skriver vdr. standarder etc. Det er jo netop det man skal have i en rigtig IT funktion. Og et at de største problemer, som jeg ser det, er netop, at man ikke har disse standarder, metoder og resourcer internt. Måske fordi der er for meget politik i det, eller fordi man har får dårlig rådgivning.

// Jesper

10
6. februar 2012 kl. 12:47

@Klavs Klavsen. Nu havde man jo også en masse eksterne konsulent huse inde over og lave review, man må formode at der også var en masse af den rigtige type af 'arkitekter' med der også. Eller måske ikke? Jeg har selv siddet i sådanne review møder, som ekstern leverandør til det offentlige, med netop et af de firmaer der nævnes i artiklen. Og magen til spild af penge skal man da lede langt efter. De havde så absolut intet forstand på det de skulle reviewe, de mente jo at vi som leverandør gratis skulle lave deres arbejde for dem. Det var Grotæsk++ og det endte med at projektet (både kunde og leverandør), gik til styregruppen og den havde så heldigvis n*sser nok til at stoppe dette. Men det skal da nok have adderet 5% ekstra på mandetimer udgifterne til projektet, og ville have adderet mere, hvis man ikke havde stoppet det.

// Jesper

11
6. februar 2012 kl. 12:55

@Jesper: Jo sikkert - det har jeg ikke nogen mulighed for at vide - og det har jeg heller ikke udtalt mig om - så jeg forstår ikke helt dit spørgsmål?

Det eneste jeg sagde, er at byggebranchen heller ikke er helt så modne - men IMHO klart mere moden - godt hjulpet på vej af at der faktisk findes regler på området (og man kan opsætte regler) for hvad byggeriet skal leve op til.

Måske kunne man opsætte nogle regler på software området (når det gælder det offentlige ihvertfald) - som kunne hjælpe.

F.ex. noget med at grænseflader skal være baseret på godkendte og frit tilgængelige standarder eller lign.

Men det er klart ikke så "nemt" som det er for byggebranchen - men måske kunne noget ligesom Statens Byggeforsknings Institut indenfor software hjælpe - indenfor software udvikling, ville det nok så bare være mere noget med konkludere på projekters forløb og metoder anvendt - og så sætte nogle regler op baseret på den erfaring?

Det er jo det, SBI gør - de kan så simulere vejrlig osv. - man er nødt til at have rigtige projekter i software ekvivalenten :)

8
6. februar 2012 kl. 11:48

@Nikolaj Brinch Jørgensen.

Heh, jo jo men det er da altid noget, at han spurgte. Man kan så kun håbe, at det var fordi han var en gammel rotte, der lige skulle mappe dagens Buzzword til de rigtige værktøjer i hans egen værktøjskasse, ha' banket lidt rust af og så ellers komme derudaf. Men det lyder ikke sådan fra din beskrivelse.

// Jesper

6
6. februar 2012 kl. 10:24

@Nikolaj Brinch Jørgensen Der er ingen tvivl om, at der findes en del tågehorn i IT-arkitekt profesionen. Og jo mere fugleperspektiv, der går i den, jo flere er der. Jeg har da siddet på møder med nogle, hvor man under mødet ikke forstod et ord af, hvad de sagde. Men mange af disse er altså 'mostly harmless' og er mere bare et overhead, der bare skal stilles tilfredse. Jeg synes måske, den stædige 'Jeg tror jeg ved hvad jeg snakker om på alle områder' typen, som så har lidt for meget at skulle have sagt, er værre. De har det med at flytte fokus fra essensen i et projekt til en ligegyldighed, som de nu har set sig varme på.

// Jesper

7
6. februar 2012 kl. 11:16

@Jesper Frimann

Jeg husker nu stadigt rædselsprojektet, hvor den nye chefarkitekt kom her til mig efter hans præsentationsmøde (efter han lige var tiltrådt), og spurgte om ikke jeg kunne sende nogle links til det der SOA og ESB...

Så begyndte mine alarmklokker at ringe ekstra højt.

PS: Hvornår kommer der trim() på titlen på indlæg!

3
5. februar 2012 kl. 22:58

Der efterlyses "en gnidningsløs integration" og standarder for grænseflader for at en nedbrydning i mindre projekter skal lykkes. Helt enig, jeg ville nok bare kalde det enterprise-arkitektur. Men hvem har ansvaret for at der findes en veldefineret enterprise-arkitektur og IT-strategi i de offentlige organisationer?

Rammeværker og standarder er kun en del af løsningen. Der kræves også en forståelse af forretningsprocesserne i den enkelte organisation og deres relation til IT-systemer og services. Det skal være klarlagt, hvis en serie mindre udviklingsforløb skal bidrage til den overordnede strategi - og ikke mindst indeholde en løbende tilpasning til behov, som uvægerligt ændrer sig over tid.

En opdeling af en større modernisering i mindre projekter kræver desuden en velfungerende porteføljestyring, vel at mærke udført tæt på forretningen og uafhængig af de enkelte projekt-leverandører. Er de offentlige kunder klædt på til at levere denne styring?

Alle offentlige organisationer burde i det mindste have offentlige IT-strategier og arkitekturbeskrivelser, så der både formelt og uformelt kunne føres en åben diskussion om projektideer før de ender som kontrakter.

5
6. februar 2012 kl. 09:15

Alle offentlige organisationer burde i det mindste have offentlige IT-strategier og arkitekturbeskrivelser, så der både formelt og uformelt kunne føres en åben diskussion om projektideer før de ender som kontrakter.

Det har en hel del offentlige organisationer også, altså både strategi, arkitektur mv.

Problemerne med den EA som du efterlyser er, at den rent faktisk finder sted. Men den er på det plan som Georg beskriver, helt ude af trit med virkeligheden (elfensbenstårnsarkitekter, hvis vigtigste værktøj er PowerPoint og System Architect). Det store problem med en stor del af IT arkitekterne (Enterprise, Løsning/Software, osv.) er, at de ikke har prøvet at realisere løsninger, og at de ikke kender til den underliggende teknologi og hvad der kan lade sig gøre. Dette kendetegn er unikt for arkitekter i IT, for i byggebranchen ved arkeitekterne nemlig godt noget om materialer og konstruktioner, og havd der kan lade sig gøre, eller srødfører de sig med ingeniøere. Det modenhedsniveau er IT mange steder ikke kommet til endnu.

9
6. februar 2012 kl. 12:11

Dette kendetegn er unikt for arkitekter i IT, for i byggebranchen ved arkeitekterne nemlig godt noget om materialer og konstruktioner, og havd der kan lade sig gøre, eller srødfører de sig med ingeniøere. Det modenhedsniveau er IT mange steder ikke kommet til endnu.

hehe - jeg har hørt en del historier fra håndværkere, hvor arkitekten har glemt at snakke med en fagkyndig.

I byggefaget, er det dog således idag, at det kræves at der kommer en ingeniør (statiker) ind over, efter arkitekten har lavet sit (og det er også det normale) - som så udregner og retter til, så projektet rent faktisk også lever op til relevante krav :)

En sådan ingeniør type (som vel ville være modsvaret af en datalog), savnes måske - eller også er det arkitekten der for lov at beslutte ting, som egentlig hører til på datalogens bord?

2
Indsendt af Thomas Hansen (ikke efterprøvet) den søn, 02/05/2012 - 21:52

God fornuftig argumentation. Men jeg er ikke helt enig.

Jeg vil gerne trække frem, at alle IT-projekter der indkøbes til det offentlige, først og fremmest er politiske valg ! Det betyder ikke, at man skal vælge Runetavler frem for IT, men der er ofte tale om, at man sætter et projekt i søen, og efterfølgende, så holder man ikke øje med om det udvikler sig som forventet. Kuldsejler projektet, så er der ingen der protesterer, før end det går helt galt, og så er man allerede igennem et eller flere regeringsskifter, og dermed placeres der ikke ansvar, og tages ikke ved lære af tidligere fejl. Det er Politikerne, som er de ansvarlige, som landets ledere. At man ikke kan stille dem til ansvar, er så noget helt andet.

I tilfældet med CSC, så er Pol-sagerne, jo bare en lille fraktion af de fejl virksomheden leverer. Der er jo tilsvarende en kæmpe sag, om tilgodehavender som ikke kan indrives i forhold til opgaven over for Skat, som fylder langt mere, end Pol-sagerne.

CSC er kun i vælten pt. men det kunne lige så godt være en anden leverandør, og det er snart jævnligt vi skal høre om IT-projekter der ikke lever op til forventningerne.

Det er politikernes ansvar, at få sat et system sammen, der sikrer at varen som indkøbes, tilsvarende leveres.

Som jeg ser det, så SKAL der præsenteres en prototype i forbindelse med at Staten køber noget som helst. Det er IKKE Statens opgave, at betale for udvikling af software i private virksomheder. Udvikling skal de respektive virksomheder selv være i stand til at financierer, ellers er der jo tale om konkurrenceforvridende støtte. Kun tilpasning til Statens systemer, kan der betales ekstraordinært for.

1
5. februar 2012 kl. 18:35

Du har helt igennem ret. Jeg har længe haft lyst til at formulere samme argumentationskæde som svar på de mange indlæg der postulerer at store offentlige projekter bedst løses ved anvendelse af agile udviklingsmetoder.