De ustyrlige offentlige it-projekter

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.

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.

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 :-)

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.

..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.

Hej Ole,
Jeg vil bare skrive at jeg er enig i din analyse.

Meget apropos konstaterer MIT Sloan også:
Leading companies [indenfor innovation] do less long-term planning and more sense and respond.

http://sloanreview.mit.edu/the-magazine/articles/2010/spring/51330/it-in...

/Søren P

@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.

@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.

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.

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å.

@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.

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?

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.

@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%.

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

"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.