mboost-dp1
Til alle dem som ved hvad der er galt med offentige IT projekter
Det er da godt at de vil gøre noget ved det, men IT problemet har vel den samme årsag som de fleste andre problemer i det offentlige, nemlig at der er alt for mange latterlige krav og restriktioner til styringen af offentlige projekter.
F.eks. ser det ud til at det er nemmere bare at købe den dyreste løsning, frem for at ansætte folk der er kompetente nok til at tage en beslutning om hvilken løsning der skal vælges.
F.eks. ser det ud til at det er nemmere bare at købe den dyreste løsning, frem for at ansætte folk der er kompetente nok til at tage en beslutning om hvilken løsning der skal vælges.
#2
Det typiske offentlige IT projekt foregår vel ved at:
- et firma rådgiver det offentlige under udbuddet
- et andet firma leverer projektet efter at have vundet udbuddet
- valg af teknologi er frit for dem som byder på opgaven
Hvor er det helt præcist at du mener at der mangler kompetance?
Det typiske offentlige IT projekt foregår vel ved at:
- et firma rådgiver det offentlige under udbuddet
- et andet firma leverer projektet efter at have vundet udbuddet
- valg af teknologi er frit for dem som byder på opgaven
Hvor er det helt præcist at du mener at der mangler kompetance?
arne_v (3) skrev:Hvor er det helt præcist at du mener at der mangler kompetance?
Jeg synes at det, der oftest går galt i IT projekter, er at der er for mange, med lige meget magt og forskellige meninger, der ikke snakker sammen. Og så er der en generel mangel på respekt for præcise kravspecifikationer og prisfastsættelse.
AKA, den manglende kompetence er hos projektlederne i begge ender.
#4
Så vidt jeg ved har offentlige IT projekter altid en meget veldefineret pris ved projekt start (også ved projekt afslutning for den sags skyld men nogen gange er den bare XXX millioner højere end den ved start).
Jeg kender ikke så meget til krav spec fra danske offentlige institutioner. Er de generelt ringere end tilsvarende fra private virksomheder?
Hm. Jeg ved faktisk at de tilsyneladende sjældent indeholder krav om erstatning ved for sen aflevering.
Så vidt jeg ved har offentlige IT projekter altid en meget veldefineret pris ved projekt start (også ved projekt afslutning for den sags skyld men nogen gange er den bare XXX millioner højere end den ved start).
Jeg kender ikke så meget til krav spec fra danske offentlige institutioner. Er de generelt ringere end tilsvarende fra private virksomheder?
Hm. Jeg ved faktisk at de tilsyneladende sjældent indeholder krav om erstatning ved for sen aflevering.
gnarfsan (4) skrev:Og så er der en generel mangel på respekt for præcise kravspecifikationer og prisfastsættelse.
Nu er det ellers så moderne at droppe kravspecifikationer. Jeg har da været med til (i den private sektor) at gennemføre million-projekter ud fra en beskrivelse på ganske få A4-sider, som kun beskriver formålet og ikke selve løsningen. Detaljerne er noget man når frem til undervejs. Det er helt normalt hos os.
Prismodellen kan så variere. I praksis klør vi på til produktet er godt nok, eller indtil nogen priorierer projektet ned. Alternativt er der fast pris, og så må vi se hvor meget vi kan nå at få med.
Det der med en deadline, fast pris og præcis kravspec, det du'r ikke. Hvis man virkelig overholder det, så er kvaliteten den eneste elastik man har tilbage.
Og uanset hvordan det ser ud, så har jeg svært ved at tro at det offentlige ikke er klar over det.
myplacedk (6) skrev:Det der med en deadline, fast pris og præcis kravspec, det du'r ikke. Hvis man virkelig overholder det, så er kvaliteten den eneste elastik man har tilbage.
Jo. Det derfor at det er vigtigt at man laver forabejdet ordentligt. Samtidigt har man jo også faser, og en vis mængde iterationer.
myplacedk (8) skrev:#7
Jeg ved ikke om du er enig eller uenig. :-P
Men jeg er enig i din tilføjelse.
Hmmm... Den måde du beskriver det på, er den hyppigste måde at køre det på. Jeg har bare set alt for mange tilfælde hvor det går galt, og det er for det meste pga. forventninger, der ikke er af stemt fra dag 1.
#9
Det ville ikke overraske mig. Det problem jeg hyppigst ser, er når et projekt har deadline eller fast pris, og nye features tilføjes (eller eksisterende ændres), så bliver nogle overraskede over at de lavest prioriterede opgaver ryger ud.
I et projekt lavede vi en post-it pr. opgave, og satte dem over hinanden på en væg i prioriteret rækkefølge. Og så lavede vi en fed rød vandret streg. "Det under streget kommer ikke med". Så var det tydeligt, at hvis man skubbede noget ind, ville noget andet ryge ud.
Det ville ikke overraske mig. Det problem jeg hyppigst ser, er når et projekt har deadline eller fast pris, og nye features tilføjes (eller eksisterende ændres), så bliver nogle overraskede over at de lavest prioriterede opgaver ryger ud.
I et projekt lavede vi en post-it pr. opgave, og satte dem over hinanden på en væg i prioriteret rækkefølge. Og så lavede vi en fed rød vandret streg. "Det under streget kommer ikke med". Så var det tydeligt, at hvis man skubbede noget ind, ville noget andet ryge ud.
#11
Det kommer helt af sig selv. Hvis en eller flere opgaver er røget ud, men man ikke kan undvære dem, må man tage en beslutning:
1) Ret prioriteringen (sker tit hos os når en opgave ryger ud)
2) Gør projektet større
3) Lær at leve med det
Det er utroligt hvordan prioriteringsrækkefølgen og Need To Have-markeringer kan ændre sig, efterhånden som opgaver krydser stregen.
Det kommer helt af sig selv. Hvis en eller flere opgaver er røget ud, men man ikke kan undvære dem, må man tage en beslutning:
1) Ret prioriteringen (sker tit hos os når en opgave ryger ud)
2) Gør projektet større
3) Lær at leve med det
Det er utroligt hvordan prioriteringsrækkefølgen og Need To Have-markeringer kan ændre sig, efterhånden som opgaver krydser stregen.
myplacedk (6) skrev:Nu er det ellers så moderne at droppe kravspecifikationer. Jeg har da været med til (i den private sektor) at gennemføre million-projekter ud fra en beskrivelse på ganske få A4-sider, som kun beskriver formålet og ikke selve løsningen. Detaljerne er noget man når frem til undervejs. Det er helt normalt hos os.
Prismodellen kan så variere. I praksis klør vi på til produktet er godt nok, eller indtil nogen priorierer projektet ned. Alternativt er der fast pris, og så må vi se hvor meget vi kan nå at få med
Fint med en intern IT afdeling.
Men ønsker du at det offentlige skal bede CSC/KMD/IBM/Accenture/NNIT/whoever gå igang på time & material basis og se hvor man ender henne?
Det ligner lidt fo rmeget et tag selv bord efter min mening.
myplacedk (6) skrev:Det der med en deadline, fast pris og præcis kravspec, det du'r ikke. Hvis man virkelig overholder det, så er kvaliteten den eneste elastik man har tilbage.
Det er ulempen ved de faste modeller. En detaljeret krav spec kan dog sikre en vis minimums kvalitet.
Men de fleste offentlige IT skandaler drejer sig ikke om on time + on budget + quality sucks.
Det er snarere for sent og overskredne budgetter der karakteriserer dem.
Kvaliteten er så varierende fra jammerlig til OK.
Jeg er ret enig med myplacedk. Tilgengæld kræver det en hvis tillid mellem kunde og producent, at lave den slags åbne udviklingsprojekter. (Så det ikke bliver et tag selv bord for nogle af parterne.)
Et problem med store projekter som der bliver lavet af de tilsvarende firmaer CSC/KMD/IBM/Accenture/NNIT/Atkins/COWI er bl.a. kravspecifikationerne. At udarbejde denne kræver ofte mange hundrede timer. Hvilket vel og mærke er mange hundrede * antallet af deltagere, fra begge parter (som ofte er betydeligt) + transport-tider + spild-tider (en programmør får ofte ikke lavet noget synderligt, den dag hvor han er til møde) + perioder hvor nogle ikke kan komme videre, grundet møder der endnu ikke er afholdte o.s.v.
Resultatet på dette arbejde, er en mange-hundrede-siders-kravspecifikation, som ledere så skal granske igennem, for derefter at delegere det ud til projektledere, som der så skal granske dem igennem, for derefter at delegere dem ud til udviklere som der derefter skal granske dem igennem. = Mange personer * læse- og gransketid for mange hundrede sider.
Derefter følger implementationen, som er lang og smertefuld, eftersom udviklerne hele tiden skal sidde med et øje på kravspecifikationen, som der er minutiøst detaljeret. De får eksempelvis ikke at vide "at de skal indhente data og præsentere det i et givent format". Mere sandsynligt er det, at de får et par A4-ark med beskrivelse om hvilken database og hvordan alle led i processen skal udføres. (Prøv selv at test, hvilken tilgang der er hurtigst at implementere.)
Undervejs i implementationen skal det derudover hele tiden afprøves, at kravspecifikationen stadigvæk er overholdt. Også med kunden til stede. (Endnu flere møder.)
Her kommer katastrofen så. Til disse midtvejsmøder vil *enhver* kunde, komme med indput og kommentare til det nuværende output. (Læs evt.: De skifter mening når de ser hvad de har bestil.)
CRASH BOOM BANG!!!! 6 måneders kravspecifikation og planlægning, lige i vasken!!!
Og jeg mener ikke (som mange andre) at løsningen på dette problem, er at bruge endnu mere tid på kravspecifikation og være endnu dygtigere til at informere kunden om, hvad det er de bestiller. De vil *altid* komme med ændringer undervejs. Og den klassiske udviklingsmodel (SPU, strukturet program-udvikling) er fantastisk dårlig (læs: dyr), til at håndtere ændringer undervejs i et projekt.
Iterativ program-udvikling FTW! Små kravspecifikationer! Små udviklingsforløb! Små tider! Småt alt!
Det er ikke ligefrem rocket science. Vi lærte om det i samme åndedrag, som da vi lærte om SPU. Men langt de fleste store virksomheder, som jeg har erfaring med, kører efter SPU.
Iterative udviklingsmodeller som Agile og Scrum er dog heldigvis ved at vinde frem, så småt. (Men igen er det mest hos små og mellemstore virksomheder at man ser det. Ikke hos den klasse som der laver store offentlige projekter.)
Et problem med store projekter som der bliver lavet af de tilsvarende firmaer CSC/KMD/IBM/Accenture/NNIT/Atkins/COWI er bl.a. kravspecifikationerne. At udarbejde denne kræver ofte mange hundrede timer. Hvilket vel og mærke er mange hundrede * antallet af deltagere, fra begge parter (som ofte er betydeligt) + transport-tider + spild-tider (en programmør får ofte ikke lavet noget synderligt, den dag hvor han er til møde) + perioder hvor nogle ikke kan komme videre, grundet møder der endnu ikke er afholdte o.s.v.
Resultatet på dette arbejde, er en mange-hundrede-siders-kravspecifikation, som ledere så skal granske igennem, for derefter at delegere det ud til projektledere, som der så skal granske dem igennem, for derefter at delegere dem ud til udviklere som der derefter skal granske dem igennem. = Mange personer * læse- og gransketid for mange hundrede sider.
Derefter følger implementationen, som er lang og smertefuld, eftersom udviklerne hele tiden skal sidde med et øje på kravspecifikationen, som der er minutiøst detaljeret. De får eksempelvis ikke at vide "at de skal indhente data og præsentere det i et givent format". Mere sandsynligt er det, at de får et par A4-ark med beskrivelse om hvilken database og hvordan alle led i processen skal udføres. (Prøv selv at test, hvilken tilgang der er hurtigst at implementere.)
Undervejs i implementationen skal det derudover hele tiden afprøves, at kravspecifikationen stadigvæk er overholdt. Også med kunden til stede. (Endnu flere møder.)
Her kommer katastrofen så. Til disse midtvejsmøder vil *enhver* kunde, komme med indput og kommentare til det nuværende output. (Læs evt.: De skifter mening når de ser hvad de har bestil.)
CRASH BOOM BANG!!!! 6 måneders kravspecifikation og planlægning, lige i vasken!!!
Og jeg mener ikke (som mange andre) at løsningen på dette problem, er at bruge endnu mere tid på kravspecifikation og være endnu dygtigere til at informere kunden om, hvad det er de bestiller. De vil *altid* komme med ændringer undervejs. Og den klassiske udviklingsmodel (SPU, strukturet program-udvikling) er fantastisk dårlig (læs: dyr), til at håndtere ændringer undervejs i et projekt.
Iterativ program-udvikling FTW! Små kravspecifikationer! Små udviklingsforløb! Små tider! Småt alt!
Det er ikke ligefrem rocket science. Vi lærte om det i samme åndedrag, som da vi lærte om SPU. Men langt de fleste store virksomheder, som jeg har erfaring med, kører efter SPU.
Iterative udviklingsmodeller som Agile og Scrum er dog heldigvis ved at vinde frem, så småt. (Men igen er det mest hos små og mellemstore virksomheder at man ser det. Ikke hos den klasse som der laver store offentlige projekter.)
illishar (15) skrev:Tilgengæld kræver det en hvis tillid mellem kunde og producent, at lave den slags åbne udviklingsprojekter. (Så det ikke bliver et tag selv bord for nogle af parterne.)
Tillid når man snakker projekter i 3 cifrede million beløb er ikke særligt naturligt.
illishar (15) skrev:Resultatet på dette arbejde, er en mange-hundrede-siders-kravspecifikation,
Med de store offentlige IT projekter vil jeg forvente en krav spec på tusinder af sider.
illishar (15) skrev:De får eksempelvis ikke at vide "at de skal indhente data og præsentere det i et givent format". Mere sandsynligt er det, at de får et par A4-ark med beskrivelse om hvilken database og hvordan alle led i processen skal udføres. (Prøv selv at test, hvilken tilgang der er hurtigst at implementere.)
Selvfølgelig er det hurtigst at implementere noget, hvis man selv kan bestemme hvad man skal implementere.
Men dem der betaler for projektet vil jo nok hellere have det som de har brug for (eller ihvertfald tror at de har bruge for !) fremfor hvad som er nemmest for levandøren.
illishar (15) skrev:Til disse midtvejsmøder vil *enhver* kunde, komme med indput og kommentare til det nuværende output. (Læs evt.: De skifter mening når de ser hvad de har bestil.)
CRASH BOOM BANG!!!! 6 måneders kravspecifikation og planlægning, lige i vasken!!!
Dette er ganske rigtigt helt almindeligt.
Men det behøver ikke at betyde at krav spec og al planlægning er spildt.
Kunden har nogle ændringsforslag, leverandøren estimerer ekstra pris og ekstra tid, kunden siger hvilke ændringer som de vil have med.
Hvis der i forvejen er sat penge og tid af til ændringer, så behøver det ikke engang at overskride budget eller deadline.
illishar (15) skrev:Iterativ program-udvikling FTW! Små kravspecifikationer! Små udviklingsforløb! Små tider! Småt alt!
Småt er godt når det drejer sig om software udvikling.
Mange beslutningstagere vil imidlertid gerne kende den totale pris inden de siger eller nej til projektet.
arne_v (16) skrev:Mange beslutningstagere vil imidlertid gerne kende den totale pris inden de siger eller nej til projektet.
Overvej f.eks. om I har lyst til at sige til en tømrer der skal modernisere jeres køkken eller en mekaniker som skal reparere jeres gamle bil, at de bare skal gå igang og så aftaler man hvad der skal laves til hvilken pris hen af vejen. Eller om I er "vandfalds typer" som gerne vil have et fast tilbud på det hele.
Fast tilbud på Håndværkere? ;-)arne_v (17) skrev:Eller om I er "vandfalds typer" som gerne vil have et fast tilbud på det hele.
Håndværkere laver et overslag. Hvis det bliver nødvendigt med flere mandetimer, bliver prisen højere. Jeg har sjældent set en aftale med en håndværker hvor prisen aldrig bliver højere end den oprindelige kontrakt.
Medmindre man køber en form for samlet løsning, ala. køkken, lidt svarende til hyldevar løsninger (tænk CMS opsætning)
#18
Det sker at man indhenter tilbud og ikke overslag fra håndværkere.
Bemærk iøvrigt at selvom et overslag ikke er et tilbud, så er det tættere på et tilbud end på efter regning. Hvis den endelige regning bliver større end overslaget kan man tage sagen i retten. Mit indtryk er at <10% overskridelse får man ikke noget ud af at protestere imode, men at der over dette laves en vurdering af sagen.
Det sker at man indhenter tilbud og ikke overslag fra håndværkere.
Bemærk iøvrigt at selvom et overslag ikke er et tilbud, så er det tættere på et tilbud end på efter regning. Hvis den endelige regning bliver større end overslaget kan man tage sagen i retten. Mit indtryk er at <10% overskridelse får man ikke noget ud af at protestere imode, men at der over dette laves en vurdering af sagen.
arne_v (16) skrev:Tillid når man snakker projekter i 3 cifrede million beløb er ikke særligt naturligt.
Personligt vil jeg også helst ha' skrevet kvitteringen ud i platin-plader, når jeg køber ting til 3 cifrede million beløb. Men en stor del af beløbet går jo netop til den føromtalte kravspecifikation og planlægning. Og en anden stor del, går til "garantier", som man som offentlig myndighed, mere eller mindre er nødt til at kræve.
Vi kan tage et eksempel. Atkins (mener jeg) har lige vundet et udbud om at lave en "webside til registrering af arealer til landbrugsstøtte". Hvilket vil sige, at det indbefatter noget med nogle webforms, koblet til en database. Hvis vi er crazy så kræver vi også et kort. Ganske simpelt. Selv personer som ZiN og fidomuh vil uden problemer kunne have noget oppe og køre i løbet af 1 måned, som der opfylder det ovenstående. Pris 30k ;)
Men hvis jeg som virksomhed skal garantere, at siden har 99% oppetid, i de næste 5 år, med potentielle spidsbelastninger på 10.000 hits/s. Så vil jeg for det første lave en "scaleable" løsning i stedet, så jeg kan afvikle den på et distribueret netværk (+8 måneder?). Jeg vil også sørge for at købe hardware og opsætninger, der potentielt kan klare store belastninger. (Eg. enterprise Oracle, Mainframes, whatever.) Hvilket der så skal ansættes en mindre hær, til at administrere. (+50M kr.)
Nu kræver kunden så, at jeg også skal hæfte økonomisk, for evt. fejl, som siden måtte lave. Jeg vil derfor kræve at systemet bliver testet i min. 3 måneder proffesionelt, 3 måneder i udpegede user groups og 6 måneder i offentlig beta. (+20M kr.)
Derudover er der også en risiko, fra det omtalte hæfte, der skal indregnes i prisen. Og da det er store beløb vi taler om (landbrugsstøtte) så skal der lægges en god slat til side. (+200M kr.)
Jeg vil derudover også ansætte et par stykker, som der har til opgave at sætte sig ind i det pågældende projekts regler og love (landbrugsstøtte). (+2M kr.)
Derudover har kunden også krav om, at siden skal opfylde krav indenfor brugervenlighed og handikap-venlighed (af alle typer). Der skal derfor ansættes nogle folk, der kan sætte sig ind i disse krav. Og der skal ansættes nogle useability-folk, nogle design-folk og nogle ekstra folk, til at implementere de ekstra ting. (+30M kr.)
Der er nu ansat en hel del flere end det oprindelige og samarbejdet mellem disse skal derfor koordineres og planlægges. (+60M kr.)
Til sidst vil kunden også gerne være sikker på, hvad det er de køber (når de nu skal give så mange penge) og den omtalte kravspecifikation kommer derfor i spil, som der vil påvirke alle medvirkende. (+100M kr.)
... historien om hvordan 30k bliver til 500M.
Og jeg mener ikke nødvendigvis det ovenstående er grotæsk. Især fordi der sandsynligvis ville komme borgerkrigslignende tilstande, hvis en sådan side, rent faktisk lavede en fejl.
Men man kunne måske have som mål, at skære ned på krav og forventninger til projekter, som der måske ikke kræver det? Digital udstedning af kørekort? Arkivdokumentation (i form af billeder) af danske museums-genstande? Lønsystemer? (den gennemsnitlige bruger/offer for et lønsystem og som regel ret god til at finde potentielle fejl) Digitale byggesager? Lokalplaner? etc.
Tror I at den gennemsnitlige borger ville vælge de 500M fremfor 50k, hvis de 50k ville betyde en fejlbehæftet offentlig administration? Måske. Men det kunne man jo passende, minde de folk om, som der piver over store IT-udgifter og overskridelser ;)
#20
Jeg er ikke uenig i at projekter som lyder simple ofte bliver enormt store.
Og det skal nok også ske for det eksempel du nævner.
regel #1: kompleks virkelighed giver kompleks software
Reglerne for landbrugsstøtte er indviklede. Bare det at forstå reglerne så man får de rigtige data indsamlet er formentlig en større opgave.
regel #2: integration mellem systemer giver altid kompleksitet
Det system skal sikkert integreres med:
- et virksomhedsregsiter over landmænd
- et grund register og landbrug
- økonomi systemet som står for udbetalingerne
etc.
regel #3: cost = k * pow(kompleksitet, 2)
Det bliver dyrt.
Og hvad skal man bortspare?
oppetid => så spilder brugerne deres tid (og det koster altså også penge)
korrekte data og beregninger => det koster rigtigt mange penge manuelt at rette op på fejl fra IT systemer
integration med systemer som validerer data => der bliver ballade med både skatteydere og EU hvis systemer er for nemt at snyde
integration med backend for udbetaling => det er dyrt at have et IT system som printer en rapport ud som så behandles manuelt i næste trin
Umiddelbart vil jeg mene at et dyrt system son løser opgaven er bedre end et billigt system som ikke hjælper nogen.
Der bliver sikkert ikke borgerkrig, men man skatteyderne sætter nornalt pris på at de får noget der fungerer for deres penge.
Så FZ Software's tilbud på 50K duer nok ikke.
Jeg er ikke uenig i at projekter som lyder simple ofte bliver enormt store.
Og det skal nok også ske for det eksempel du nævner.
regel #1: kompleks virkelighed giver kompleks software
Reglerne for landbrugsstøtte er indviklede. Bare det at forstå reglerne så man får de rigtige data indsamlet er formentlig en større opgave.
regel #2: integration mellem systemer giver altid kompleksitet
Det system skal sikkert integreres med:
- et virksomhedsregsiter over landmænd
- et grund register og landbrug
- økonomi systemet som står for udbetalingerne
etc.
regel #3: cost = k * pow(kompleksitet, 2)
Det bliver dyrt.
Og hvad skal man bortspare?
oppetid => så spilder brugerne deres tid (og det koster altså også penge)
korrekte data og beregninger => det koster rigtigt mange penge manuelt at rette op på fejl fra IT systemer
integration med systemer som validerer data => der bliver ballade med både skatteydere og EU hvis systemer er for nemt at snyde
integration med backend for udbetaling => det er dyrt at have et IT system som printer en rapport ud som så behandles manuelt i næste trin
Umiddelbart vil jeg mene at et dyrt system son løser opgaven er bedre end et billigt system som ikke hjælper nogen.
Der bliver sikkert ikke borgerkrig, men man skatteyderne sætter nornalt pris på at de får noget der fungerer for deres penge.
Så FZ Software's tilbud på 50K duer nok ikke.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund