Hvad kan vi lære af kuldsejlede offentlige IT-projekter?

Hvorfor hører man fra tid til anden om skandaleramte offentlige IT projekter? Er der fællestræk - nogle farer, man skal forstå at navigere uden om?

Høj pris er ikke en garanti for kvalitet

I 2012 ramte Politiets sagsbehandlingssystem Polsag jorden med et brag og efterlod en regning på en halv milliard. Systemet nåede ikke længere end til pilottest på Bornholm, før det blev skrottet.

Der er mange grunde til, at IT-projekter fejler. Vi hører især om de offentlige fiaskoer, fordi private virksomheder bedre kan styre uden om offentlighedens søgelys, når et projekt udvikler sig til en katastrofe, og at de er hurtigere til at lukke skandaleprojekter ned. Men de fleste fejlmuligheder i et IT-projekt er uafhængige af, om projektet er offentligt eller privat finansieret.

Organisationen skal arbejde efter et fælles overordnet mål

I en veldrevet organisation forstår medarbejderne, at de skal skabe værdi for kunderne/borgerne. Medarbejdere og ledere har en naturlig fornemmelse for betydningen af at arbejde effektivt og løfte i flok. Det fokus er nødvendigt for at skabe succesfulde IT-løsninger.

Dårligt politisk lederskab kan betyde kortsigtet fokus på en politisk dagsorden. Inden for sundhed kan det fx være et ensidigt fokus på ventetider for kræftundersøgelse og -behandling. Det er selvsagt væsentligt, men en snæver dagsorden må ikke få lov at være det eneste, som er i fokus.

Strømlinede arbejdsgange, gode IT værktøjer og velfungerende intern kommunikation skaber langt større værdi, end når en organisation forsøger at springe efter en enkelt mærkesag. Men det kan være svært at forstå for den almindelige borger, og kan derfor også have mindre politisk fokus. Fokus skrider fra at skabe værdi til at håndtere politiske mærkesager. Det fremavler en lederkultur, hvor man navigerer efter politiske vinde. Og hvor det ikke nødvendigvis er de mest kompetente ledere, der kommer til tops.

Manglende overordnet retning skaber grobund for, at forskellige dele af en organisation modarbejder hinanden. Den type adfærd har en tendens til at forgifte IT-projekter, fordi systemet skal tage højde for mange særinteresser.

En særinteresse kan fx være overdrevet håndtering af rettigheder. Hvis forskellige grupperinger i en organisation er mistroiske over for hinanden, kan det afstedkomme et unødvendigt og kontraproduktivt kompleks af rettigheder, som har til formål at styre præcis, hvem der kan tilgå, hvem der kan redigere, hvem der kan oprette, hvem der kan slette forskellige typer af data. I nogle sammenhænge kan den slags være berettiget, i andre sammenhænge dækker det over mangel på tillid og en dårligt fungerende organisation.

I sig selv er det ikke noget problem, at et system har avanceret rettighedsstyring. Problemet er summen af de detaljerede krav, som på forskellig vis skal tilfredsstille spredte ønsker rundt omkring i en organisation. Tilsammen får listen af krav projektets kompleksitet til at eksplodere. Projektet - der skulle have været en Ferrari - bliver til et knudret garnnøgle.

De bedste IT løsninger bliver til i et miljø, som formår at tiltrække de bedste hjerner. Ofte tiltrækkes disse mennesker af at være i en veldreven organisation/virksomhed, det er derfor en selvforstærkende proces.

Gør målet konkret

Målet med projektet skal gøres konkret. Sørg for at målet er skrevet ned og let forståeligt. Om muligt skal projektets succes være målbar.

Definér ejerskabet entydigt

IT-projekter kræver entydigt ejerskab: et skal være klart, hvem der sidder for bordenden. Er der tvivl om ejerskabet, kommer der også tvivl om projektets retning.

Offentlige IT-projekter bliver ofte sat i søen af politikere - ligesom når bestyrelsen i en privat virksomhed er involveret i vigtige beslutninger. Men nogle politikere vil gerne vise handlekraft i offentligheden, og blander sig ved at træffe beslutninger hen over hovedet på projektlederen. Her burde der være et tæt og konstruktivt samarbejde. Ud over at beslutningerne kan være uheldige, har de også den afledte effekt, at stillingen som chef for projektet bliver mindre attraktiv, hvis man får stækket sine handlemuligheder.

Analysér og optimér de interne arbejdsgange

IT-systemer understøtter arbejdsgange i en organisation. Vellykkede IT systemer bygger på gennemtænkte arbejdsgange. Det kan forekomme banalt, men her går det ofte galt.

Manglende analyse af eksisterende arbejdsgange - og manglende ledelsesmæssig vilje til at forenkle og forbedre arbejdsgangene internt - kan føre til, at man tilpasser systemerne til gamle arbejdsgange i stedet for at optimere dem.

Det er ikke altid populært at pille ved arbejdsgangene i en organisation. Pludselig får nogle medarbejdergrupper adgang til informationer, de ikke tidligere havde adgang til, og kan nu pludselig stille kritiske spørgsmål. Måske bliver nogle menneskers opgaver overflødige. Måske giver det mening at flytte ansvar fra en personalegruppe til en anden.

I stedet for at adressere disse udfordringer - som ofte er vanskelige - kan det forekomme nemmere at rette fokus mod systemerne. Her kan man komme til at bilde sig selv ind, at med ny teknologi bliver det hele nemmere. Men ofte bliver den nye teknologi et alibi for ikke at forholde sig til de svære ting i en organisation.

Bygger man et IT-system omkring besværlige og forældede interne processer, ender man med et babelstårn, hvor systemet skal kunne håndtere alle mulige specielle ønsker.

For en IT leverandør er komplekse ønsker en udfordring og forretningsmulighed. Så leverandøren siger typisk bare ja og skruer prisen op.

Systemer, der på den måde er blevet unødigt komplekse, har ofte problemer med langsomme responstider og at det er dyrt og tungt at videreudvikle dem.

I stedet skal man kunne vælge fra. Tænk fx på Rejsekortet. Her er der forskellige takstsystemer for Vestdanmark, Østdanmark og rejser over Storebælt. For menigmand er takstsystemerne umulige at gennemskue. Et mere enkelt system kunne være at have bare ét prissystem baseret på afstanden mellem rejsens start- og slutpunkt. Der er klart, at en sådan prismodel også har sine ulemper. Men her er det netop nødvendigt at stå fast og acceptere rimelige fravalg for at sikre et enkelt system.

Arbejd iterativt

Ofte starter man et IT-projekt med brug af kravspecifikationer, der søger at indtænke alle ønsker til systemet. Det er et godt udgangspunkt, men kravspecifikation er et øjebliksbillede, som er bundet til, hvordan en organisation ser sine ønsker på et givent tidspunkt. Men organisationer flytter sig, medarbejderne får nye erfaringer, der kommer ny teknologi til, og der viser sig mere enkle måder at gøre tingene på.

En effektiv fremgangsmåde er derfor at arbejde iterativt, hvor man opbygger erfaringer, og gradvist raffinerer teknikken og måden, man udnytter teknikken.

Dermed kan man tidligt finde ud af, hvad der virker og ikke virker. Så brænder man ikke 500 mio. af på noget, der senere viser sig at blive en dundrende fiasko.

For en politiker er det en angstprovokerende fremgangsmåde. Hvis projektet går galt, vil fadæsen klæbe til både leverandør og kunde - og dermed også til politikerne. Med en grundig kravspecifikation og en kuldsejlet systemudvikling er det nemt for politikerne at vaske hænder og placere ansvaret hos leverandøren.

At systemet kan specificeres i en meget lang kravspecifikation og at programmørerne kan kode det, er desværre langt fra ensbetydende med at det bliver brugervenligt og velfungerende.

Så pas på med de tunge kravspecifikationer. Del projekterne op. Start med et pilotprojekt: et proof of concept. Og start med det mest vanskelige.

Læg budget, men forstå, at det kan gå op og ned. Vær parat til at skifte leverandør hvis der ikke bliver leveret.

Fx er Rejsekortet forældet, idet en smartphone er et mere velegnet og mere fleksibelt værktøj til at håndtere billetter - i hvert fald for de fleste rejsende. Den erkendelse kunne have givet billigere billetter til gavn for alle. Her hjælper det ikke, at den oprindelige kontrakt havde intet mindre end ca. 2200 funktionskrav til Rejsekortet.

IT-arkitekturen skal også være agil. Den skal anspore til at nye ideer og initiativer efterfølgende kan bygges på via gennemtænkte grænseflader og testmuligheder.

Involvér brugerne

Værdien af et system står og falder med at brugerne kan bruge det - og endnu bedre: hvis de tilmed synes om at bruge det.

God brugervenlighed og vellykket brugeroplevelse (UX), fordrer at brugerne er med i processen hele vejen, fx gennem:

  • indledende brugerresearch,
  • tidlige tests af mock-ups og wireframes,
  • løbende brugertests undervejs, og
  • løbende undersøgelse af brugernes behov.

Kommunikationen med brugerne og andre interessenter skal tilrettelægges med en gennemtænkt kommunikationsplan.

Ofte spares der på fx brugertest, idet økonomien er under pres, og det vurderes som “nice to have”, mens funktionaliteten er “need to have”. Set i et helhedsperspektiv holder det argument ikke. Dårlig brugervenlighed koster penge, fx i form af dårligere medarbejdereffektivitet. Men udgiften til den dårligere effektivitet kan lande uden for projektets økonomi. Endnu en gang understreger det betydningen af at agere helhedsorienteret.

Tænk systemet i sammenhæng med andre systemer

Komplekse IT-systemer snakker ofte sammen med andre systemer. De skal fx kunne udveksle data for at undgå manuelt arbejde med at opdatere data i flere forskellige systemer.

Jo flere systemer, som skal snakke sammen, des tungere kan systemudviklingen blive på de enkelte systemer. Uden overordnet styring kan integrationen mellem de forskellige systemer udvikle sig til et rodet, kostbart og ineffektivt morads.

I eksemplet med Polsag var der fx overdrevent ressourcetunge integrationer til andre systemer, fx til et dokumenthåndteringssystem.

Styr derfor IT-projekterne fra et ovorordnet perspektiv gennem sunde og gennemtænkte IT principper.

Følg standarder og brug eksisterende løsninger

Komplicerede problemstillinger kan ofte løses let og ubesværet ved at udnytte eksisterende standarder og bygge videre på eksisterende løsninger.

Et eksempel er WAYF, som binder studerende sammen med udbydere af forskellige webtilbud, fx adgang til akademiske databaser. De studerende skal dermed kun huske ét login, og de forskellige serviceudbydere kan nemt give fx alle studerende på et universitet adgang til at logge på deres site.

Teknisk set er det en ganske krævende systemintegration at bygge fra grunden. Men WAYF bygger på en eksisterende standard, SAML2, og kan dermed trække på eksisterende software og erfaringer. Det har både betydet at WAYF er billigt i forhold til kompleksiteten af den service, som systemet leverer, og at brugerne har været forskånet for større tekniske vanskeligheder.

Tænk i performance fra start til slut

Komplekse systemer får hurtigt langsomme responstider. Det betyder spildtid og irritation for brugerne. Og sådan kan det hurtigt gå, hvis man ikke tilrettelægger teknikken rigtigt.

Det kuldsejlede Polsag havde massive performanceproblemer (bl.a. dokumenteret i en rapport fra Globeteam fra 2012) grundet en ineffektiv og ikke-skalerbar IT-arkitektur.

For at undgå den type problemer skal man:

  • fra starten af projektet specificere, hvad systemets maksimale responstider må være,
  • opsætte testcases, hvor man løbende kan validere responstiden, ikke bare i et udviklingsmiljø, men med en realistisk brugerbelastning i et realistisk driftssetup,
  • gennem hele projektet have adgang til de fornødne specialistkompetencer i forhold til performanceoptimering, og
  • have et samarbejde mellem ledelse og performancespecialist.

Undgå sikkerhedsmæssige stopklodser

IT sikkerhed kan sætte begrænsninger ift. at få systemer til at snakke sammen. Og dermed dræbe decentralt initiativ. Lad det derfor være nemt og gennemskueligt hvad kriterierne er for at åbne op for adgangen ind i systemet.

Ofte ender sikkerhedsforhold med at være et argument for at kun en enkelt leverandør kan udvikle op imod systemet. Men sikkerheden skal ikke ligge i at systemet er tillukket, sikkerheden skal ligge i at der er gennemtænkte kriterier og procedurer for adgangen til systemet.

Dermed åbnes der op for initiativ og konkurrence. Eksempelvis kan nogle systemer nyde godt af at der udvikles en eller flere apps op imod systemet. Og måske er app-udvikling ikke den stærkeste side hos den primære systemleverandør. Men ved at gøre systemet åbent, kan der opstå nye og værdiskabende mulighed.

Kræv at alle tager medansvar

Nogle projekter ender desværre med fiasko. Gradvist går det op for nøglepersonerne i projektet, at musikken ikke spiller. Man tror ikke på projektet, og kan ikke se, hvordan projektet kan komme tilbage på sporet.

Lige så stille begynder medarbejderne at sive, og politikerne lægger luft til projektet. Ingen vil være ansvarlige for den kommende fiasko. Til sidst fyrer man projektlederen, selvom projektlederen måske først er kommet til efter at kimen til blev lagt til et fiaskoprojekt.

Når et projekt begynder at gå skævt, handler det om at få projektet på skinner, lægge en revideret projektplan og få nye, kompetente folk ind i projektet. Men skal det lykkes, skal dem der er i front for projektet - politikerne - turde stå på mål for projektet. Er de på vej til håndvasken for at vaske hænder og fralægge sig ansvaret, er chancen for succes ikke-eksisterende. Det kræver kompetente politikere, som tænker langsigtet.