Om e-Valg

Den 9. juni afholdt Teknologirådet en Workshop om mulige scenarier for e-valg som en del af den opgave, man var blevet stillet af Videnskabsministeriet om at undersøge muligheder for at indføre e-valg i Danmark. Projektbeskrivelsens titel er 'e-Valg – en udfordring for demokratiet?'

Baggrunden for projektet er tidl. Videnskabsminister Helge Sanders begejstring over at overvære det Estiske valg i marts 2007, hvor borgerne for første gang kunne deltage i fjernafstemninger ved anvendelse af den fælles offentlige/private digitale signatur (læs: smart card).

(Se Europæiske eksempler)

Ved dette valg stemte 5.4% af vælgerne på denne måde, men også andre lande har forsøgt sig med forskellige former for e-valg: Holland gjorde forsøg med stemmemaskiner, og i 2006 var stemmedeltagelsen ved hjælp af disse apparater oppe på 90%, men siden har det vist sig, at maskinerne (NEDAP) kunne hackes, og man er gået væk herfra foreløbig;

Irland brændte parallelt hermed mere end 51 mio € af på at etablere stemmeaskiner, som så blev droppet, medens det i Norge ser ud til at gå bedre: 11 kommuner vil være med til e-afstemning i 2011, og i Schweiz fik vælgerne i 11 kantoner muligheden for at e-stemme – og andelen var høj – mellem 21 og 68% af de afgivne stemmer var elektronisk afgivet.

Herhjemme har vi set forsøg på lokalt plan: Menighedsrådsvalget i 2008, forsøg med e-afstemninger i Frederiksberg Kommune og et prøvevalg for unge i 31 kommuner i 2009 i forbindelse med kommunalvalget, der også blev understøttet af e-valg.

Hvorfor e-valg?

Begrundelserne for at tilbyde e-valg må være at få en højere vælgerdeltagelse, men sekundært måske også at sænke omkostningerne ved afholdelse af valg. En højere valgdeltagelse kan være svært at eftervise i de eksempler, vi indtil nu har, men omvendt betyder en e-valgsmulighed, at der bliver færre undskyldninger for IKKE at stemme, især hvis tilbuddet ligner den Estiske model.

Ser man snævert på selve afstemningsproceduren vil besparelsespotentialet ligge i mindre personaleforbrug, herunder mindre diæter til folkevalgte kontrollanter, og mindre behov for omtællinger og administration. Dette potentiale må så opvejes af, om man ønsker at tilbyde løsninger, der indbærer særlige investeringer, sikre afstemningsmaskiner, særlige valgkort, procedurer omkring distribution af stemmesedler (elektronisk) og opbevaring af kvitteringer for afgivne stemmer.

Scenarier

Arbejdsudvalget for e-Valg under Teknologirådet fremlagde 3 scenarier, som workshoppen derefter behandlede ud fra 2 kriterier: Opfyldte de kravene til et sikkert og påpliudeligt e-valg, og hvilke trusler skulle scenarierne i givet fald være forberedte på.

Medens scenarie 1 gik på anvendelsen af stand-alone stemmebokse med et (forhåbentligt) brugervenligt interface, gik scenarie 2 på ideen om en valgbus, der (formodentligt som et supplement til 1) opsamlede beboere på plejehjem, hospitaler, fjerne arbejdspladser, og hvor tilforordnede kunne hjælpe med afstemningen. Scenarie 3 gik på en helt on-line løsning – enten ren internet baseret eller ved hjælp af smartphones, og opridsede perspektiver i retning af gruppepres, familiepres på hvordan den individuelle stemme skulle afgives.

Den teknologiske synsvinkel

Set ud fra en ren teknologisk synsvinkel er scenarie 1 og 2 utænkeligt i praksis; Stand alone stemmemaskiner skal initieres, distribueres, opdateres, opstilles, serviceres – og frem for alt vedligeholdes. Omkostningerne ved at tilvejebringe sådan en løsning (der i øvrigt ligner den, der blev kasseret i Holland og Irland) er eksorbitante, og i løbet af ganske få år vil maskinen sikkert minde om de stemmemaskiner, der blev brugt i Florida ved forrige amerikanske præsidentvalg, hvis nogen kan huske dem.

Det er sympatisk med en valgbus, der kører rundt til plejehjem og folk, der har besvær med at transportere sig, måske også til folk, der har problemer med at affinde sig med at stemme via en skærm og som har behov for hjælp, men ideen herom kræver en on line løsning – folk på hospitaler hører til på forskellige afstemningssteder, de kender måske ikke kandidatlisten, stemmesedlen skal distribueres ud til bussen, og afstemningen skal foregå kontrolleret og anonymt.

Det sidste scenarie er det eneste, der set fra en teknologisk, herunder også security/privacy mæssig synsvinkel har en chance for en gang på jorden. Men kun under nogle ganske bestemte forudsætninger:

I dag kan en ægtefælle 'låne' den andens NEM-ID eller digitale signatur – det er praktisk til bankopgaver – men er i sådanne tilfælde brugernes eget ansvar. Afpresning/gruppepres kan undgås, såfremt borgeren ikke får en kvittering på HVAD han har stemt, men kun AT han har stemt.

Men scenariet kan forbedres!

Idealløsningen

Man kan IKKE forestille sig, at man begynder med e-valg via en valgboks, der så gradvist forpupper sig til en tynd klient og til sidst anvender NEM-ID. Omkostningerne ved at gå via en stemmeboks er for store, og NEM-ID'en kræver stærkere autenticering hvis den foregår fra et valglokale.

Man kan heller ikke forestille sig en løsning, der med et slag lukker alle valgsteder; det vil være en tilvænningssituation for borgerne, og der vil i mange år være en rest-gruppe, der skal nurses særligt.

Den eneste løsning er derfor at tænke på et fælles Borgerservicekort: Et smart card, bygget op som det tyske kort, der kan anvendes i mange sammenhænge, hvor borgeren selv bestemmer, hvor meget man vil afsløre af sin identitet, udstyret med biometri, så man kan gennemføre 'stærk' autenticering, f.eks. ved stemmeafgivelse, men først og fremmest et kort, man er fortrolig med, som man anvender i et væld af sammenhænge – som kørekort, som sygesikringskort, som EU-legitimationskort, som pas, som valgkort. Så kan man udstyre valgstederne med standard PC'ere/tynde klienter, der er udstyret med kortlæsere til chips og bio, og som i øvrigt er koblet til fuldstændigt samme system (en privat Cloud!), der anvendes af de, der hellere vil stemme hjemmefra. Men hvis vi ikke råber vagt i gevær ender det med, at Danmark og Kroatien i 2018 er de eneste lande i EU UDEN smart cards!

Perspektiver

Teknologirådet vil i efteråret gennemføre endnu en workshop, denne gang med fokus på hvordan e-valg vil påvirke den demokratiske proces – og det bliver spændende: Det vigtige er nemlig stadig væk at gøre deltagelsen i debatten, interessen for at øge kendskabet til de politiske emner til noget, der er muligt for alle at deltage i. Det participative demokrati er en forudsætning for at nå det, som Helge Sander så i perspektivet fra Estland: At styrke demokratiet kræver mere end at afgive sin stemme og være tryg ved at den ikke er manipuleret eller bliver manipuleret. Og så er det måske spørgsmålet, om vores repræsentative demokrati på ALLE områder behøver at være '2. hånds' – om ikke der er områder, hvor den nye teknologi muliggør et mere direkte demokrati?

Men det tager vi fat på i november!

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 Public IT projects Fail – Continued

Yesterday I commented on the status for the Property Registration System and mentioned, that another major IT failure seemed to have been hiding from the public eye – namely the wreckage of the Danish Emergency Management System. Normally I don't claim to possess a crystal ball, but today the news hit the World: Under the heading: ' The Prime Minister knew that the Emergency Management System was high risc', a paper from the Ministry of Finance dated May 16 2007 documented that the Minister of Finance, the current Prime Minister knew that the Emergency Management Project, a Dkr. 2 B + project, was evaluated at high risk, 4 out of a scale 1 to 5.

This document was originally confidential, confidentiality raised in August 2007, when the contract with the consortium led by Motorola was signed. But the contract – although a major investment – did not cover the 'control room SW', which was out for tender and not signed before 2008.

This contract was won by Terma, a Danish company until then only known for it's supply of high tech military systems, radar controlled defense systems and firearms control systems for helicopters, fighters and ships. The contract value was at the time estimated to be a mere 200 – 250 mio Dkr. For the Control Room SW including 4 years of operation, as opposed to a total budget for the entire emergency management system at 2.718 Mio Dkr.

At the time of the evaluation, the Ministry of Finance could not include Terma and the contracted solution (that also included Intergraph and a couple of smaller, Danish companies) in the risk evaluation. So the reason a '4' was the result, was a combination of 4 for organizational complexity, 4 for technical solutions, 3 for vendor risk and 5 for complexity of stakeholder interest.

As a contingency plan to reduce/meet the risk, 193 Mio was set aside as a buffer, and the conclusion was, that if any of risks materialized, the consequences were thought only to impact the project plan and the budget.

At this point in time it is clear beyond any doubt, that although the control room SW contract only covered a mere 10% of the total project cost, this part of the project has failed completely, Terma's Staff for has been fired, and the department Public Safety, created for the occasion, has been dismantled. The Government Attorney is currently handling the case.

But as I mentioned in a blog, the Government Attorney is no programmer, and this will not create anything but a financial resolution of the conflict between Terma and the Government.

The secretariat set up to handle the emergency system – SINE – has been radio dead around this.

See their homepage at http://www.sikkerhedsnet.dk/om+sine.

So how can we determine what went wrong? If you look at the SINE homepage you will find a link to European Tetra-net projects that more or less all seem to have succeeded. What went wrong in Denmark? What is different and why couldn't we just adopt this seemingly uninteresting piece of technology and enable the fire brigade to talk to the police and the rescuing service to the civil defense units? There are several answers to this question:

1. Underestimation of the importance of the 'control room SW'.

2. A very complicated and partly conflicting group of stakeholders

3. A lack of a systemic overview of both tenders before call for tender

4. An steering committee consisting of gatekeepers instead of decision makers

5. Lack of understanding of the competence level of the winning company (Terma)

6. Lack of understanding of technological improvements in the emergency mgmt arena

As is clear from the international references, the Tetra net is not a very complicated technology – it has a rather small bandwidth, but in case of emergency you could deal with only limited amount of data and voice interchange. Also Motorola is known to have skills and competence in this area, but the exchange between different organizations was explicitly placed in the second call – 'control room SW' – that also covered integration with GIS (Intergraph) as well as links to all the different organizations variety of communication media – plus an integration layer to back end systems like the Central Personal Registration system, interface to local office systems, hospital exchange, and interfaces to privately operated ambulance services and in some areas also fire brigades.

The complicated mixture of stakeholders were supposed to be coordinated by the Police, that although in practice more than 80% of all cases of (day-to-day) emergency management calls do not involve the police. And the police was in the middle of a major reorganisation, where this system was just another brick in the wall. The tender was headed by the Agency of Economy, part of the ministry of Finance, and the Emergency Management organization was merged with the Ministry of Defense a few years earlier and was probably looked upon as a sort of step child here. The complication also included the above mentioned private ambulances and fire brigades, covering about 50% or more of the local Government emergency services.

The lack of systemic overview before the 2 tenders calls for a reevaluation of how and why Gartner Group, hired as a consultant company to prepare the tender, could overlook the key role of 'Control Room SW' and underplay the importance of technical interoperability between the different stakeholders and not least the level and complexity of change management to ensure the take-up of the solution by all major players.

It seemed that the steering committee probably covered the right institutions: Ministry of Justice (which includes the Police) acting as chairman, Ministry of Finance, Ministry of Defense, Ministry of Welfare, Ministry of Science and Technology, Association of Municipalities and Danish Regions Association. Until proven wrong it is my hypothesis that the steering committee meetings concentrated more on status of progress, spending of money rather than risk management and change management like acceptance and enacting of the various groups 'in the fire' literally speaking. If stakeholder committees act as gatekeepers, it is at best an advisory committee, not a steering committee. In stead the head of this group should have been a dedicated 'CZAR' with sufficient decision power to change events – if possible by changing the contract.

Lack of understanding on the proper level of competencies and vendor capabilities. Terma had never before worked in the field of Public Safety; nor had they ever participated in major SW integration tasks with administrative stakeholders – their use of standard systems was and is 'Java'. When the contract negotiations squeezed Terma, they skipped partners that could have provided the skills and muscle, that Terma obviously did not possess when the signals of crisis were raised. And because of the nature of public tenders, they were allowed by a steering committee to continue for too long.

The lack of understanding of concurrent technological development was another reason, why the course was not changed; over the last few years the terminology 'Unified Communications' and 'Collaboration Services' has been greatly improved, mainly led by the defense forces, but using standard SW components and basing communication of the Internet. To day at least 2 vendors offer SW capability for multi-platform same-time support of communication systems supporting both Tetra Net (Motorola), standard mobile communication channels as well as highly sophisticated and encrypted VPN tools for same-time video conferencing, exchange and overlay of Geographic information. ( See CISCO Solution, IBM solution )But nobody was allocated to watch this field while the hand coding of Terma progressed. This could actually have saved the project – if attention to the acceptance of the solution by all stakeholders also had been in focus.

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

Om Danmarks første computer - Af Kai Mortensen, tidl. IBM

Jeg har fra Kai Mortensen, pensioneret servicetekniker fra IBM , modtaget denne herlige beskrivelse af SASCO I - og om de første 'rigtige' computere i Danmark:

SASCO I systemet bestod grundlæggende af 2 stk IBM 1410 computere.

Disse var tredje og fjerde IBM 1410 systemer i Danmark,

og blev ikke efterfulgt af flere.

Første og anden IBM 1410 system blev installeret i 1962 hos henholdsvis Dansk Folkeforsikring på Otto Mønsteds Plads og hos den daværende Handelsbanken på Frederiksholms Kanal, begge i København.

Dansk Folkeforsikrings var den første, og blev dengang udråbt som Danmarks første computer.

Den blev hentet på IBM's fabrik i Essonnes ved Paris under megen presseopmærksomhed i en specielt luftaffjedret lastbil, som ikke var almindelige dengang, og som var overmalet med hvad dens last var, og ”Danmarks første Computer”.

Dansk Folkeforsikrings direktør fulgte lastbilen på hele turen i sin egen bil.

Begrundelsen for at kalde den for den første computer var, at den som den første kunne multiplicere og dividere direkte, og ikke blot addere og subtrahere på samme måde som tidligere regnemaskiner, og som også mekaniske regnemaskiner gjorde det.

Om begrundelsen var rigtig, skal jeg lade være usagt, men for commercielle computere passer den formentlig.

Den blev dog næsten omgående overgået af en IBM 7070 hos Datacentralen.

SASCO I systemet blev også bygget på fabrikken i Essonnes, og måtte til formålet udbygget med funktioner til at kommunikere med reservationsterminaler (agentsæt), fjernskrivere og skrivemaskineterminaler.

Begge systemer blev opstillet på fabrikken i 1963, og et større udviklings- og testarbejde på såvel hardware som software blev påbegyndt.

Software blev udviklet af vor kollega fra system engineering, Søren Brandt.

1410-enheden bestod normalt af 4 sammenbyggede skabe, hvoraf det første indeholdt strømforsyningen, og det andet hukommelsen, som kunne være på enten 40K, 80K eller 100K 8-bit tegn. Vi startede med 80, og endte med 100K.

SASCO I systemet måtte imidlertid udvides med et ekstra skab, som blev propfyldt med førnævnte specielt udviklede netværksfunktioner.

For at kunne skifte netværket mellem de to computere blev der også udviklet en speciel omskifterenhed til formålet.

På billedet øverst kan man se, hvordan elektronikken i IBM's 14xx og 70xx systemer så ud dengang. Kortene havde trykte kredsløb på bagsiden, men forbindelsen mellem kortene skete med kobbertråde, som vikledes om de pinde, man ser forneden.

På grund af disse specialiteter var vi fire serviceteknikere fra Danmark, som blev koblet på projektet i december 1963 for at lære systemet at kende, og deltage i arbejdet til det var færdigudviklet omkring maj måned 1964. Foruden undertegnede var det Per Løve, Keld Nielsen og Ole Truelsen.

Det færdige resultat blev herefter transporteret til Danmark, og installeret i Københavns Lufthavn.

På det tidligere publicerede billede af SASCO CENTREt på denne Facebook-gruppe sidder personen til højre i billedet ved betjeningskonsollen til den ene 1410, og modsat ham står konsollen til den anden 1410 med bagsiden til.

Imellem de to konsoller sidder en kollega ved en skrivemaskineterminal med ovennævnte omskifterboks overfor sig.

Længere til venstre ses en række båndstationer, hvoraf de to længst til venstre er papirbåndststioner, som kan læse såvel 5-spors som 8-spors papirbånd.

Desuden havde centret 2 stk IBM 1403 kædeprintere og 2 stk 2540 kort-læser og -huller.

Endelig havde anlægget 2 stk IBM 1301 pladehukommelser. De kom fra USA og var derfor bygget til 60 hertz strøm, så for at klare dette blev 2 stk roterende omformere installeret på loftet over maskinstuen sammen med kølemaskiner m.v.

Teknikken på disse var en videreudvikling af IBM's 305 RAMAC, og i modsætning til denne var 1301 forsynet med et læse- skrivehovede for hver pladeside som vist på fotoet til venstre herunder.

Hver 1301 kunne rumme utrolige 50 millioner 8-bits tegn.

Da udviklingen løb fra 14xx og 70xx systemerne blev IBM's 1410'ere udskiftet med Univac computere til flyreservation.

Venlig hilsen

Kai Mortensen

NB: En gruppe SAS-veteraner har lavet en hjemmeside med deres side af SASCO-historien på http:/www.g-hit.dk/historie.htm

BIOMETRICS - The Danish Perspective

To day I had the pleasure to participate in the network for Biometrics in Denmark. The network was originally established by Frederik Kortbæk, DeLoitte and others, and todays' meeting had 3 major elements, at status report from the Danish National Police on the biometric passports, a presentation on identity management by Omada, and a user report from the leading architect of the Capital Region, the organisation responsible for hospitals for 1.6 mio inhabitants in the Greater Copenhagen Area.

The representative from the Danish Police was Mrs. Lene Gisselø, a lawyer, presented the status of the bio passport. The passport is based on the EU Directive 2252/2004.

The directive is of course based on the increased focus on terrorism, and demanded the member countries to implement a 2-step strategy, first passports with photos of the card holders, which has always been the case in Denmark, and 2. step due in june 2008 to implement biometric fingerprints as part of the passport. (See the Technology Board report on Biometric Passports - where it is pointed out that also illegal immigration is supposed to be less after the bio passes are introduced. )Denmark is lagging behind the original target date, and in spite of a tender issued 2 years ago and supposed to be closed months ago, is still not signed. The tender called for multiple types of equipment to be used by the municipalities, by the foreign office's representations around the World and by the department for immigrants in Denmark. It was stated that one of the reasons for the delay is the lack of funding, as the preferred vendor was well above the allocated budget.

What wasn't mentioned was that in the meantime 20 municipalities out of the 99 already have established a local workplace to issue not only passports, but also driver's licenses, motor vehicle licenses etc. If the budget discussion drags out much longer, the wisest thing to do will probably be to drop the tender and open a new one based on the experiences with the municipalities.

Lene Gisselø presented all the security features around the Danish passport and pointed out, that even if the holders' picture and fingerprints were stored centrally during a 3-5 week period until the passport was duly delivered to the holder, there would be no centrally stored register on biometrics of the data – 'even if it would have benefitted the police'. The locally captured data is encrypted, the BAC method used to store the photo, and EAC to protect the fingerprint data. Also Lene G. discussed the enormous task of cross-certifying all passports within the European Community.

From the audience a question was raised why the Police didn't choose the 'Match on Card' method for authentication in stead of 'Match off card'. The issue here is that when the border police checks the passport, the passport officer takes a photo of the visitor, takes a digital print of the fingerprint and then let the SW on his workstation extract the data from the passport, convert to some sort of algorithm (which may vary between the countries), and then makes the comparison based on his local algorithm. This means that the data from the passport has to be extracted and at least for some time resides in another computer. The alternative method would be to have a chip residing in the passport with the capacity to perform the comparison without having to extract any data from the passport. Lene G's answer to this question was that is was what met the EU defined standard specifications. This of course raised the question if other countries in Europe were legally prevented from storing biometric data from Danish passports, and the answer to this is, that probably there is no legislation in place to prevent this. For instance UK and Netherlands have active plans to compare the extracted data with the criminal records. The representative from the Data Protection Agency, Janni Christoffersen, pointed out that although the Privacy Officers' forum, the WP29, was looking at these issues, no common agreement has been reached yet. See this excellent book on other outstanding issues regarding use of biometrics, commented buy the WP29.

The question after the presentation remains that one might wonder what will happen to the tender and the selected solution now 12 months after deadline while the World is changing and technology progressing.

The second presentation on Identity Management from OMADA corporation was an OK run down of the issues of ID management, but it clearly showed the lack of standard solutions in a Microsoft world based on Sharepoint, where Omada clearly filled a gap in providing multiple roles access management admin solutions, deploying even Kerberos in a federated security environment, but compared to the solutions offered by for instance the Tivoli portfolio and a Websphere environment, the presentation was not that ground breaking.

The 3^rd item of the day was presented by Claus Thorsen, who is the lead enterprise architect from the IT department of the Capital Region. (Region Hovedstaden). This is a merger of 3 former counties, the Island of Bornholm and the city of Copenhagen. They are responsible for the health care and the 12 public hospitals int he region, producing more than 800.000 in take patients pr. year.

Claus' topic was based on the defined need for a single sign on solution for use in the hospitals; One hospital department (Gentofte) claimed, that due to the security regulations, logging on/off, changing workstations, registration of patient data at centrally placed terminals etc. required one additional medical doctor.

Against this, the National Health Domain committee has come to the conclusion, that only 1.2 minute pr. day is waisted because of long log-in procedures.

Claus took us through all the tedious steps required to register patient data, and where he hoped that 'some day' a biometric solution would help. One example is the use of the so-called Medical Card, introduced to increase patient security, so that the doctor checks that the right patient is getting the prescribed medicine. In order to access this application, the doctor is required to use his digital signature issued by the hospital. When he has signed and logged in, he has to make an additional log in using the digital signature to access the Medical Card application. But what happens if the doctor is ill and a substitute has to do the checking? You can't have fast track issuance of official digital signatures, and the result is that the doctor's from time to time borrow each other's digital signature. And this is only one example.

The most promising solution at this stage is to use virtual desktops, so that the desktop of each doctor remains 'active' in a sort of private cloud, so that it is much faster to check in at another terminal later. The Virtual Desktop Infrastructure is one possibility, but the enormous variation in clients and PC-equipment makes is complicated and difficult to implement this at a large scale.

So the biometric solution to assist in an almost-automatic sign on, could be helpful. But so far the conclusion is that you cannot just have one biometric solution: In the operations theatre you need to wear a mask, hence you can't use face recognition. If you wear glasses, Iris recognition is a problem, and if you want to avoid congestion, fingerprint readers (and even keyboards) are doubtful. As Claus put it: The problem is, that we are users, we are many , and we are poor!

The long range solution is probably a combination of RFID active tags and biometrics, but it remains to be seen if this can be implemented in a practical way. Yet the Region intends to start a number of pilot projects, because the problem is real – the workload around log in/log out is simply too heavy – either it takes too long time, or the doctors and nurses are cheating to ensure quality of patient treatment.

To this statement Janne Christoffersen from the Data Security Agency pointed out, that the privacy legislation 'definitely has no intention to be a problem for daily operations, as it only required, that the doctors and nurses only has access to the data, that are necessary!'

'This is exactly the issue,' Claus Thorsen declared, 'For who knows what data are necessary? Take use of Antabuse! If this is an information that is not revealed to the Doctor, the patient might be seriously mistreated!' This seems to be a very central point in designing an up-to-date privacy legislation, that ensures a more holistic treatment of patients.

The next question, equally central for the discussion, is whether Claus' Region are coordination or cooperating with the other regions, and why this is not a centrally managed development program.

The representative from the Health Domain Steering Group - (Digital Health is an organisation supposed to coordinate anything within the health domain) – claimed that they weren't funded to do this, which again lead us back to the fundamental question on whether the Regions should continue inventing hot water all of them or if the Government should step in and define real areas for centralized solutions.

But a very interesting and down-to-earth real-life presentation with lots of areas where a combination of new technology and use of biometrics might be helpful.

Following this presentation, Ulrich Østergaard from CardLab presented the biometric card that they were trying to introduce in a number of countries. As can be seen from their homesite, this seems to be very promising – the card contains an active RFIOD chip, it has a fingerprint reader, which can be used by the proper owner to turn the card on, and can be equipped with various passwords, digital signatures etc. Looking forward to see some pilot projects based on this idea – and of course combined with proper ID/access management systems on the network.

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