De ustyrlige offentlige it-projekter

Der er for tiden megen fokus på tinglysningssystemet, som af mange ses som endnu et eksempel på ustyrlige eller for dårligt planlagte offentlige it-projekter.

Der er røster fremme om, at der generelt skal strammes op i projektledelsen af de offentlige it-projekter. Der skal være mere fokus på risikovurdering og risikostyring.

Under hele denne debat ligger der en uudtalt antagelse om, at it-projekter rent faktisk kan planlægges præcist på forhånd og gennemføres fuldkommen according to plan. Hvis ikke det sker, må nogen have gjort noget forkert.

Debatten kommer derfor hurtigt til at handle om at udpege de skyldige - dem, som "har gjort noget forkert", ikke har været tilstrækkelig grundige osv. osv.

Men at tro, at man kan planlægge sig lydefrit gennem en kompleks verden, er efter min opfattelse lettere naivt. I bedste fald er det udtryk for en rigid systemtænkning, der daterer tilbage til midten af det forrige århundrede: At virkeligheden kan opdeles og håndteres i små systemer og at output kan kontrolleres præcis via bestemte input. Sjovt nok var det netop på dét tidspunkt, at projektledelse kom til verden som en selvstændig disciplin indenfor industrien.

Tiden er løbet fra den måde at opfatte verden på. Vores verden er blevet altfor kompleks, tværgående og integreret til at man kan lave en plan og bare følge den til punkt og prikke for at nå frem til det ønskede, foruddefinerede mål. Bare det, at der indgår mennesker med egne ideer, følelser og behov i alle større projekter, gør at planen aldrig bliver eksekveret sådan som den står på papiret. Man kan derfor heller ikke på forhånd lave en fyldestgørende risikovurdering, der kan overbevise projektets belutningstagere om, at man som projektleder har fuldkommen styr på projektet fra start til slut. Tværtimod ved man med sikkerhed, at der vil opstå en række uforudsete ting i løbet af projektet.

Man er derfor efter min mening nødt til at gøre grundlæggende op med den traditionelle systemtænkningsagtige måde at tænke projektledelse på. Store kravspec's, vandfaldsmodeller, skrivebords-risikovurderinger, milepælsplanlægning - og hvad det alt sammen hedder, er altfor statiske værktøjer i en dynamisk og uforudsigelig verden. Det offentlige skal sadle helt om på dette område. Man skal lægge Prince2 helt væk og orientere sig mod moderne iterative og agile måder at arbejde med projekter på - måder, som i langt højere grad er gearet til at agere i en moderne, uforudsigelig verden. Og ja, det vil kræve en ændret mentalitet hos mange offentlige beslutningstagere og en fundamental ændring i den måde, hvorpå bliver bevilget midler til projekter i det offentlige.

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anonym

Ole

Du kan have meget ret i din kritik af de tunge udviklingsprojekter.

Men samtidig bør du se på forudsætningerne for det alternative forslag. Det store problem med digitaliseringen af samfundet er at processerne ikke idnretter sig efter borgerne (behovet) men tager udgangspunkt i systemet (interessen).

I den fysiske verden kunne borgerne mere eller mindre tvinge processerne og systemerner til at indrette sig, men i den skale og indgriben i specielt infrastrukturen som vi nu ser virker processen omvendt - borgerne tvandstilpasses til Systemet, hvilket igen fører til tilsanding og legacy.

Specielt den offentlige sektor bliver systematisk mindre produktiv.

Hvis du ikke addresserer dette problem, bliver dit forslag en del af problemet.

  • 0
  • 0
Steen Krøyer

Du rammer sømmet lige på hovedet! Bag alle disse ledelses- og projektstyringsmodeller (Prince2, ITIL osv.) ligger en forældet antagelse om at projekter kan styres deterministisk. Dvs. hvis vi bare planlægger længe nok, skriver tilpas mange hyldemeter dokumentation, opstiller tilstrækkeligt mange og detaljerede krav, uddanner tilstrækkeligt mange mennesker og indfører tilpas mange standarder - ja, så kan alle projekter laves indenfor de opstillede rammer (tid, økonomi etc.).

Problemet er bare at det kun gælder for projekter som er en eksakt kopi af tidligere projekter, for kun i sådanne tilfælde har man al den nødvendige viden på forhånd. Men for alle andre projekter, og det gælder især alle interessante ikke-trivielle projekter, er pointen den at projektet nødvendigvis må gennemføres uden at al den nødvendige viden er tilstede fra starten.

Projektstyringen må derfor nødvendigvis udøves i fravær af komplet viden. Undervejs bliver man klogere, og når projektet er slut ved man hvad man burde have gjort. Det selvf. en banal iagttagelse, men konsekvenserne for projektstyringen er ikke så banale. Det er min påstand at moderne projektledelse, af store og ikke-trivielle projekter, primært er en øvelse i at håndtere usikkerhed. Og det hjælper ikke at forsøge at begrave denne usikkerhed i tonsvis af papir, procedurer, standarder o.l, det bliver den ikke mindre af. Der er bare visse ting man ikke kan vide på forhånd. Verden bliver mere og mere kompleks, ikke mere og mere simpel, lev med det, det bliver aldrig anderledes.

Hvis man ikke accepterer at f.eks store offentlige IT-projekter er behæftet med betydelige usikkerhed mht. endelig funktion, varighed, omkostninger, tekniske udfordringer osv., bliver vi aldrig bedre til at gennemføre dem.

"Hallo!" kan jeg høre nogen indvende, "vil det sige at politikerne skal bevilge penge til projekter uden at vide hvor længe de vil vare, og uden at vide præcist hvad de får for pengene?" Ja! Det gør de jo dels i praksis allerede i dag, hvor vi ser de papir- og proceduretunge projektstyringsmodeller fejle igen og igen, dels er de bedre stillet ved at vide at der er usikkerheder end ved at tro det modsatte.

Jamen, skal vi så tilbage til den mørke stenalder, hvor købere af it-projekter troede de bestilte een ting, reelt specificerede noget andet, fik leveret noget helt tredje, og hvor alle projekter løb over tiden og budgettet?

Niks, for hvis man først accepterer usikkerhed som en af de primære faktorer i projektstyringen, kan man begynde at gøre den synlig og dermed agere hensigtsmæssigt. Det gælder f.eks indenfor områder som estimering/budgettering hvor der findes veludviklede teknikker til at gøre usikkerheden synlig. Men også hele planlægnings- og ledelsesdelen kan agere mere hensigtsmæssigt, hvor man f.eks gennem hensigtsmæssig brug af pilots og agile/iterative udviklingsmodeller bevidst arbejder med at nedbringe usikkerheden gennem hele forløbet.

I nedenstående, noget forsimplede, beskrivelse, mener jeg at de fleste offentlige IT-projekter benytter model 1, mens det jeg advokerer for er model 3.

Model 1: Man ved godt at der er betydelige usikkerhedsmomenter, men prøver at omgå dem ved at specificere, estimere og planlægge ned i mindste detalje. Det sker ud fra devisen "Hvis lidt papir og procedurer kan give lidt struktur og styring på tingene, så kan meget papir give meget struktur og styr på tingene." Når uforudsete hændelser indtræffer, koster det meget arbejde at skifte kurs og holde hele procedure- og papirapparatet opdateret.

Model 2: Man ved godt at der er betydelige usikkerhedsmomenter, men prøver at omgå dem ved at benytte agile/iterative udviklingsmetoder. Man arbejder ikke bevidst med usikkerhederne, men stoler på at man agilt kan reagere på dem når de gør sig gældende. Når uforudsete hændelser indtræffer, justerer man efter bedste evne, og med mindre omkostninger, projektet.

Model 3: Man ved godt at der er betydelige usikkerhedsmomenter, og prøver at tackle dem ved at benytte agile/iterative udviklingsmetoder kombineret med synliggørelse af usikkerheder. Man arbejder bevidst med usikkerhederne, og benytter agiliteten til hele tiden at udforske og minimere usikkerhedsmomenter. Når uforudsete hændelser alligevel indtræffer, justerer man efter bedste evne, og med minimale omkostninger, projektet. Omkostningerne er minimale fordi man godt vidste at der var en usikkerhed på et område og derfor ikke på forhånd har truffet dyre beslutninger der afhang heraf.

Puha, nu er det her allerede ved at blive for langt, så jeg slutter her. Men det er spændende diskussion det her. Vi kan jo alle se at det man i dag gør for at styre store offentlige IT-projekter ikke virker for godt. Og jeg tror ikke at det hjælper at hælde mere af den samme sovs over. Husk at en definition af vanvid er at gøre det samme igen og igen, og forvente et andet resultat.

  • 0
  • 0
Mette Birkedahl Christensen

For mig at se er det aldrig en dårlig ide at tænke sig ekstra om - også før man losser et stort projekt i vandet.
I forhold til projektledelse og metoder forekommer
det umiddelbart, at Prince2 udøvende ledere - ikke i tilstrækkelig grad løfter risikohåndteringen.
Det amerikanske og ældre projektledelsessystem, PMI,
satser hårdt på at dygtiggøre ledere i risikohåndte-
ring - og amerikanske eller ikke-europæiske - (Prince2 er et engelsk system) virksomheder i Danmark - følger vist generelt også denne linje.
Men måske er det fordi det offentlige - ikke
tænker (endnu) så klart bundlinje, effektivisering,
resultat og ikke mindst motivation af medarbejdere -
at projektledelse hænger i laser. Det er politisk styrede organisationer, der ofte ledelsesmæssigt mangler eller netop ikke er istand til at levere et 'commitment' til at tage ansvar for projekters succes!
Projektledelse burde være en cocktail af forskellige
metoder og redskaber, til at komme succesfuldt i hus.

  • 0
  • 0
U.D. Pedersen

Hvis sådan et projekt skal lykkes skal der folk med hjerne, nosser og erfaring ind på de pladser hvor beslutningerne tages. Se hvor meget dette projekt har kostet borgerne http://www.digital-tinglysning-skandale.dk/listall.html

Brug dog pengene på at sikre de skarpeste hjerner i landet til sådan nogle projekter, istedet for alt det bøvl vi nu ser, som koster i milliardklassen, og giver så mange mennesker kvaler.

Modeller er gode til at skabe en fælles referenceramme, men de har ikke skyggen af chance for at håndtere de politiske og menneskelige aspekter som spiller en enorm stor rolle i hvor vidt sådan et projekt bliver en succes.

GØR DET RIGTIGT FØRSTE GANG - er så meget billigere og nemmere for alle :-) Men selvfølgelig ikke lige så godt for beskæftigelsen her i landet :-)

  • 0
  • 0
Torben Mogensen Blogger

Jeg tror, at problemerne primært skyldes, at man lader store IT-projekter ledes af ledelsesuddannede mennesker uden dyb IT indsigt. Disse ledere kan opstille fine diagrammer over projektfaser osv., men de kan ikke vurdere, hvad det koster at lave og hvor meget tid det tager, for det kræver en indsigt i, hvilke tekniske problemer, de forskellige krav kan medføre.

Omvendt vil en teknisk kyndig IT-person måske kunne identificere potentielle problemer, men ikke nødvendigvis kunne organisere et større projekt. Så der er behov for folk med både dyb teknisk indsigt og erfaring med ledelse af større projekter.

Den slags hænger ikke på træerne, så man er i regel nødt til at lave teams. Det gør man også, men ofte består disse teams af folk, der ikke forstår hinanden og har svært ved at arbejde sammen. Derfor bør man ikke sammensætte disse teams ad hoc for hvert projekt, men have nogle faste teams af ledere og IT-eksperter, der arbejder sammen på en lang række projekter, startende med mindre projekter og først senere på større. Og hvis en eller flere personer i et sådant team udskiftes, så skal teamet straks rykkes ned i projektstørrelse, indtil de nye personer er "indkørt" i teamet.

Det vil sikkert ikke løse alle problemerne, men det vil reducere de værste katastrofer.

  • 0
  • 0
Markus Hornum-Stenz

..som jeg er meget enig i:

Det egentlige dilemma ligger velnok i at man adskiller forretning og IT som to adskilte aspekter/interesser i en givent projekt. Dermed kommer disse to tilgange alt for nemt til at blive et kunde-leverandør forhold hvor man konkurrerer om magten og pengene og det bliver meget vanskeligt at forventningsafstemme.
Det er en dum IT-projekt kunde, som ikke i forvejen indtænker IT på det strategiske plan og har tekniske folk ansat, som er klædt på til at tale med systemleverandørerne på deres eget sprog.
Tilsvarende er det en dum IT-leverandør, som ikke har projektledere og account managere, som ved hvordan man sætter systemfunktionalitet i realistisk relation til forretningskrav og praktisk brugbarhed.

  • 0
  • 0
Peter Nørregaard Blogger

@Steen (og @Ole): Gode indlæg. Ud over metoderne spiller incitamenterne og kontraktstrukturen også kraftigt ind. Det kan gøres bedre - det er alle enige. Det interessante spørgsmål er egentlig hvorfor det så ikke [i]bliver[/i] gjort anderledes i større omfang end vi ser i dag.

  • 0
  • 0
Finn Christensen

@Ulver.... folk med hjerne, nosser og erfaring ind på de pladser hvor beslutningerne tages..

For højt og umuligt krav. De folk du nævner bliver enten vævet ind i organisationen og mister det, der netop var deres force, eller smidt af projekter pga de er fremmede fugle i disse politisk inficerede organisationer.

Det projekt de arbejder med og det menneskemateriale der skal fremstilles til, det er næsten alle som en diftsorganisationer - deres viden, uddannelse og formål - høj til lav - fast arbejde og stille rolig drift.

Drift incl. chefer har ingen interesse eller værdi af udvikling og projekter - tværtimod chancer for det værste, fiasko og ustabilitet + mere end de 7.5 timer arbejde om dagen.. listen er grumme lang kan jeg fortælle dig.

Du har en kløft der ikke kan løses via de skønne tiltag jeg læser i indlæggene her - der skal helt andre boller i den suppe.

  • 0
  • 0
Morten Korsaa

Mange kloge betragtninger i ovenstående - der er stadig håb :-)
Mit ydmyge bidrag er blot at minde om at det netop er de kompetencer man lægger bag der til sidst er afgørende. Prince2 er ikke godt eller skidt. Det er bare en model, som i hænderne på den rette bliver et nyttigt værktøj. Det samme med agile modeller. I hænderne på en der har overbevist sin ledelse om at han bare skal programmere, for han arbejder agilt, er agile metoder vel som en flammekaster i hænderne på en syvårig. Men i hænderne på den kompetente der bruger metoden til at risikominimere på det tidspunkt hvor det er mest hensigtsmæssigt, så er det utvivlsomt et af de mest lovende koncepter.

Jeg tvivler på at der er helte nok i verdenen til at redde de offentlige it projekter. Jeg tror mere på solide kompetencer indenfor bl.a. de her nævnte emner.

  • 0
  • 0
Ole Bech

De hidtidige indlæg i denne tråd afspejler ganske godt, hvilken problemstilling der ligger nedenunder hele debatten om de ustyrlige offentlige it-projekter. Det er nemlig en problemstilling, der vedrører, hvordan man helt grundlæggende opfatter virkeligheden.

På den ene side har vi objektivisterne. De mener, at virkeligheden er rationelt indrettet, forudsigelig og lovmæssig. Da den er det, kan vi mennesker også manipulere præcist med den, blot vi anvender de rigtige metoder og værktøjer. Virkeligheden kan altså måles, vejes, programmeres og ændres rationelt hen mod de mål, vi sætter for den.

På den anden side er der konstruktivisterne. De mener, at verden derude er et sammelsurium af forskellige opfattelser blandt mennesker og at der derfor ikke findes én objektiv virkelighed, men mange virkeligheder, som støder uforudsigeligt ind i hinanden. Ser man verden på denne måde, må man bruge andre metoder og værktøjer end objektivisterne til at håndtere verden, nemlig trail-and-error, eksperimenter, løbende dialog og forhandling, løbende korrektion og nyorientering.

Stephan, Mette, Ulver, Torben, Markus, Finn og Morten udtrykker et klar objektivistisk syn på verden og virkeligheden: Med de rette folk og de rette kompetencer skal vi nok få styr på de offentlige it-projekter. Steen, Søren, Peter og jeg selv hælder klart mere til den konstruktivistiske virkelighedsopfattelse, hvor usikkerhed og uforudsigelighed bliver omdrejningspunktet for fremadrettet handling.

Min pointe med dette er, at debatten om offentlige it-projekter slet ikke får medtænkt denne mere grundlæggende problemstilling, som dog må være helt afgørende, idet projekter jo i allerhøjeste grad bør forstås som menneskers indgreb i den virkelige verden med henblik på at forandre denne.

Personligt mener jeg ikke, at man kan opretholde et objektivistisk syn på verden, og i konsekvens heraf mener jeg naturligvis heller ikke, at de såkaldt ustyrlige it-projekter kan håndteres hensigtsmæssigt med metoder og værktøjer, der hylder et objektivistisk syn på verden.

  • 0
  • 0
Jacob Christian Munch-Andersen

I hvert fald til at starte med. Man kan ikke sætte 100 mand til at arbejde på et produkt så tidligt i udviklingsfasen, det gælder vist i øvrigt for stort set en hvilken som helst type produkt.

Måske man blot skal tænke på it-projekter lige som en hvilken som helst anden produktudvikling. Et begrænset hold til udvikling af en prototype, derefter kan man så skrue op for udviklingstempoet.

Kigger man fx på spilindustrien er det ikke usædvanligt at der forefindes et fuldt spilbart spil 10% inde i udviklingen, og på det tidspunkt er det vigtigt at få evalueret og ryddet op, for det er sidste chance for at ændre væsentligt i kerne funktionaliteten uden at kollidere med det arbejde som bygger ovenpå.

  • 0
  • 0
Finn Christensen

@Ole "..Stephan, Mette, Ulver, Torben, Markus, Finn og Morten udtrykker et klar objektivistisk syn på verden og virkeligheden: Med de rette folk og de rette kompetencer skal vi nok få styr på de offentlige it-projekter..."

Jeg forstår godt din opdeling og synspunkterne Ole, men mit konklusionen i mit indlæg var - at man bygger uden at tage værten i ed, altså grundlæggende havner som man kan forvente. Dit 'objektive syn' ligelede korrekt, men 'med de rette folk og rette kompetancer' er forkert. De kan sagtens være til stede - jeg har set utallige og fortræffelige i aktion.

Man kunne jo kikke på det jeg nævnte her "..listen er grumme lang kan jeg fortælle dig." som jeg af indlysende grunde ikke uddyber.

  • 0
  • 0
Lasse Lindgård

Jeg er enig i at projekter i størrelse x-large ville kunne styres bedre hvis man fra starten så usikkerheden i øjnene. Jeg kan bare ikke komme en løsning på hvordan man kommer derhen.

Problemet fra kundens side (staten m.fl.) er at de i starten af projektet skal vælge en leverandør.

Hvordan får man gjort det, hvis ikke man skal måle og veje på den pris, kvalitet og tidsramme som leverandøren tilbyder at binde sig til (under bod)?

Projekterne skal jo i udbud efter EU-regler. Foreskriver de ikke netop fastpris-projekter?

Når man så har valgt leverandøren, hvordan sikrer man sig så at projektet kommer i mål og ikke bliver en uendelig cashcow for leverandøren?

  • 0
  • 0
Anonym

Ole

Stephan, Mette, Ulver, Torben, Markus, Finn og Morten udtrykker et klar objektivistisk syn på verden og virkeligheden: Med de rette folk og de rette kompetencer skal vi nok få styr på de offentlige it-projekter. Steen, Søren, Peter og jeg selv hælder klart mere til den konstruktivistiske virkelighedsopfattelse, hvor usikkerhed og uforudsigelighed bliver omdrejningspunktet for fremadrettet handling.

Hvis du opfatter mit indlæg som objektivistisk i den forstand, du beskriver, så har du totalt misforstået hvad jeg siger.

Min pointe er at staten ikke kan lave gode systemer så længe de agerer planøkonomisk og prøver at vælge på vegne af meget forskellige behov i en dynamisk verden under hastig forandring.

Det man kan gøre er at åbne op og sikre at efterspørgslen har kontrollen til at trække forandringer og forpligtelsen til at prioriere ligger så tæt på den mest nuancerede opfattelse af behovet - nemlig hos den enkelte borger.

Om man laver dårlige planøkonomiske tiltag som de store katastrofale big bang modeller som Finansministeriet og KL gør sig skyldig i. Eller om man gør det via kaos-tiltag uden mål eller styring via en slags halvanarkistisk udvikling som stadig agerer indenfor det forvaltningscentrerede paradigme. Det kan vist nærmest komme ud på et.

Faktum er at offentlige systemudvikling som det praktiseres i Danmark er en nærmest sikker fiasko fordi det hardkoder stærkt ideologiske mekanismer som vi har set fejle masser af gange.

Du kan ikke kalde det objektivistisk at ville sikre at kontrollen følger behovet og infrastrukturen skal ånes så man kan have forskellige løsninger parallelt. Tværtimod er det stærkt konstruktivistisk.

Det er tværtimod implicit objektivistisk når du tror eller blot prøver at sakbe illusionen af at agile udviklingsmetoder ændrer på noget, når styringsrammerne stadig er objektivistisk planøkonomisk styret. Det som sker er at interesserne tilsidesætter behovet, istedet for at systemerne tilpasses til behovet.

Men hold lige fast i at jeg tager en idelogisk neutral tilgang - man behover ikke at privatisere for at flytte kontrollen til borgeren selv over omfordelte ressourcer.

  • 0
  • 0
Ole Bech

@ Lasse. Du har fat i et særdeles vigtigt aspekt, nemlig den kontraktmæssige side. Det er jo rigtigt, at hele EU-lovgivningen på dette punkt styrer i retning af, at projekter skal specificeres og planlægges ved skrivebordet INDEN projektet overhovedet er kommet igang. På dette skrivebords-grundlag indgås så en kontrakt mellem kunde og leverandør, som de kan slå hinanden oven i hoved med, lige så snart der kommer uforudsete hændelser i projektforløbet. Det er et særdeles uhensigtsmæssigt udgangspunkt for komplekse IT-projekter.
Der er derfor behov for, at der kan indgås en anden type af kontrakter - kontrakter, der baserer sig på iterative projektforløb. Faktisk har 3 advokater for nylig kommet med forslag til iterative versioner af K01 og K02 standardkontrakterne - KO1i og K02i - som netop adresserer dette behov.

  • 0
  • 0
Jan Ulrich Jensen

Det er en ret interessant diskussion. Jeg kan bare ikke lade være med at tænke, at det jo ikke er "det offentlige", der kører projekterne i sænk. Projekterne har jo været udliciteret til store firmaer i kategori med CSC, KMD, CapGemini m.fl. Disse store firmaer har i mange år brugt de offentlige projekter som en tilsyneladende uudtømmelig pengetank.
At det så er meget nemt at certificere sig i PRINCE2, PMP etc., gør jo ikke succesraten højere. Jeg har ladet mig fortælle, at KMD forlanger PRINCE2-certificering af sine eksterne konsulenter. Det er ikke sikkert, at det passer i alle projekter.
I min erfaring er nogle af de allerdyreste fejl opstået ved at lade ikke-tekniske projektledere tage tekniske beslutninger.
Lad nu være med bare at forlange nye "certificeringer" til "agile" projekter! Prototype-udvikling er slet ikke så nyt og smart, som IT-chefen i Roskilde Kommune måske tror. Det var pensum på Datalogi-studiet ved Københavns Universitet i 80'erne.

  • 0
  • 0
Ole Bech

@Jan. Det er såmænd ikke et spørgsmål, om noget er nyt eller smart. Men hvad der er mest hensigtsmæssigt. Faktum er, at den offentlige sektor fortsat sværger til paradigmet med fyldestgørende kravspec's up front og projekter gennemført efter vandfaldsmodellen - uanset hvad der var pensum på DIKU i 80'erne ;-)

  • 0
  • 0
Steen Krøyer

@Stephan

Om man laver dårlige planøkonomiske tiltag som de store katastrofale big bang modeller som Finansministeriet og KL gør sig skyldig i. Eller om man gør det via kaos-tiltag uden mål eller styring via en slags halvanarkistisk udvikling som stadig agerer indenfor det forvaltningscentrerede paradigme. Det kan vist nærmest komme ud på et.

Der er lidt stråmandsargument over den der. Intetsteds ovenfor er der nogen der gør sig til talsmand for kaos-tiltag uden mål eller styring. Jeg ved godt at mange i dag bruger agile metoder som undskyldning for ikke at planlægge eller disciplineret vedligeholde og forfølge projektmål, men de har så bare ikke fattet at agile metoder kræver lige så meget disciplin og styring som alle mulige andre udviklingsformer, blot anderledes vægtet.

Men dine pointer:

Min pointe er at staten ikke kan lave gode systemer så længe de agerer planøkonomisk og prøver at vælge på vegne af meget forskellige behov i en dynamisk verden under hastig forandring.

og

Faktum er at offentlige systemudvikling som det praktiseres i Danmark er en nærmest sikker fiasko fordi det hardkoder stærkt ideologiske mekanismer som vi har set fejle masser af gange.

rører ved noget centralt i denne diskussion. Hvis vi nogensinde skal bevæge os hen imod en situation hvor offentlige IT-projekter har en større chance for success end i dag, er det klart at opfattelsen af hvad det vil sige at gennemføre sådanne projekter skal ændres på alle niveauer. Og især skal det gamle planøkonomiske tankegods, som kan få enhver gammel østtysk politiker til at blive varm om hjertet, ud. Kunne man bare skubbe til hele måden projekter defineres og udliciteres på, er der håb. Om man så udfylder projektrammerne gennem agile metoder eller andet, er sikkert af mindre betydning. Det vigtige er at man både ifbm. udstikningen af rammerne, og den efterfølgende gennemførsel, hele tiden holder sig for øje at der er usikkerheder forbundet med projektet. Før vi accepterer disse usikkerheder og bevidst forholder os til dem, kommer vi ikke videre. Med en mindre omskrivning af Kent Becks ord, "embrace change and uncertainty".

Usikkerhed er ikke det samme som kaos. Kaos opstår når al determinisme fordufter, når man ikke længere ved hvad der er årsag og virkning. Den situation kan opstå af mange årsager, dårlig ledelse, manglende styring og planlægning, ringe forståelse af projektets formål, dårlig kommunikation mellem interessenter osv. Alt det ved vi, og vi ved også noget om hvordan sådanne problemer kan imødegås. Alle de gængse projektdyder skal vi have med, og oveni dem skal man så inddrage en ny dimension, at man bevidst arbejder med usikkerhederne i projektet. Det er så min pointe, og nu vil jeg hoppe af kæphesten.

Det man kan gøre er at åbne op og sikre at efterspørgslen har kontrollen til at trække forandringer og forpligtelsen til at prioriere ligger så tæt på den mest nuancerede opfattelse af behovet - nemlig hos den enkelte borger.

Jeg kan godt følge dig et stykke af vejen der. Hvis man lod offentlige IT-projekter være meget mere styret af de bagved liggende behov, snarere end af et kludetæppe af fortolkninger af disse behov fra diverse instanser, startende med politikerne, diverse ministerier, højtstående embedsmænd, ekspertudvalg og en assorteret håndfuld konsulentfirmaer, kunne vi måske komme videre. For mig ser det ud som om at skrækhistorierne fra '70-erne og '80-firserne om dårligt specificerede projekter, og tekniske løsninger der blev trukket ned over hovedet på folk, har fået os til at falde i den modsatte grøft. Nu skal alt specificeres ned i den mindste detalje, med fare for at de reelle behov drukner i et hav af uprioriterede detaljer. Og verden og hans hund skal høres undervejs i processen, i et forsøg på tilgodese alle, med det resultat man ikke tilgodeser nogen. Og det er så her at jeg har lidt svært ved at se hvordan vi skal inddrage Hr. og Fru Danmark i de offentlige IT-projekter. For ideelt set skal offentlige projekter selvf. være til gavn for, om ikke alle, så nogen borgere. Men vi kan jo f.eks ikke involvere alle brugere af arbejdsformidlingerne, hvis man en dag får den ide at lave et AMANDA-2. Hvordan man så kunne gennemføre et mere reelt behovsstyret AMANDA-2, ved at slippe de gamle betonkommunistiske styringsmodeller, men uden at involvere alle slutbrugere af arbejdsformidlingerne, er faktisk et ret interessant spørgsmål.

Afslutningvis vil jeg sige at selvf. kan vi gøre det bedre. Der findes med garanti ikke nogen mirakelkur der kan garantere en 100% successrate på offentlige IT-projekter, men der findes sikkert fremgangsmåder der kan give en fiaskorate tæt på 0%.

  • 0
  • 0
Anonym

Ole

Vi er ikke langt fra hinanden her.

Øvelsen går efter min mening ud på at nedbryde systemerne i mange små systemer som tilpasser sig forskellige borgeres behov og så borgere kan vælge mellem dem og - i princippet - sammensætte dem efter behov.

Dvs. i stedet for at tale om et offentligt "System", så skal vi se hele samfundet som et system af løst koblede systemer, hvor koblingen styres af behovet og det er nemt at udvikle, sammensætte og afprøve nye løsninger.

Limen mellem disse løst koblede systemer er ikke fastlåste standarder og overvågningsmekanismer, men semantiske beviser så man kan overføre viden stukureret relativt uafhængigt af teknisk implementering og kilder.

DU skal være den eneste som kan overføre viden OM DIG, men du kan delegere denne styring i det omfang som passer dig og til dem som DU vælger at delegere til.

Den gammeldags planøkonomiske opfattelse af at vi står overfor et ideologisk valg mellem "velfærd" i form af gratis offentlige og skatteyderbetalte services versus "selvbestemmelse" i form af private services i en minimalstat er vrøvl som fejler både teknisk og økonomisk.

Sikkerhedsmekanismerne er de kritiske fordi det er dem som skal sikre at man kan lave interoperable modeller som samtidig isolerer den kontekst som en given process fungerer i - man skal TVINGE systemudviklingen og -udviklerne til at orientere sig mod borgerens egenstyring ved den infrastrukturelle ramme og det instutionelle framework omkring "samfundsdannelsen" som både dækker over den private og den offentlige sektor.

  • 0
  • 0
Vagn Hansen

Så længe det offentlige er belastet med ældre kontorchefer, som ved bedst, og middelmådige it-medarbejdere (de bedste søger det private med langt højere løn)kan man ikke undgå disse fatale fiaskoer.
Min tidligere kompagnion (nu it-direktør i en stor bank)var god til at forme et projekt. Alt blev designet i Excel eller lign, og kunden fik mulighed for at godkende ned til mindste detalje. Samtlige skærmbilleder og samtlige tastefunktioner var visuelt beskrevet, og kunden kunne vælge at godkende dette projekt. Kernen var bare, at min ven havde ikke skrevet een eneste programlinie. Progammeringsfasen startede først op efter at projektet var godkendt ned til mindste detalje.
Men derefter, når kunden ønskede ændringer, kunne man jo let se, at her var der tale om en programændring, og så begyndte det at koste.

Som ung arbejdede jeg som projekterende ingeniør hos Steensen & Varming vedr. Herlev Sygehus. Min chef sagde dengang at man aldrig måtte stoppe et byggeri på grund af fejl. I 80% af tilfældene er det billigere at rette fejlen via et nyt tilbud, end ved at acceptere ekstraregninger uden for kontrol.

Jeg tror at ovennævnte synspunkter er den væsentligste årsag til at et projekt kan stige fra f.eks. 100 mill til 600 mill.kr

  • 0
  • 0
Anonym

Nu er der forskel på et byggeriprojekt (som nok ofte løber over budget), og et it-projekt som griber alvorligt ind i processer efterfølgende.

Problemet er at embedssystemets ser sin primære opgave som at administrere og styre, men det som de i virkeligheden gør er at agere planøkonomisk dyne som isolerer udviklingen af løsninger fra de faktiske behov.

Det vender først når muren falder igen og det går op for folk at embedssystemet kun plejer egne interesser medmindre man stærkt styrer centraladministrationens ageren.

  • 0
  • 0
Vagn Hansen

"Nu er der forskel på et byggeriprojekt (som nok ofte løber over budget), og et it-projekt som griber alvorligt ind i processer efterfølgende.

Allerede fra min håbefulde studietid fra 65-69 blev vi grundigt informeret om, at processer skulle indordnes FØR man programmerede. Ofte fandt man så ud af at blot den systematiske opdeling af processer overflødiggjorde edb-indførslen. Derfor
Et IT projekt bør bestemt gribe ind før og ikke efterfølgende. Måske er det her man begår alle fejlene. Men lærebøgerne selv fra 60'erne foreskrev at man først tilpassede processerne til ADB (administrativ data behandling), og derefter omlagde dem til EDB (elktronisk data behandling).
I min studietid var ADB langt større end EDB.

  • 0
  • 0
Log ind eller Opret konto for at kommentere