Når kunden ikke er kunden

At offentlige IT-projekter har et svært liv, er nok gået op for det fleste. Listen er lang, med prominete sager som Rejsekortet, DORA, Elektronisk Patientjournal, POLSAG, Virk.dk i spidsen for for adskillige milliarder fejlslagne ITsystemer.

Georg Strøm peger, i sin blog på Version2, på, at organiseringen af et projekt i det offentlige  er en central årsag til offentlige it-projekters kollaps:

Det betyder at projektet skal udvikle en software som passer perfekt til nogle ukendte behov, og det betyder at det på forhånd er umuligt at planlægge en tilpasning af organisationen til de begrænsninger som softwaren har. Der er nemlig ingen som ved hvor de har betydning, før den er i drift.

Udover, at det lyder som en indirekte opfordring til at det offentlige arbejder mere agilt for at kunne justere og tilpasse løbende, peger det også på at det offentlige laver IT-projekter i et vakuum.

Det er efterhånden åbenlyst, og genfortalt til bevidstløshed, at de udførlige kravspecifikationer og grundige kontrakter, som (det offentliges) ledelser har så stor forkærlighed for, kun giver dem en falsk tryghed for projektets sikkerhed – både med henblik på at nå det ønskede slutmål (produktet) og evt. juridiske battles, når ikke det sker.
Problemet er – i mine øjne – ikke om projektet er formuleret agilt eller ej (selvom det også har betydning). Det stikker dybere – helt ind i sjælen hos opdraggiveren.

Organisationens organisering som udfordring

Organiseringen af et projekt er den store udfordring. Allerede før projektet er sat i søen, er beslutningsprocesserne meget lange, og når projektet går gang, bliver de ikke kortere. Oven i den eksisterende kabale  kommer et udviklingshus af en art, typisk uden at organisationen ændrer kommandoveje og projektorganisation. (Rejsekortet adskiller sig faktisk i denne henseende, men det er en anden historie).

Jo mere vægt der lægges på agiliteten i et projekt, des vigtigere er det at sikre at produktejeren har mulighederne for at kunne handle og kender produktets og  organisationens forretningsmål i detaljer.

Resultatet af en undersøgelse om udfordringer ved agile projekter som BvHDs Nicolai Dragsted præsenterer (slide 23) viser at kundens beslutningsdygtighed og kundens egen ressourcestyring overfor leverandøren i et projekt, er de punkter hvor leverandører og kunder er mest uenige om ydelsens kvalitet.

Den klassiske projektledelse med styregrupper og afrapporteringer til ledelsen er stadigt comme ils faut. Både fordi nogen frygter andre gør noget forkert, men også fordi man ikke vil stå alene med fejlen. CMA hedder det i klassisk projektledelse: Cover My Ass. Og i en stor (og gerne hierarkisk) organisation tager det tid, når man som projektdeltager ikke vil stå alene med beslutningen og ikke tør lave fejl.

Det bliver mere markant, når det fortoner sig ud i organisationen, for hvem man egentlig laver løsningen, og projektlederen måske er yngste fuldmægtige, der endnu ikke kender organisationen og dens mål så godt, og organisationens fejlkultur ikke opfatter “Fail Fast. Fail Early” som risikostyring, med indbygget læring. Så vil man hellere gøre det, der er planlagt i kravsspecifikationen eller det man får besked på.

Lex Rejsekort

Rejsekortet løser et (i mine øjne) fiktivt problem. I stedet for at gøre takstsystemerne transparente og homogene, så man kan bruge sine klippekort i hele landet, laver man et system som pakker uoverskueligheden ind i en sort boks, hvor alle regler på magisk vis forsvinder. Man lader dernæst et teknisk system stille krav til brugernes handlinger, så man kan bruge et chipkort (endnu en tvungen opsparing) til at tjekke ind og ud fra en rejse, som er besværlige, at udføre i det flow, som udgør en rejse.

Havde man løst problemet fra brugernes (de reelle kunders) side, havde løsningen sikkert set anderledes (brugervenligt) ud, og man kunne fx. have brugt en lille del af de milliarder rejsekortet har kostet til dato, på at give alle danskere en smartphone, så de alle kunne benytte mobilbilletter. Eller en del gratis rejser i hele landet.

Hvem er kunden?

Problemet, som jeg har forsøgt at ridse op, er at forretningsmålene, projektopfyldelsen og projektets formål etc. peger mod et led højere i organisationen. Det synes ikke at pege “ned” på at skabe klar værdi for kunderne. Alle organisationer kan finde ud af at lave noget til kunderne, færre organisationer kan strække sig så vidt som at lave noget for kunderne, og de organisationer som laver noget med kunderne, kan nok tælles på en hånd.

Projektlederens “kunde” er styregruppen, andre overordnede embedsmænd og politisk foresatte, der er ansat til at vare tage Folkets interesser. Leverandørens kunde er opdraggiveren, projektlederen med bagvedliggende styregruppe og organisation. I den lange, teleskopiske organisation bliver ideen om at fokusere på at løse noget for slutbrugeren hurtigt vagere.

I offentlige projekter er der den særlige hage, at slutbrugeren, som skatteyder og bruger af samfundet, ofte både er produktets reelle kunde, og samtidig dets (ufrivillige) ejer, men ikke har mange andre kontaktmuligheder til projektet end at brokke sig (mere eller mindre konstruktivt) i medierne. Dette er tilfældet i Uni-C’s SkoleIntra, som er administrationssystem på næsten alle danske skoler, og hvor forældredelen er genstand for  hård kritik fra forældrene. (Spørgsmålet er om der overhovedet findes brugere, der er glade for systemet?). Det seneste af en længere række ihærdige forsøg på at få udviklerne i tale er en åben Ideastorm med ønsker og forbedringsforlag til forældreintra.

Konkret kendskab til de faktiske og ønskede kunder er mindst lige så vigtigt for projektledere og produktejere som et klart abstrakt, organisatorisk forretningsmål. Så man kan skabe noget kunderne kan bruge, og tager udgangspunkt i deres behov.

Hvis projekterne skal lykkedes, skal både leverandør, produktejer og projektets ejere have fokus på hvordan man løser de reelle kunders problemer, fremfor på hvordan man kan løse sit eget problem med kunderne. Som leverandør, gør man sig en stor tjeneste ved at bore dybt i hvis problemer man løser, og fokusere på at give slutkunden værdi. Og måske have den bagtanke at det offentlige projekts reelle ejer (skatteyderne) muligvis får mere værdi ud af at projektet slet ikke bliver lavet.

Som en “kedelig” bibemærkning kan man tilføje, at indgår man en K03-kontrakt om udviklingen af sit it-projekt, er man som leverandør forpligtet til at sørge for at kundens løsning giver forretningen værdi. Og det må man så gøre i henhold til de, for det offentliges vedkommende, tre lovlige forretningsmæssige behov: Effektivisering, kvalitetsløft og overensstemmelse med vedtaget international lovgivning.

PS.

Det private laver også fejl. Typisk har de private virksomheder også tykkere gulvtæpper, man kan feje mere ind under. Og der er det aktionærerne det går ud over. De har det valg, at de kan sælge aktierne når de vil, og forsøge at afsætte bestyrelsen hvert år. Borgerne skal vente 4 år.