Av Tore Audun Høie
Dette avsnittet ble offentliggjort i bladet Prosjektledelse 2/2020
Ingeniøren 21. februar 2018:
Projektarbejde hjælper
‘Evnen til at arbejde i teams’ vurderes som den næstvigtigste kompetence blandt de nyuddannede. Det lærer de unge allerede i studietiden, og derfor skal de skræve over en betydeligt smallere kløft end nyuddannede i mange andre lande.
»Vi er lidt specielle, fordi der er meget projektarbejde på danske ingeniørstudier, og det klæder vores ingeniørstuderende bedre på end f.eks. britiske og amerikanske studerende,« siger hun (Anette Kolmos, Aalborg Universitet).
Den projektorienterede undervisning ruster de unge langt bedre til den virkelighed, de møder. De lærer at igangsætte en proces og føre den til ende. De forstår, at der skal andre fagligheder ind over, hvis man skal have succes med et produkt, og de kan se nødvendigheden af arbejdsdeling.
»I den forstand er de meget mere parate til at gå ind i en virksomhed. Teamwork giver dem en forståelse for, hvordan man arbejder i den virkelige verden,« fastslår Anette Kolmos.
Prosjektledelse var et glansnummer i mine første år i jobb, til sammen 5 vellykkede prosjekter hvis jeg regner med Optima.
Langt senere ble prosjektledelse en egen profesjon med sertifiseringer og mange bøker, men ble prosjektledelsen egentlig bedre?
En kommentar til status for dagens prosjektledelse innen data begrenset til offentlige prosjekter kommer fra professor ved det danske IT-universitetet Søren Lauesen:
Jeg har sammen med Rigsrevisionen og forskellige kolleger haft lejlighed til at finde årsagerne i flere store offentlige IT-projekter som “gik galt” på en eller anden måde, bl.a. Elektronisk Tinglysning (eTL), Rejsekortet (RK), Poliets sagsbehandlingssystem (PolSag), Skats gældsinddrivelse (EFI) og Sundhedsplatformen (EPIC).
Hvad vil det sige at et projekt går galt? Blandt de 5 er det kun PolSag som aldrig blev taget i brug. I luftfarten definerer man en katastrofe som en situation hvor der skete væsentlig skade på personer og/eller materiel.
På samme måde kan man definere en IT-katastrofe som et projekt der har væsentlige “skader” på leveringstid og/eller kundens udgifter, den forretningsmæssige værdi, brugertilfredsheden, leverandørens udgifter, eller hvor det aldrig blev afklaret om projektet var realiserbart.
De 5 projekter har meget forskellige skadesmønstre. Fx har EPIC (som det eneste) hverken skade på tid eller kundens udgifter. Til gengæld er der store skader på brugertilfredsheden. For PolSag og EFI blev det aldrig afklaret om de kunne realiseres. Dog kørte halvdelen af EFI i flere år.
Hvorfor skete disse skader så? Vi fundet frem til 36 skadesårsager. Hvert projekt er ramt af mellem 13 og 17 af årsagerne. De optræder i forskellige mønstre i de 5 projekter.
Lad os se på nogle af de hyppige årsager i de 5 projekter:
Årsag A1: Kunden identificerer ikke brugernes behov (ramte alle 5 projekter). Behovene burde fremgå af den kravspecifikation kunden og leverandøren skriver under på, men det gør de ikke. Man kan fx ikke se hvem der skal bruge det nye system, hvornår og til hvad.
Ofte har projektledelsen aldrig stillet sig selv det spørgsmål. I stedet beskriver man – ofte i detaljer – hvad systemet skal gøre. Det er ikke så smart, for leverandøren har måske en bedre løsning, der gør tingene på en anden måde end den kunden har beskrevet.
En grunn som ikke er nevnt ovenfor og ser ut til å ligge utenfor horisonten er stakeholderanalyse. Den ville antakeligvis avslørt svakheter ved alle prosjektene.
Nevnt allerede er det britiske NPfIT med tosifret milliardtap – i pund. Det var til helseadministrasjon, men man tok seg ikke tid til å spørre legene hva de hadde behov for.
En annen metode nevnt i denne boken er å utvikle enkle prototyper, det ville trolig avslørt svakheter ved alle de fem danske prosjektene.
Mer generelt for et stort og viktig dataprosjekt behøves omhyggelig og metodisk planlegging. Dette var tidligere del av datautdannelsen, men det virker som planlegging er fortrengt av krav til tid og økonomi.
Positivt virker norsk offentlig prosjektledelse bedre enn de danske erfaringene. Dessverre går Epic igjen i Norge også, og dårlig stakeholderstyring. Men Norge har hatt fordel av Nordsjøen med mange store prosjekter og formalisert planlegging. Muligens har også noe av Knut Heiers ekspertise slått igjennom.
I Norges prosjekt for folkeregistret er stakeholderstyring formelt lagt inn, og er omfattende. Din premiere i registeret er som baby, det er ønskelig at babyen blir lagt inn så raskt som mulig, men dette må avtales på en ryddig måte med fagfolk som jordmor og gynekolog. Se hvor langt stakeholderbegrepet går!
I motsatt ende er død, den døde bør tilsvarende ut av folkeregistret så raskt som mulig, men kun når vedkommende offisielt er erklært død. Muligens har man egen rutine for Lazaruser. Det satses også på rutiner for å informere stakeholdere, for eksempel offentlige myndigheter og kanskje banker. Det måtte jeg gjøre for min kone Marit, og det var ikke en velkommen oppgave i sorgen. Alle måtte få kopi av dødsattesten, noe som gjorde prosedyren mer komplisert. Flere år senere hadde ikke Danmark registrert at hun var død, og hennes lønn ble lagt til min i beregninger.
Noe som antakelig hjalp er at Skattevesenet er representert i styringsgruppen for folkeregisterutviklingen ved sin sjef, Hans Christian Holte. Han har kjørt flere vellykkede prosjekter for Skatt, og blitt forfremmet av den grunn. Forfremmelse på grunn av oppnådde resultater virker sjeldent i offentlig forvaltning, men Holte er altså et gledelig unntak.
I Danmark virker det som de positive erfaringene fra bankprosjektet jeg var med på ikke er snappet opp, nesten utrolig, men man manglet kanskje en koordineringsinstans som Norsk Forening for Prosjektledelse, startet av Knut Heier.