Aftenposten tok kontakt i forrige uke for å få noen innspill om Akson-prosjektet. Resultatet ble publisert her.
Men artikkelen gjengir selvsagt ikke alt jeg sa, så jeg har fått lov til å publisere det fulle intervjuet her.
Aftenposten:
På bloggen din skriver du om “hvordan både konsulenter og fast ansatte har valgt en prosjektgjennomføring som går imot alt vi har lært om softwareutvikling og hvordan man unngår katastrofer.” Hva legger du i dette?
Svar:
Først og fremst mener jeg dette med at de har valgt å løse så mange problemer i ett stort prosjekt som skal gå over 10 år og koste flerfoldige milliarder kroner. Vi har veldig mye erfaring nå, både i Norge og internasjonalt, både i privat og offentlig sektor, som tilsier at størrelse på prosjekt, både i omfang, kostnad, tid og antall deltakere korrelerer negativt med suksess. Jo større prosjektet er, jo større sjanse er det for at det går dårlig. Dette har blant annet Magne Jørgensen i Simula jobbet og skrevet mye om, blant annet her.
Akson kommer til å være norgeshistoriens største IT-prosjekt, og er i så måte norgeshistoriens dårligste ide når det kommer til IT-prosjekter.
Det er bare fint at man ønsker å satse skikkelig på å forbedre helse-IT, og jeg er ikke negativ til at store summer brukes til dette formålet. Men rent IT-teknisk er det ikke lurt å organisere arbeidet som et eneste stort prosjekt med leveranser langt frem i tid.
Aftenposten: De eksterne fagfolkene som har vurdert Akson i kvalitetssikringsrapporten skriver blant annet:
“Det er etter vår vurdering en manglende harmoni mellom overordnede uttalelser om ambisjoner og hvilke muligheter man ønsker å åpne for, og innholdet i mer operative strategier og planer som skisseres for å nå de beskrevne målbildene. Samlet er det for mange viktige problemstillinger om løsnings- og gjennomføringsstrategi som er skjøvet fremover i tid uten å gi svar som normalt skal være dekket i SSD ( Sentralt styringsdokument ). Det er ikke tilstrekkelig synliggjort hvordan de overordnede prinsippene om økosystem, plattformtilnærming og samhandling, samt en stegvis gjennomføring, skal omsettes til en planlagt, konkret og troverdig løsnings- og gjennomføringsstrategi.”
Og:
“Etter vår vurdering er den samlede risiko knyttet til løsning og gjennomføring meget høy. Forskning viser at sannsynligheten for at prosjekter mislykkes øker betydelig når omfang og kompleksitet er stort, og varigheten er lang. Det er etter vårt syn nødvendig å tydeliggjøre både den stegvise utviklingen og den fasedelte innføringen av Akson journal for å redusere den tilhørende risiko.”
Stemmer dette overens med ditt inntrykk av prosjektet?
Svar: Ja, dette er gode tilbakemeldinger. Men jeg har lyst til å legge til at selv med tydeliggjøring av strategier og oppdelinger som de her ønsker seg, så bør man ikke gå videre med Akson. I mine øyne er det aldri en god grunn til å sette av mange milliarder kroner på ett prosjekt, uansett hvor godt “sentralt styringsdokument” det måtte ha. Det er i IT som med alt annet at når man først har fått en sekk med penger, så blir de brukt opp. Gullforgylte Mercedeser, håndvesker til 500 000 kr, jo mer penger man har, jo mer tull bruker man penger på. Med så rause rammer – 22 milliarder kroner – så legges det opp til enorm sløsing.
Det som gjør det enda verre, er at innen IT, er ikke sløsing av midler bare bortkastede penger, det gjør også at leveransene blir dårligere. Det å skrive software er ikke som å bygge et boligfelt med klart definerte tegninger. Man kan ikke øke produktiviteten med å legge til flere håndverkere slik man kan andre steder. Det å skrive software er mer som å skrive en bok, der kapitlene må henge sammen og historien skal gi mening. Jo flere forfattere som skal skrive på en historie samtidig, jo vanskeligere blir det, jo mer koordineringsbehov får man, jo større er sjansene for at boka blir umulig å forstå.
Aftenposten: Folk i IT-miljøet skriver om figuren (se vedlegg) at dette må være “skoleeksempelet på scope creep”. Hva tenker du om denne figuren?
Svar: Dette illustrerer så godt hvor lett det egentlig bør være å dele Akson inn i flere prosjekter. Her har vi masse bokser som beskriver konkrete behov man har innen helse. Det bør være uproblematisk å finne fine avgrensede områder man kan jobbe med som gir klare gevinster hver for seg.
En ting de konsekvent ikke gjør i disse mer tekniske dokumentene om Akson-prosjektet er å ta tak i begrepet “journal”. Når man ser på definisjonen av “Journal” så ser vi at en journal skal inneholde alt som kan krype og gå av informasjon som kan være relevant for helsepersonell. Bare det å snakke om å lage en “jornalplattform” som en ting, er problematisk i seg selv. Vi må se på hva de forskjellige delene av en journal er, og finne måter å jobbe effektivt med de forskjellige delene.
Når man skal dele opp software, er det lurt å dele det inn i deler som gir en konkret brukerverdi hver for seg. På den måten kan ledelsen mye lettere sikre at pengene blir brukt på en god måte. Det er vanskelig for en leder uten IT-kompetanse å vite hvordan det egentlig går med utviklingen av “en IT-plattform”. Det er veldig lett å kaste bort årevis med midler på plattformutvikling uten å sitte igjen med noe som kan brukes. Det er spesielt viktig i organisasjoner som ikke har dybdeforståelse innen IT at man alltid insisterer på å få levert noe som løser konkrete behov forløpende. Da kan alle følge med og bidra på best mulig måte inn i prosjektet.
Aftenposten: Hvorfor tror du da Direktoratet for e-helse har valgt denne løsningen – du var selv på dialogmøte om prosjektet i desember i fjor?
Svar: Jeg tror det er mange grunner til at de velger denne fremgangsmåten. For det første er det sikkert motiverende for ledelsen å tenke at “Nå skal vi ordne opp i alle problemene innen helse! La oss ta i et skikkelig tak.” Det er mer prestisje å lede et stort prosjekt, enn å lede et lite ett. Og for ledelsen, som sitter og ser på det hele ovenfra, som har ansvar for alt, så er det lett å tenke at alt sammen er ett problem. Man ser på problemer og finner løsninger utifra sitt eget perspektiv. Mitt perspektiv som utvikler, og brukernes perspektiver er ganske annerledes enn for toppledelsen. I IT-prosjekter er det viktig å alltid minne seg selv på at det er brukernes perspektiv som er det viktigste – det er det lett å glemme.
En annen grunn til at man gjør det på denne måten er problemer rundt finansiering av IT. Ideelt sett bør utvikling av software gjøres “i linja”, med ansatte (gjerne supplert med konsulenter ved behov). Private foretak som driver med software, Finn.no for eksempel, legger ikke ut prosjekter på anbud når de får en idé om en forbedring eller ny funksjonalitet som skal inn i deres tjenester. De har en etablert utviklingsorganisasjon som har stabile budsjetter og jobber kontinuerlig med både ny funksjonalitet og forbedring av gammel funksjonalitet. Men i staten har man mange steder gått vekk ifra dette, selv om IT-systemer i aller høyeste grad er et kjerneområde flere og flere steder. Uten egen linjeorganisasjon, er den eneste måten å få midler til utvikling å starte et prosjekt. Da virker det enklere å bare be om masse penger med en gang, istedenfor å måtte søke om nye midler i mange omganger.
Aftenposten: Du er jo selv i konsulentbransjen – skildrer konsulentbruken i “Konsulentmillionene” en kjent virkelighet for dere?
Virkeligheten dere beskriver i “Konsulentmillionene” er ikke tatt fra deler av prosjekter jeg selv typisk er involvert i, men jeg har måttet leve med konsekvensene av at “management consulting” uten IT-faglig kompetanse får holde på i årevis med planlegging før folk som meg blir involvert. Jeg har selv erfaring fra et større konsulenthus, og har vært med på et anbuds-prosjekt i 100-millionersklassen, og det er det verste jeg noen gang har vært med på rent profesjonelt. PWC driver ikke med software-utvikling i det hele tatt, de leverer kun “management consulting”-tjenester. Det er tydelig i all dokumentasjon om Akson-prosjektet at man mangler IT-faglig kompetanse i beslutningene og strategiene som velges. Her for eksempel ser vi hvordan de ser for seg å dele Akson prosjektet opp stegvis. De ser for seg at man kan ha flere anbudsrunder med følgende rammer:
Journalplattform
Forvaltning av identiteter og rettigheter
Utvikling av grensesnitt og integrasjoner
Applikasjonsdrift og forvaltning
Driftsplattform
Kompetanse- og kapasitetsforsterkning
Tilleggsfunksjonalitet
Hvis man ikke kan noe om IT, høres sikkert dette helt greit ut. Men for en som jobber med dette ser man umiddelbart at alle disse leveransene er gjensidig avhengig av hverandre. Ikke en eneste av disse leverer brukerverdi. Man kan ikke ha en journalplattform uten en forvaltning av identiteter, eller grensesnit og integrasjoner, eller driftsplattform. Ingen av leverandørene vil kunne levere noe uten å koordinere med alle de andre. Det er slik det så altfor ofte blir. Man bruker millioner på dyre management konsulenter i lange planleggingsfaser som vedtar prosjektplaner som gjør det nesten umulig å jobbe effektivt.
Aftenposten: Du reagerer ikke fordi dere må se på milliardprosjektet fra siden?
Tja, det hele kjennes kanskje som å være utdannet kokk og sitte på en kjempedyr restaurant med åpent kjøkken, og se på at de som jobber på kjøkkenet putter kjøttdeig i sjokoladesoufléen og blander salaten med tærne mens de kontinuerlig kaster bøttevis med safran opp i lufta som blir blåst ut vinduet av store vifter. På den ene siden får en lyst til å bidra med sin kunnskap for at ting skal bli bedre, men det er ikke fristende å skulle ta del i det som skjer på kjøkkenet på noen som helst måte. Mest av alt er det utrolig provoserende at store mengder av ens egne penger skal brukes på slikt sløseri.
Reblogged this on Oligofren.
Sendte deg en epost hvor jeg utdyper noen av mine synspunkter til deg.
Knallbra intervju! Veldig bra svar på tiltale på slutten 😀
Som tidligere programutvikler, senere leder for å ta i bruk IT, så jeg tidlig at i tillegg til å løse en oppgave, må software oppfylle brukerens oppfatning om at dette er noe som virker!! Man må sette seg i brukers sted, og spørre: “Hva tjener jeg på dette?” . Hvis svaret da er positivt, dvs at brukeren oppfatter at dette er arbeidsbesparende og effektivt, vil brukeren aktiv lære seg og utnytte verktøyet. Hvis brukeren oppfatter systemet som tungvint og lite hensiktsmessig, vil vedkommende i det lengste unngå å ta systemet i bruk, og leve på gammel løsning så lenge som mulig. I tillegg bør systemet utvikles bit for bit, og lokke brukeren med seg. Se på Facebook. Eller Altinn. Dersom disse hadde blitt lansert slik de fremstår i dag på første dag, hadde de vært så kompliserte at ingen hadde tatt de i bruk. Imidlertid var de første versjonene ganske enkle og lettfattelige, og man fikk brukerne med seg etterhvert som man stadig la til ny funksjonalitet. Det samme kan man si for Windows, Word, Excel osv.
Flott at du får frem dette til Aftenposten. Og sammenligningen din til slutt: Perfekt.
Jeg hadde heller ikke gått inn på dette “kjøkkenet”!