Dette indlæg er alene udtryk for skribentens egen holdning.

Derfor bliver dårlige it-projekter ikke stoppet i tide

9. februar 2012 kl. 15:464
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Menneskelige faktorer såsom personlig involvering, ønsketænkning og frygt for nederlag er skyld i, at store it-projekter ikke bliver stoppet i tide og ender som en skandale, ligesom det skete med politiets netop skrottede POLSAG it-system til 400 mio. kr.

Hvor Bonnerup-rapporten (2001) og senere Finansministeriet (2010) i en lignende rapport pegede på blandt andet den politiske proces, stramme udbudsregler, uklare mål og fravær af business cases som centrale syndere, er der faktisk en række menneskelige faktorer, som kan være skyld i at fejlslagne projekter, fortsætter alt for længe.

Man bør nemlig kigge nærmere på den øverste ledelse og især på de mennesker, der sidder i projekternes styregrupper og stille spørgsmålet: Hvorfor stoppede de ikke projektet i tide?

Svaret kan findes i de menneskelige og psykologiske mekanismer, der træder i kraft, når man igangsætter et stort projekt. De mest udbredte menneskelige mekanismer er:

Artiklen fortsætter efter annoncen

Ønsketænkning

Når først et projekt er igangsat, og beslutningen om at allokere ressourcer til det er taget, opstår et stort ønske om at det bliver en succes. Og når det begynder at gå galt kan det forvandle sig til ønsketænkning.

Personlig involvering

Når et projekt startes i en virksomhed, kan det være svært at se objektivt på projektet, fordi man allerede har så meget viden. Man kunne kalde det ”Indsigtens forbandelse”. Den personlige involvering i virksomhedens dagligdag kan skygge for et objektivt syn på et projekt. Ofte er de eneste eksterne styregruppemedlemmer fra leverandøren, som sjældent har et ønske om at stoppe et projekt.

Artiklen fortsætter efter annoncen

Konsistens

Videnskabelige undersøgelser har vist at ønsket om personlig konsistens er en meget stærk drivkraft for hvordan vi træffer beslutninger. Har vi én gang sagt ja til et projekt, ønsker vi, ifølge videnskaben, at være konsistente med vores tidligere beslutning.

Ikke-professionelle styregrupper

Hvis ”professionel” betyder at man har sit indtægtsgrundlag fra den pågældende aktivitet, er de fleste styregrupper uprofessionelle. I rigtig mange offentlige og private firmaer er store projekter et særsyn, og ledelsen har ikke den nødvendige erfaring i at håndtere dem, eller se faldgruberne. Også selvom de er meget dygtige ledere i andre ledelsesroller.

Frygt for at realisere et tab

Denne tendens er kendt fra private investorer, der ikke ønsker at sælge aktier med tab under devisen: ”Så længe de ikke er solgt, er tabet kun på papiret”. I samme øjeblik man sælger aktierne, realiseres tabet. I projekter kan der være samme tendens: Så længe projektet kører, er der stadig chancen for at få en succes, og tabet ikke et faktum.

Hver for sig kan disse effekter være uheldige, men de har tendens til at optræde samtidigt. Og så kan de i yderste konsekvens betyde at faresignaler overses og projekter får lov at køre langt længere end de burde.

Kunsten består i at afholde sig fra de åbenlyst risikofyldte projekter, hvor den potentielle gevinst ikke står mål med risikoen, og at sikre god ledelsesmæssig bevågenhed på de projekter der startes.

Den største fare ved et kuldsejlet projekt som POLSAG er dog ikke, at fremtidige lignende projekter kuldsejler, men at der skabes en frygt for at sætte nye initiativer i gang.

Hvad kan man gøre?

Men er der en vej til at undgå det? Kan man reelt gøre noget?

For at professionalisere er der i statsligt regi gjort meget det sidste år med en fælles projektmodel, en standardiseret risikovurdering, og et it-projektr gransker store komplekse projekter.t sidste år, med en fælles projektmodel, en risiko kører mange mellem et projekt. i ydersteåd, der gransker store komplekse projekter.

Men et stort projekt er i størrelse og kompleksitet som en mellemstor virksomhed. Men alligevel kører mange af disse projekter med noget der svarer til de berygtede ”tantebestyrelser”, dvs. styregrupper besat med mennesker, der enten har en personlig interesse i projektet eller ikke har erfaring med komplekse projekter. Og ofte en kombination.

En oplagt løsning kunne være at besætte en eller flere pladser i en styregruppe med professionelle projekt- og programfolk, uanset om disse kommer fra andre lignende virksomheder eller ernærer sig som professionelle styregruppemedlemmer.

Det vil give andre perspektiver på projekterne og tilføre nye og mere professionelle kompetencer til styregrupperne.

4 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
10. februar 2012 kl. 10:07

I al det skriveri, der findes, om det nye store fejlslagne projekt, POLSAG, mangler der tydeligvis fokus på en bestemt faggruppe: programmørerne.

Når jeg leder efter en fællesnævner for udvikling af store systemer der enten er fejlet eller ikke rigtigt er lykkedes, så er det typisk at rigtigt mange har været alt for uvidende om hvordan et IT-program ser ud indvendigt.

Det ER nødvendigt med styregrupper og det ER nødvendigt med ledelse, for det er limen der binder programmørerne sammen på større systemer. Men den ensidige fokus på "manglende business-cases", "for lange kravspecifikationer" og "umodne kunder" - viser at vi har glemt, at de der skal udføre det faktiske arbejde ikke må være fabriksarbejdslignende væsener. Programmører skal være genier på deres felt, og samtidigt skal de besidde evnen til at kunne forstå den forretning de implementerer.

I "den danske IT Branche's" higen efter at gøre IT udvikling til et fabriks projekt, har man overset hvad der skal til for at skabe nyt: mere eller mindre bindegale mennesker der sætter hele deres liv til side for at skabe ting ingen andre havde troet muligt. Disse mennesker kan man ikke købe sig til i lavtløns områder ved blot at købe tifold af selvudnævnte programmører, og så sige: "lav et Tinglysningssystem der styrer danske boligforhold".

For mange år siden (1996) udtalte en programmør, der var blevet sat til at afskaffe sit eget arbejde, ved at lave en kravspecifikation til langt billigere Indiske udviklere: "Når jeg har beskrevet det så detaljeret som det i sidste ende var nødvendigt...ja så havde jeg allerede skrevet programmet selv". Den sætning er virkeligt ubehagelig. Den kan opfattes på to måder: 1) Han ville blot beholde sit job eller 2) Han forudsagde 15 års fejlslagen systemudvikling og masser af penge ud af vinduet, inklusive spildte talenter der aldrig ville komme til at udvikle deres fulde potentiale.

Begge opfattelser viste sig at være rigtigt.....

Bundlinien af eks. POLSAG, Tinglysning, Rejsekortet, IC4 Software, Windows Longhorn, Amanda sat op imod f.eks. Mac OS X, Windows 7, Navision, PC Plus, WordPerfect, MS Office, Skype, Google, YouTube - set fra en programmørs synspunkt er, at det er de dygtige programmører med tilhørende blændende ledere der lykkes med at få et nyt system sat godt i søen.

Succes historier er meget sjældent startet med et regeringsapparat, eller en velbjærget virksomhed, der ikke rigtigt kan finde på andet end at beskæftige sig selv. Succes kommer altid ud af passion, arbejdsomhed og dygtighed - hvor end den måtte optræde. Og inden for IT starter det med en håndfyld dygtige programmører.

Peter J. Bruunwww.cobolprogrammer.dk

4
10. februar 2012 kl. 12:38

Hej Peter

Ja jeg finder det meget interessant hvordan programmører idag ses som fabriksarbejdere, der skal lave noget kodearbejde man nærmest kunne sætte en abe til at gøre - en programmør er en programmør uanset om han er fra Danmark, Indien, Pakistan eller Vietnam lader til at være holdningen og uagtet om han har 2 eller 10 års erhvervserfaring - man kan bare hyre og udskifte programmører efer behov. Det "intelligente" arbejde ved vi jo alle at man så passende kan lave her i Danmark (dvs. overordnet arkitektur, design og ledelse) - man glemmer blot at der er intet af dette arbejde der fører til noget håndgribeligt, hvis det ikke er for programmørene.

Måske det er på tide at det gik op for nogen at verden ikke helt er skruet sådan sammen og at en dygtig udvikler der har forståelse for hele stack'en (arkitektur, analyse, design, programmering, ...) uden problemer kan gøre det bedre end 10 eller 20 middelmådige udviklere der slavisk implementerer hvad de har fået besked på oppefra - hvilket formentlig er et ret unikt element for vores branche, som meget få lader til at anerkende (ihvertfald hvis man kigger på lønningerne).

Denne insisteren på at opbygge en pyramide over ansvarsområder, hvor sidste led helst skal være i kategorien slavearbejde passer meget dårligt på IT udvikling - men vi vil så gerne gøre udvikling til en ingeniør-diciplin at vi glemmer hvad det er vi beskæftiger os med.

3
10. februar 2012 kl. 11:02

Hej Peter, jeg kunne ikke være mere enig, med dig omkring sammensætningen, men jeg forsøgte blot at forholde mig til blog'en omkring ledelsen af projekterne. De fleste ved at hvis ikke teamet der skal udfører opgaven indeholder de rigtige kompetencer (udviklere, arkitekter, forretningsudviklere, testere, etc), i min optik er projektets leverance ikke bedre end det svageste led og den sammensætning af roller der er besat i projektet.

1
9. februar 2012 kl. 23:12

Godt indlœg og ja der må sidde nogle SG i øjeblikket og vurdere deres projekters ve og vel. Men spøgsmålet er om de vurdere projektets grundlag, businesscase og exitkriterier...

Jeg tror de fleste af os der følger med i den offentlige projektportefølje tager os til hovedet hver gang vi ser et af disse projekter køre i hegnet, og så reflekterer vi jo så også med den viden eller indsigt - eller mangle på samme over hvilke mekanismer der har påvirket projektet. Det er hœvet over en hver tvivl at det starter med styregruppen, den er ultimativt ansvarlig for at projektets økonomi og businesscase realiseres. Det er også SG der overordnet har ansvaret for projektets success.

Jeg er meget enig med dig i, at der kan gøres meget for at uddanne SG medlemmer, og indenfor det offentlige burde man nok sikre at alle projekter over en hvis vœrdi havde en ekstern QA funktion tilknyttet som kunne udfordre SG på businesscasen og den generelle TCO, i og med mange af disse store projekter har det med at strœkke sig over mange år, jamen så er businesscasen og ikke mindst krav og forudsœtninger voldsomt under pres allerede på det tidspunkt hvor man begynder at udvikle, og dermed er der allerede sket meget i "kundens" miljø fra dengang de oprindelige krav blev defineret.

MEN det er projektlederen/programlederen der skal sikre gennem professionel og kompetent ledelse af sit projekt at SG altid er opdateret på tilstanden af businesscasen, samt de øvrige successkriterier der er for projektet - som er beskrevet i projektgrundlag eller charteret bliver evalueret og såfremt der er afvigelser skal projektlederen sikre at SG er bekendt med konsekvensen. SG medlemmer har det med at vœre en flygtig størrelse, hvorimod man bedre kan sikre sig at en professionel projektleder er der i projektets levetid.

Det er i min optik projektlederen der har ansvaret for at SG er bekendt og opdateret på forandringerne i projektets miljø, det interne som det eksterne miljø. Jeg mener at den projektmetode det offentlige har svœrget til i mange år understøtter denne rapportering. Det er også projektlederen der arbejder ud fra det grundlag der er udstukket af SG, og dermed har PL fået nogle faste rammer som denne skal agere indenfor. Jeg har set mange eksempler på at PL også har haft samme symptomer som du diagnosticere SG med, og det gør det jo blot endnu svœrere at anbefale at projekterne stoppes.

Dette gœlder projekter som udføres ud fra en traditionel vandfaldsmodel eller agile projekter - der er ingen forskel i opdraget. Så ja det offentlige har i høj grad en udfordring i at få success i deres projekter, og det starter med en professionel organisation, en dedikeret indsats for udarbejdelse og godkendelse af projektgrundlaget og projektets succeskriterier, samt nogle meget konkrete exitkriterier der løbende skal evalueres. Jeg ved selv hvor svœrt det kan vœre at anbefale et stop, men hvis ikke man tager diskussionen om projektets validitet så gør man sin organisation en bjørnetjeneste og man udnytter ikke det mandat man har som projektleder (nu er der sgu nok nogen der giver mig et gok)...

Det tragiske for de offentlige projekter er at alle projekter over en hvis sum bliver evalueret af en af styrelserne for undgå budgetoverskridelser - men det er tilsyneladende meget høje tœrskler før det kommer en egentlig konsekvens... men det er jo en helt anden snak :-)

En ting jeg kunne ønske for os der betragter denne nyeste fiasko af dimensioner var indsigt dokumentionen, altså alle de referater fra SG møder og projektrapporter etc hvor al den herlige viden ligger. Jeg ville gerne have mulighed for at se deres erfaringslog og ikke mindst lessons learned dokumentet. Det kunne vi nok lœre en del af til nœste gang, og hvis der er nogle dygtige og professionelle projektledere i det offentlige så beder de om at lœse lessons learned fra Polsag, Amanda, EPJ etc etc etc der er jo nok af erfaringer - som kan bidrage til en bedre ledelse af det projekt der skal startes op.