Gå til hovedindhold
Ægte samarbejde. Bedre resultater.

Hvad kan vi lære af fejlede digitale megaprojekter?

Fra tid til anden hører vi om skandaleramte — ofte offentlige — digitale projekter. Hvilke fællestræk har projekterne, og hvad kan man gøre for at styre udenom problemerne?

Maleri af Poseidon på havet ("Poseidon farer over havet omgivet af nereider og tritoner")

Læs artiklen for at du ikke begår de samme fejl, næste gang du selv står i spidsen for et digitalt projekt, fx et redesign af dit website eller udvikling af en ny app.

26.02.2021
Læsetid: 11 minutter
Af Bjørn Axelsen

Digital konsulent,
stifter af &web

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.

Lad viden om slutbrugerne styre projektet

Værdien af et system står og falder med at slutbrugerne 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, og
  • løbende brugertests undervejs.

Den viden, som genereres om slutbrugerne, skal være styrende fra start til slut.

Når sproget ikke er i øjenhøjde

Et eksempel på, hvor galt det kan gå, finder vi i den første udgave af den digitale tinglysning i Danmark. 

Den blev udformet, så der ikke var en ejendomstype, der hed "ejerlejlighed". Juridisk set var ejerlejligheder nemlig omfattet af begrebet "enfamiliehus", og man tilstræbte overensstemmelse mellem tinglysningen og begreberne i lovgivningen.

Skærmbillede fra digital tinglysning, hvor der skal vælges enfamiliehus, hvis der er tale om ejerlejlighed.

Det ville måske have fungeret, hvis brugerne var advokater, men også ejendomsmæglere skulle kunne bruge systemet. Og problemet blev kun værre af at man lavede en "big bang" lancering af systemet fra den ene dag til den anden, helt uden tilstrækkelig adgang til support.

Havde man været klar over, hvem brugerne er, hvilke gøremål de ville have, hvilke begreber de anvender - og havde man brugertestet løsningen ordentligt, havde man nemt kunne have afværget problemet.

Dårlig brugervenlighed er dyrt

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.

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.

Lederskab som vinden blæser

Dårligt politisk lederskab kan betyde et snævert fokus på en politisk dagsorden. Inden for sundhed kan det fx være et ensidigt fokus på ventetider for kræftundersøgelse og -behandling. Kræftbehandling er selvsagt væsentligt, men en snæver dagsorden kan komme til at fortrænge en bredere og vigtigere dagsorden. Inden for sundhed er det væsentligt at medarbejderne kan arbejde effektivt, frem for at have en dagligdag med masser af spildtid. Men du hører aldrig en politiker gå til valg på at sundhedspersonale skal have mere effektive værktøjer i hverdagen.

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.

Især i politisk styrede organisationer skrider fokus ofte fra at skabe værdi for organisationen som helhed til at håndtere politiske mærkesager. Det fremavler en ledelseskultur, hvor man navigerer efter politiske vinde. Og hvor det ikke nødvendigvis er de mest kompetente ledere, der kommer til tops.

Særinteresser ødelægger helheden

Manglende overordnet retning skaber grobund for, at forskellige dele af en organisation modarbejder hinanden. Det 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: veldrevne IT-projekter tiltrækker gode medarbejdere, dårlige IT-projekter får de dygtige til at søge væk.

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.

I kommercielle projekter kan der være tale om mål for omkostninger.

I offentlige projekter er målet sjældent omsætning, men man kan opsætte mål for hvor stor en del af brugerne der er i stand til at gennemføre en række primære opgaver og hvor lang tid de bruger på det.

Definér ejerskabet entydigt

IT-projekter kræver entydigt ejerskab: det 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 - på samme måde som når bestyrelsen i en privat virksomhed er involveret i vigtige beslutninger.

Men frem for at tænke fremad, ser man desværre at nogle politikere søger at vise handlekraft i offentligheden, ved at blande sig og træffe beslutninger hen over hovedet på projektejeren. Her burde der have været et tæt og konstruktivt samarbejde. Og viser det sig at tilliden mangler, så er det mest produktive at udskifte projektlederen med en ny, som man har tillid til. Selv den dygtigste projektleder kan ikke drible et projekt igennem, uden at have opbakning oppefra.

Analysér og optimér arbejdsgange og organisation

IT-systemer understøtter måden, en organisation arbejder på. Vellykkede IT systemer bygger på gennemtænkte arbejdsprocesser.

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 hele værdikæden.

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 længst 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.

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 overordnet perspektiv med 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.