Sundhed 3.0 - Behov for nytænkning haster mere end nogensinde

Bertel Haarder - Grundlovsmøde 2011

Ved afslutningen af Folketingsåret kunne Bertel Haarder løfte armene, da Sundhedsministeriet som det eneste ministerium tilsyneladende får tilført ekstra milliarder år for år frem mod 2020.

Ser man nærmere efter, er dette et resultat af tidligere indgåede aftaler, bortset fra de fingeraftryk, som Pia Christmas Møller fik sat, og som især gavner det psykiatriske område. Men hvordan ser det ud i fugleperspektiv?

Vi står ved starten på et omfattende sygehusbyggeri, som i løbet af de næste 10 år vil koste 41 Mia kr., hvoraf de 25 mia kommer fra Staten og resten fra Regionerne. Tilskuddene er blevet prioriteret efter alle kunstens regler, og regeringens ekspertudvalg har grundigt analyseret regionernes planer og tildelt midlerne og offentliggjort begrundelsen i rapporten fra november 2010.

Men allerede før rapportens fremkomst var der kritiske røster, der pegede på, at en al for stor del af de afsatte midler ser ud til at vedrøre mursten snarere end teknologi, på trods af intentionerne og på trods af regeringens oprindelige visioner om at det omfattende sygehusbyggeri kunne blive en showcase for de danske kompetencer på området. Den 25. maj kunne man i Ingeniøren læse en artikel under overskriften: Ingeniører om Supersygehuse: Byg et ad gangen.

Heri anbefaler 71 procent af de adspurgte ingeniører at sygehusene bygges serielt, så man kan lære af hinanden. Næstformanden for regionerne, Carl Holst er ikke enig, han siger at man dels baserer sig på internationale erfaringer fra Sverige, Norge, Finland og Island (der var deltagere fra Sverige og Norge med i Regeringens ekspertudvalg), og dels er man meget obs på at lære af hinanden.

Hverken de 71% af ingeniørerne eller Carl Holst forholder sig imidlertid til kritikken om, at kun en beskeden del af investeringerne sker i teknologi.

Værre bliver det, når Bertel Haarder understreger, at man ved den nye sundhedsaftale 'fokuserer på brug af Telemedicin, der vil kunne spare 4-6 milliarder kroner'. Bertel Haarder henviser her formodentlig til Formanden for Dansk Selskab for Telemdicin, Klaus Panareth, der udtalte at 4.700 hospitalssenge kunne spares væk, såfremt sygehusvæsenet virkeligt skruede op for brug af telemedicin. Han anslår, at næsten halvdelen af de 3 millioner sengedage, som medicinske patienter har hvert år, kan spares væk. Det giver 7 milliarder kroner.

Bertel Haarders forklaringsproblem er imidlertid, at kommunerne i dag overhovedet ikke har taget telemedicin til sig (Se vores udredning om dette) ,at der ikke er planlagt en revision af hele organiseringen af sundhedsvæsenet, som dette ville medføre (Og som ekspertpanelet faktisk direkte har anbefalet i kapitel 3, synspunkter på fremtidens sygehusstruktur) – og hvad værre er, at man har afsat 50 millioner til at fremme brugen af Telemedicin. Beløbets størrelse står slet ikke mål med den mulige besparelse, og man har ikke tænkt andre incitamenter ind i modellen, men ovenikøbet ændret afregningen mellem kommuner og sygehuse i en retning, der ikke umiddelbart fremmer tilskyndelsen til at investere i hjemmeovervågning, organisatoriske ændringer, sammenhæng med primær lægetjenesten.

(Det er åbenbart symptomatisk at man hellere vil give 300 mio til en øget toldkontrol ved grænsen, som har vakt vrede hos alle vores naboer – men det er jo en anden historie!)

Det kan næppe være ABT-fondens opgave at designe den organisatoriske ændring af den danske sundhedsmodel, der vil være nødvendig frem til år 2020 – og slet ikke for 50 mio kr! Lige så lidt som man kan tage ingeniørernes anbefaling om at bygge sygehusene sekventielt alvorligt – det er jo stadig 'kun' en delmængde af det samlede problem.

Allerede i efteråret kunne man i MandagMorgen den 24.9 læse en artikel under overskriften

'Århundredets sygehusinvestering risikerer at blive tabt på gulvet'

Hvor kan man gå hen for at se gode erfaringer, der flytter patienterne ud af sygehusene og medfører en højere sundhedstilstand? En af de cases, som mange peger på, er Kaiser-Permanente i Californien. Her har man dels etableret nogle af Verdens mest moderne hospitaler, men også organiseret hele patientforløbet på en meget mere effektiv måde. Man har etableret store lægecentre, hvor både almen praktiserende læger, speciallæger, sygeplejersker, laboranter og andet sundhedspersonale kan supplere hinanden, stå for en effektiv diagnose og visitering og ikke mindst bistå ved 'call centre' for udskrevne patienter, så genindlæggelser minimeres og patientens trivsel øges. Så vi skal ikke 'vælge' læge i Sygesikringen – men lægehus. Det vil fremme en hurtig diagnose, øge trygheden og mindske presset på sygehuse.

Hvis vi om 10 år står med en aldrende befolkning, hvor patienter med kroniske sygdomme beslaglægger 60-75% af det samlede sundhedsvæsens ressourcer, er det oplagt at flere vil lide af mere end én kronisk sygdom med hvad det fører med sig af behov for viden om forskellige mediciners virkning på hinanden, individuelt tilpasset overvågningsudstyr og behov for patientens on-line kontakt via lægecenter med relevant personale – enten i centret, på specialesygehuset eller hos andre.

Det er ikke nok at allokere 50 mio til en ABT-fond, der ikke har ansvar for re-organisering af sundhedsvæsenet, det er ikke nok at give 600 mio til en ny helikopter og akutbiler (omend lægehusdelen af dette initiativ er et lille skridt på vejen, selvom det er et hold-kæft bolsche til 'udkants-Danmark).

Ekspertudvalget, der indstillede prioriteringen af investeringerne i de nye sygehuse, var i deres kommissorium begrænset til at vurdere indretningen, organiseringen og designet af de nye sygehuse, ikke af den samlede sundhedssektors organisering. Og det er det, der er behov for.Som udvalget skriver i afsnittet om 'synspunkter på fremtidens sygehusstruktur':

”Fremtidens sygehus må derfor ikke planlægges og bygges som en simpel lineær fortsættelse af fortiden. Fremtidens sygehuse er ikke lig med selv det nyeste af dagens sygehuse. Der skal tænkes mindst 10 år frem, før flere af sygehusene overhovedet tages i brug. Udfordringerne til fleksibilitet er store, idet man kan forvente, at en stor del af den teknologi, som skal til rådighed for sygehusene i 2020 slet ikke er kendt i dag.”

”Med det omfattende investeringsprogram skal der være plads til nytænkning omkring organisering, logistik og brug af teknologiske muligheder.” (s.19)

Der er kort sagt brug for en meta-model for sundhedssektorens opgaver, funktioner i relation til patientgrupperne – herunder af forholdet mellem forebyggende behandling, fjernbehandling, selvbehandling, diagnosticering, forløbsstyring, kvalitetssikring, udskrivningskontrol, genoptræning og samspil med pleje, kommunale services, ambulante kontroller etc.

Vi kan anvende begreber fra Enterprise Architecture til at mappe byggeklodserne, flowet, funktionerne – og det skal IKKE forveksles med f.eks. G-EPJ, der var fejlslagen, fordi den efter flere års forsøg på generalisering af selv de mindste detaljer i arbejdsgange ikke fik opbakning og ikke havde mulighed for løbende tilpasning og justering. Hvis Regeringen sammen med KL og Danske Regioner virkelig VIL en sundhedsreform, der også omfatter almen praksis, så er det nu. INDEN supersygehusene sluger alle ressourcer og opmærksomhed og løser problemer, der ikke vil være relevante, når de står færdige.

Hvorfor fejler Offentlige IT-projekter? (in Danish)

Om betydningen af en Arkitektur: Gotikkens og Renaissancens domkirker afspejler en klar arkitektur, som har kunnet varieres utallige gange. Den er tilpasset de funktioner, der udspilles i den, og er skabt til en organisation. Den har kunnet overleve i århundreder ......

Indledning – Teknologirådets Workshop om Offentlige IT Projekter

Fredag den 21.5 afholdt Teknologirådet en workshop om hvorfor offentlige IT projekter fejler.Det var bl.a. baseret på udgivelse af Finansministeriets redegørelse for hvordan man planlægger at stramme op på IT Governance og projektstyring i offentligt regi. Jeg fremlagde i den forbindelse følgende i forbindelse med paneloplæg. Emnet for panelet var, hvordan brug af arkitektur og standarder kunne forbedre succesraten.

Hvorfor fejler offentlige IT projekter?

Offentlige IT-projekter har altid været genstand for kritik, så det er en historisk fejltagelse at tro, at det er en tendens, der er opstået i forbindelse med Internettets udbredelse – vi klarede os glimrende helt tilbage til etableringen af Kildeskatten og Sygesikringssystemet. Og det er ikke engang et specielt dansk fænomen, især UK, Australien, USA og andre har haft rigtigt spektakulære fejltagelser, så vi kan heller ikke skyde skylden på nationalkarakteren. Ser man på EU er det karakteristisk, at EU-systemet konsekvent fremhæver 'best-of-breed' og har alenlange beskrivelser af succesfyldte (EU-medfinansierede) eGovernment-projekter, men ikke nogen troværdige analyser af projekter, der fejler. Teknologirådets rapport, den såkaldte Bonnerup-rapport, en af de første forsøg på at systematisere fejlkilderne herhjemme, men faglitteraturen indeholder en række analyser, som giver flere aspekter, årsager til mulige problemer ved introduktion af teknologi i forskellige organisationsformer.

Maskinbureaukratier og netværksorganisationer

Den første grundlæggende fejltagelse er at opfatte IT og IT-løsninger som et stykke værktøj, der kan benyttes af en hvilken som helst organisation uden ændringer. Et traditionelt bureaukrati, der i en hierarkisk struktur arbejder mod et veldefineret formål, og hvor udførelsen koordineres og styres i kraft af regler og standarder, og vidensbasen holdes ajour i arkiver, skulle på papiret jo ellers være let at forsyne med nye værktøjer og IT løsninger, men til overraskelse for traditionelle sociologer viser det sig, at tilkomsten af teknologi ikke 'bare' automatisk fører til en symbiose: Viden og kunnen, der før var indlejret hos de enkelte medarbejdere, udføres måske nu af nye systemer, og det kræver forandring af (rutine) jobs, og det kræver forandringsledelse – for hvad gør man, ved medarbejdere, der skal 'aflæres' gamle vaner ? Morale nummer 1 er at teknologi og organisationer altid påvirker hinanden.

Men med opblomstringen af internettet er muligheden for at understøtte nye organisationsformer blevet meget mere oplagt – men hermed stiger kompleksiteten flere størrelsesordener og muligheden for spektakulære fejltagelser tilsvarende. En netværksorganisation kan bestå af alt fra uafhængige offentlige og private virksomheder, der 'bare' har en fælles indgangsportal til sammensvejsede og integrerede løsninger, der bygger på samspil mellem de indgående organisationers data, applikationer og programmer. Hvor et traditionelt bureaukrati holdes sammen i hierarkiet ved regler og ordrer, er motivationen og styrken af sammenholdet i en netværksorganisation fuldt og helt bestemt af gensidig tillid, interoperabilitet, fælles værdier – også benævnt 'social capital'. Også her øver teknologien en afgørende indflydelse på netværksorganisationens evne til at fungere, da teknologien medfører transparens, vidensdeling og åbenhed. Hvis kulturen, arbejdsformen, ledelsesformerne i de indgående organisationer er meget forskellig, vil tilførelse af teknologi kræve ændringer – i den enkelte medarbejders arbejde, i de regler, der styrer den enkelte organisation og igen : Det kræver forandringsledelse hos alle indgående organisationer.

Hvis vi skal tænke på nyere eksempler på problemstillinger, der illustrerer de 2 typer af organisationer, er det nærliggende at tage Tinglysningen og Domstolsstyrelsen som eksempel på det traditionelle hierarkiske bureaukrati, medens projekter som Den Offentlige Indkøbsportal, DOIP'en og i nyeste tid det kuldsejlede projekt for det danske katastrofeberedskab, SINE, som et godt eksempel på en netværksorganisation mellem vidt forskellige myndigheder og institutioner.

Hvor DOIP'en nærmest kan betragtes som en fælles portal, er SINE projektet et projekt, der var tænkt at indgå som rygrad i mange forskellige beredskabsmyndigheder – fra politi, beredskab, brand, ambulance, hospitaler, kommunale enheder.

Hvor kommer Arkitekturen så ind i billedet?

I oplægget til dagens seminar står med flammeskrift:

”Det offentlige har brug for en overordnet IT-arkitektur til at sikre interoperabilitet mellem forskellige offentlige systemer og åbne for privat brug af data til støtte af (for ?) den offentlige infrastruktur.” Som standardeksempel på hvor en sådan fælles arkitektur ville have hjulpet, anføres EPJ-situationen i Danmark, hvor vi fortsat står uden en fælles Elektronisk Patientjournal, der dækker hele landet. Implicit synes løsningen derfor at være at ophøje VTU's hvidbog om IT Arkitektur til en lovbefalet, landdækkende arkitektur, hvorefter alle haver sig at rette. Men forholder det sig nu også sådan? Og er der overhovedet nogle fornuftige alternativer til sådan et udsagn?

For at kunne besvare det på en afbalanceret må kan vi gå tilbage til 'Alle EA'ers fædreland' USA.

The Clinger-Cohen Act 1996

Den amerikanske kongres vedtog i 1996 denne lov, der er en forudsætning for amerikanske ministerier og myndigheder for at opnå bevilling til iværksættelse af nye IT systemer. Lovens bogstav kræver af de ansøgende myndigheder, at de har opstillet ”An integrated framework for evolving and maintaining existing information technology and acquiring new information technology to achieve the agency's strategic goals and information resources management goals”

Den praktiske håndhævelse heraf foretages af OMB – Office of Management Bureau – som har udvidet/præciseret ordlyden til at være et krav om en egentlig Enterprise Architecture, som defineres som ”An agency-wide roadmap to achieve an agency's mission through optimal performance of its core business processes within an efficient information technology environment.” Og det er det, vi i dag forbinder med EA: en samlet arkitektur, der binder forretningen og dens strategiske mål og opgaver sammen med IT løsninger og infrastruktur.

Så for at vurdere om ministerier, institutioner, 'agencies' lever op til loven, vurderer OMB så kvaliteten af den EA, der følger med ansøgning om nye bevillinger.

Det man vurderer er kvaliteten af den enkelte EA (Idet der netop ikke forlanges en fælles EA på tværs af myndighederne). Kvaliteten af den enkelte EA måles på:

• Tolerance for ændringer – Er det muligt at skifte strategisk sigte/teknologi/organisation ?

• Giver EA'en støtte for implementering af det/de nye systemer?

• Er der indbygget en evne til at justere delmål undervejs i implementeringen?

• Medvirker EA til at sikre en høj grad af målopfyldelse for projektimplementeringen?

Fokus er klart, at EA skal medvirke til at definere og støtte etablering af borger-centrerede, resultatorienterede løsninger – vel at mærke i høj grad baseret på standard komponenter (COTS: Commercial Off The Shelf). Hovedsigtet med loven og den måde, den administreres på, har været og er at medvirke til at få de enkelte resportområder moderniseret og effektiviseret som en direkte følge af den indsats, som Clinton-Gore regeringen satte i gang i halvfemserne.

Det har resulteret i mange og mange forskellige EA-versioner (Se f.eks. Beryl Bellmans paper her:) i de enkelte amerikanske ministerier og forvaltninger: Treasury Enterprise Architecture Framework, Department of Defense Architecture Framework, Federal Enterprise Architecture Framework med 5 underliggende frameworks m.v.

Fordele og mangler ved den amerikanske model

Umiddelbart giver denne måde at løse EA på den generelle fordel, at det enkelte forvaltningsområde bliver tvunget til at redegøre for sine kerneprocesser og sætte dem i relation til IT understøttelsen på den måde, der er mest meningsfyldt for det pågældende område. Det betyder, at man ikke er afhængig af en fælles terminologi, og at man kan beholde sin kulturelt betingede tilgang til opgavedefinitioner, generelle regler, og frem for alt lettere kan afspejle det eksisterende, ofte traditionelle hierarkiske organogram i EA'en. Alt i alt forhold der medvirker til en hurtig accept, og som medvirker til en generel hurtigere forståelse for hvor og i hvilket omfang de planlagte ændringer påvirker organisation og arbejdsgange. Det er altså en god model når det gælder om at sætte strøm til bureaukratiske hierarkiske systemer, som tidligere defineret.

Og fordelen er helt klart at hele processen understøtter og hjælper til forandringsledelse. Herved prøver man så vidt muligt at undgå, at et bestående bureaukrati sander til og modvirker ændringer.

Det er også interessant at bemærke kravet om 'COTS' hvor muligt; hvor mange danske udbud ville ikke have set anderledes ud og været lettere at få udbytte af, hvis flere standardløsninger var blevet indført i stedet for håndprogrammerede løsninger, der opfylder 'ufravigelige krav', men som ikke fornys eller opdateres i takt med andre kunders erfaringer?

Men ulempen ved metoden kommer frem, når det gælder om at understøtte tværgående løsninger, der involverer flere domæner og mange (forskellige) bureaukratiske hierarkiske eller løst koblede netværksorganisationer, herunder frivillige organisationer (NGO'er), internationale partnere o.l.

Der er ikke nogen fælles EA for alle amerikanske myndigheder – og stadig ingen fælles datamodel.

Så der mangler en overgribende, 'meta arkitektur' – netop IKKE en fælles, detaljeret EA, men en arkitekturmodel, der kan favne de forskelligheder som der nu en gang er, og som kan fokusere på at etablere netværkssamarbejde i en serviceoritenteret arkitektur.

Og der er én yderligere ulempe, som måske ikke mærkes i et stort land, men som i Danmarks tilfælde vil spille en afgørende rolle: Et krav om at hver myndighed opstiller, vedligeholder og følger sin EA stiller automatisk krav om tilstedeværelsen af højt uddannede arkitekturkompetencer, for lige præcis koblingen mellem ledelse, strategi, kerneprocesser og IT er ikke noget, der lader sig outsource.

EA i Danmark - Hvor er de reelle udfordringer?

Er det rigtigt, at vi ikke havde fået en EPJ skandale, hvis vi havde haft en fælles arkitektur fra starten? Når vi HAR så mange forskellige, skyldes det jo den daværende sundhedsministers ønske om at 'lade de 1000 blomster blomstre' og derved satte gang i amternes uafhængige udvikling.

Fordelen ved den decentrale udviklingsmodel var, at rigtigt mange specialister og ildsjæle blev stærkt motiveret af det, og kastede sig ud i EPJ-løsninger, der godt nok stritter lidt i alle retninger, men som også hver især er resultatet af en solid lokal forankring og indsats.

Man forsøgte sig så – lidt sent – med at etablere en fælles arkitektur, den såkaldte G-EPJ, som Sundhedsstyrelsen satte sig for bordenden af. Det blev så af amterne opfattet som centralisme, et forsøg på fra SST's side at styrke sin position overfor amter og senere regioner, så de mange og endeløse diskussioner for at beskytte lokale særinteresserer tog så livet af G-EPJ, der i mange af sine definitioner forudsatte en helt bestemt klinisk arbejdsgang.

Og her står vi så. Vi står i en situation, hvor Danmark er det land i Verden, der har den største penetration af EPJ i hele Verden, vi er foregangsland for Obama, fra hele kloden rejser folk hertil for at se vores moderne sundhedsvæsen. Det har man let tilbøjelighed til at glemme.

Det værste, der kunne ske nu, var at nogen (politikere) kom og sagde, at alle eksisterende EPJ-systemer indenfor 5 år skulle erstattes af et fælles EPJ-system. Det ville virkelig spilde tid og penge – for udviklingen indenfor data analyse er heldigvis gået videre, og det ER allerede i dag en kendsgerning, at der er etableret en landsdækkende e-Journal (Se f.eks. fra region Syd:), der på daglig basis opdateres fra -næsten – alle EPJ-systemer i Danmark med fælles forståelige udtræk og informationer, der i langt de fleste tilfælde giver god mening. Samtidig understøtter e-Journalen kravene til datasikkerhed og privacy. Her er det altså data interface-standarden, der er afgørende, og som sikrer at man fra næsten alle sygehuse kan tilgå den fælles Journal, ovenikøbet ved hjælp at en front end løsning, der kan tilpasses individuelle behov. Moralen er her, at løsninger, der i det enkelte sygehus er kørt ind, accepteret af medarbejderne, som afspejler forskelle i arbejdsgange og kultur udgør en infrastruktur, som det vil være det rene spild at erstatte.

Som kuriosum kan vi nævne, at svenskerne tilsyneladende har lært af vores G-EPJ fejltagelser og nu er ved at etablere en fælles svensk standard, der understøtter individuelle arbejdsgange på de enkelte sygehuse og klinikker.

Åbne Standarder og Snitflader

Den anden virkelige udfordring i Danmark består i at blive enige om hvad en åben standard er. Det fremgik af den pinagtige diskussion om åbne dokumentstandarder, at man her i landet er endda meget tilbageholdne med at vedtage tiltag, der går Microsoft imod.

Når vi skal realisere målsætningen om at gøre de offentlige data tilgængelige for borgere og virksomheder, vil diskussionen blusse op igen med fornyet styrke. I modsætning til idealistiske ønsker om at have én fælles, lovbestemt EA for alle styrelser, ministerier og institutioner, må det næste skridt på vejen rimeligvis være at lave en prioriteret plan for de væsentligste offentlige registre, som vil kunne tilgås og forædles via web 2.0 teknikker, som Apps eller på anden vis bidrage til et højere serviceniveau - og til udvikling af nye IT-nicher.

Kort- og Matrikelstyrelsens grunddata, Danmarks Statistiks arsenal af data, Statens Museum for Kunst og den digitale Kulturarv, Det Kongelige Biblioteks samlinger, Rigsarkivet (der burde have været digitaliseret ved udflytningen), Danmarks Radios lyd- og videoarkiv, alle disse samlinger udgør spændende potentialer, men information og standardisering af interfaces, valg af åbne dataformater og billedformater trænger sig på, for at vi ikke én gang til skal stå i det dilemma, som politikerne åbenbart har så svært ved at skære igennem: Skal vi fortsat være afhængige af leverandørinteresser, eller må vi beholde vores kulturarv selv?

Konklusion

Arkitektur og åbne standarder er to af flere vigtige forudsætninger for at IT-projekter ikke kører af sporet. Men det er ikke de eneste krav, der bør stilles – det er ligeså vigtigt, at udbudsformen og udbuddets krav er tilpasset organisation, arbejdsform, graden af fornyelse som projektet indebærer.

Også hele ledelsesprocessen og ejerskabet, det vi kalder IT Governance, er én af de alvorligste og hyppigt tilbagevendende årsager til flops – man kan ikke outsource god ledelse, især ikke god forandringsledelse. Og man ikke klare den slags med et rejsehold.

Det vil ligeledes være ønskeligt at man i Danmark fik en tradition for at efterspørge standard-løsninger, COTS, hvor det vil give mening, i stedet for endeløse opsummeringer af 'ufravigelige' detaljekrav, som konsulenthuse betales gode timepriser for at identificere. Standardsystemer vil have den fordel, at de udvikles i takt med den samlede brugerskares krav, så når NATO kan have COTS som krav, bør den danske stat vel også kunne benytte det?

Og tilbage til arkitektur og åbne standarder: Arkitekturen skal understøtte forandringsprocessen, ikke fastfryse den. Formålet med arkitekturen er have et udgangspunkt, der kan absorbere, udnytte og tilpasse sig den teknologiske udvikling, uanset hvilken retning denne måtte tage. Og standarder er tilsvarende et middel på rejsen, der skal understøtte valgfrihed og fleksibilitet og forhindre utilsigtede konverteringer.

Efterskrift

Når jeg som illustration i starten viste Siena Domkirke som eksempel på en arkitektur, der er etableret som et blueprinty over hele Europa og er tilpasset organisationen og de funktioner, der er udføres i de enkelte varianter af arkitekturen, så er det ment som et kuriosum. Hvilken organisation kan klare sig uforandret igennem flere hundrede år? Hele pointen med EA er, at den skal være fleksibel, kommunikerbar, skalerbar.

Why do Public IT-Projects fail?

On May 21. the Danish Technology Council is inviting to a workshop under this heading. They have invited several specialists to present points-of-view on various aspects, and I am invited to comment on the need for standardization and architecture.

As this is central to the eGovernment course I am preparing for the Masters' education at the Danish IT University from this autumn, I welcome the initiative and the opportunity to discuss with some of the victims as well as meeting the people, that are classified either as 'rascals' or at least passive viewers to the mess, that admittedly seem to have happened a number of times.

This is not the first time the Danish Technology Council has focused on the topic; in 2002 a special group was created headed by Erik Bonnerup, a renowned public sector manager with a past track record of CEO also for KMD, the large Danish ICT-company focusing on municipal and regional computing.

The report from this group to a large extent has since been acknowledged as the best of it's kind, but unfortunately 8 years after the recommendations have not seen to have influenced the success rate much; The Govt. Audit Authority recently came to about the same conclusion as the Bonnerup committee, that hardly any public IT project meets it's objective nor sticks to the original project plan nor budget. The auditors point to the point that unforeseen complexities account for the majority of reasons for delays and budget overrun.

Having spent 39.5 years with one of the major suppliers of ICT technology to the Public sector, I recall numerous situations from way back – the Illness Insurance Project in 1972-73, the new Financial Management system for regional and local Govternment in late 70'is, the financial management system for all higher education centers and schools in the 80'is over the so-called Amanda project for the unemployment services in the 90'is, the Procurement Portal supposed to save billions for the public sector purchase agencies, to the original VIRK-project – a portal for all enterprises and their interface to the public - and to todays major flops – some well-known like the current problems with the digitization of the Property Registration System/cadastral System in Denmark – and some very well hidden but real disaster projects like the failure to deliver an emergency management system covering police, rescue services, hospitals, fire brigade and civil defense.

One thing they all seem to have in common is that all projects had a distinct borderline between the IT-project and the organizations, institutions, users and 'customers' = citizens/companies/other Govt. Institutions. Almost in all cases the vast majority of effort in the preparation phase has been allocated to a detailed specification of the functionality of the IT system, often to a degree where 80 % of very detailed requirements are specified as 'mandatory', and only in recent cases the requirements have also covered 'non functional' requirements – such as scalability, response time, security.

At the same time Denmark has been more and more focused on a very strict interpretation of the EU tendering regulations, and this leads to a situation, where innovation during project delivery is forbidden, where the public sector's project managers stick to the contract and not to possible changing realities, new technological development, even new happenings in the market place and environment.

Some of the recent thinking points to the lack of centrally defined mandatory strategic guidelines and a centrally defined IT Architecture for the public sector. The guidelines issued by the Ministry of Science and Technology were issued 3-4 years ago, but they are not mandatory, and to some of the municipal managers they may seem too academic and too far from day-to-day operational need.

Although I do agree that Enterprise Architecture definitely is part of the solution – in as much as the idea of EA is to couple management and ICT capacities according to the strategic business processes – I fear that a request for a centrally defined all-encompassing EA for the entire public sector will hamper innovation even more – and even stress some of the reasons for failure, that in my perspective are much more severe: ICT projects are defined too narrowly, too technically, and hardly never ever try to cover all the aspects of organization theory, social impact and the vast amount of knowledge that we have accumulated from non-IT studies on how technology are able to enable the performance of organizations – and recently even more the behavior of networked agencies and organizations, where the most ambitious ICT projects nowadays are being implemented. I will come back to how I view the possibilities of defining a Danish framework for EA in Government.

The Property registration System (link in Danish) is notorious in several ways: The government notary functions report to the institution called Domstolsstyrelsen, the agency that are controlling the administration and work of all courts in Denmark. The specific Land Registration Notaries are extremely sensitive for buyers and sellers of property, as registration is required to obtain financing, sell mortgages and start building or modifying on the properties sold. It started as a major analysis made by DeLoitte in 2005 with general use cases, project plans, overview of document types, a logical data model, benefits and costs – and a suggestion that the project could be finished end 2007.

To head the project a well known person with ICT background from the IT Task Force was selected – Adam Wolf. A very skilled person but none the less with an ICT background. The project was started based on DeLoittes recommendations.

After some delays the project was delivered by CSC in the autumn 2009. Immediately it created huge problems in the handling of the various document types already somewhere in the process, some of the delays noted were now several months – causing real financial problems for a lot of people. A request has recently be made that the private persons or small companies are reimbursed for their excess costs as a result of the delays. To this the CSC project manager in February responded, that 'The IT project was run according to plan – delivered at the approved time, and has been operating with an uptime of 99,8 since!'.

And today in Berlingske Tidende Adam Wolf states that 'The Property Registration System is an excellent solution that got an unfortunate start'. Adam W points to all the manual processes, that were 'extraordinary' including a 'backlog from the old system' stating that 'It was the (manual) case management system that didn't perform – not the IT system.'

In my opinion this simply underlines my argument that most of the problem is that the modernization project has ONLY been focused on the technical and technological aspects, including coding of the functionalities as stated by the changed legislation. What has NOT been considered has been the process to imbed the technology in the organization, including the handling of interfaces with the suppliers of data and information. Any sociologist will ask questions like how the acceptance, enablement and management of the change project was handled seen from the human and intra-organisational way. The political management behind the reform should have been advised that the change required more skills that ICT project management, and that human process knowledge and management are even more required in situations where processes are changed, where employees get unfamiliar tasks, when demands fluctuate and when traditional bureaucratic controls are used in stead of human motivation, establishment of social networks and encouragement of the new 'super users' as partners and mentors for those in need. This type of failures are common for all the projects, mentioned above – plus some specific blunders in each of them, of course.

So the future solutions are depending on:

1) Framework Enterprise Architecture and mandatory, selectede standards for API's

2) Less strict interpretation of EU tender rules with room for innovation and stepwise improvement of mutual understanding between stakeholders

3. Review of change management team – including sociological and organisational projekt management emphasis

4. General acceptance of performance measurement system including employee take-up of new IT projects

I will be back with more comments concerning the wrecked Emergency Management System – SINE – other points of learning can be obtained from this. ( And – as a sort of competition: May I ask by readers to try to google any relationship between Økonomistyrelsen, Terma, Sine and the Tetra Net. Somebody REALLY has a way of making clean ups!)

2 days with Chris Potts – Good Bye to IT as we know it!

(Breaking down the wall around IT !)

This week I spent 2 exciting days at one of Chris Potts' seminars on Corporate (IT) Strategy.

It certainly was an eye-opener for me, having lived through all stages of IT since the 360 mainframe.

A few years ago when Enterprise Architecture became the hot topic, we all agreed, that one of the fundamental problems of this world was to align business and business strategy with IT and IT strategy – but all this is nonsense, according to Chris Potts. 'You shouldn't have an IT Budget' was one of initial remarks. But after 2 days I am convinced he's right and that this new approach leads to complete different and much more meaningful business decisions, investments and methods of managing complex portfolio of projects – including projects heavily relying on IT and technology.

However, Chris' point of view is completely different from Nicholas Carr's 'IT Doesn't Matter' kind of approach trying to persuade business managers to spend less on IT, to follow in stead of leading at the 'bleeding edge'. Chris' point is straight forward: As you cannot do anything business wise without deploying 'some' IT and some technology in it's broadest sense, than there is simply no reason in treating IT 'projects' and IT spending as if it is an animal of it's own. What is even worse is, that this tradition has been thriving on the 'IT specialists' that have kept the WE and THEM paradigm in what Chris Pott calls the second generation II era. Fueled by crisis and downturn, the 2. G people are 'cutting down on IT spending' instead of asking the obvious question: What Value do we get for it? Which are the key business investment areas we should be concentrating on and first at this point maybe wonder of technology could be deployed in these areas in a smarter way than to day.

So it is not about cost, it's about value. (Even accountants are beginning to admit this!) IT in itself creates no value – as if we didn't know it, the sinister implication is that the public sector's (IT) projects being launched these days are all being selected according to the strict EU tendering rules focusing on minimizing cost and securing 'delivery' – meaning fulfillment of a development/deployment contract at a specific point in time at a spefic cost – but where is the value of the project?

Chris' observation not only leads to the clear conclusion that the perceived outcome in terms of value of a project not only should be the guiding principle, but that the whole accounting process around project selection and project management is completely wrong:

Any project – and public sector projects in particular – should be selected according to their contribution to value – maybe cost reduction is one of them, but in that case total operational costs. Also transparency could be a very interesting value of a public project as could citizen participation and take-up of eGovernment projects. So the estimated impact on all essential types of value is absolutely meaningful, but ONLY if the project management is measured on how the value of the project is created AFTER it's fulfillment. We are deploying 2. generation project managers maybe skilled in PRINCE 2 to deliver 4. generation solutions deploying web 2.0 technologies and aiming at involving citizens – but we are not measuring it.

One of the latest scandals in Denmark is the project dealing with electronic bonds and real estate registration. According to CSC's project manager 'The IT project is a success – we have a service level of 99.5% availability and we have had that for months!' - but reality is that now it takes anything from 4 to 8 months to register a sale of a real estate. Again – the tendering rules selected the winner of the development project, but didn't in any way measure, secure or include the total costs of the process, let alone found it necessary to manage that real value was actually achieved.

(See this blog: (In Danish) http://it-bizzen.blogspot.com/2007/11/csc-forsinker-hurtig-tinglysning-it.html )

So Chris Potts lesson is that you need to go to the thirds generation thinking: focus on the value people are getting from projects involving IT and employ BUSINESS experts to ensure this – not nerds, npår technical people – not even 'Enterprise Architects' still stuck in the THEM/US thinking.

But Nirvana only comes if you forget IT completely – drop the idea of a specific IT budget, think in terms of business organization and embed the investment and management issues of IT in the proper context.

In summary: From Chris we learned how to make an overall Corporate strategy in one page – with a clear strategic objective, with max 10 basic principles and/our beliefs and max 10 core tactics.

I can clearly recommend this seminar and the thinking behind it to any 2. generation frustrated IT manager or to any forward thinking CEO. If you happen to be employed by the Public Sector, I have to warn you, though: Your politicians are all 2. G, the rules are from last century and the narrow budget thinking is killing many bright ideas. But if you don't try, we might face 'civil unrest' – when the new generations used to web 2.0 technologies demand a decent way of thinking what value the Government is really bringing to the table!

(See also http://www.aeaassociation.org/ )