Det kommer næppe som en overraskelse for nogen at der er en grad af stigma forbundet med offentlige IT projekter. En stor del af dette stigma skyldes den dårlige omtale af offentlige IT projekter i medierne, hvor der stort set sættes lighedstegn mellem ”offentlig IT projekt” og ”fiasko”. Jeg er af den holdning at dette stigma er i nogen grad ufortjent, og jeg vil i fremtidige indlæg vil komme ind på hvorfor jeg mener det, men i første omgang vil jeg hellere fokusere på et relateret emne, nemlig hvad der gør at man kan betragte et projekt som succesfuldt.
Mit postulat er at mens det ofte er nemt at se at et projekt er en fiasko, så er det svært at vurdere om et projekt har været succesfuld før noget tid efter det er afsluttet.
Klassisk set, kigger man på 3 ting i forhold til om et projekt er succesfuld:
- Tid – dette kan enten være i form af tidsforbrug eller leverancedato.
- Pris – kostede projektet det som man forventede, eller løb prisen op.
- Scope – indeholdte projektet det forventede.
Man kigger selvfølgelig på disse 3 ting kombineret: fik man det aftale scope på det aftale tidspunkt til den aftalte pris.
Der er næppe nogle som ikke er klar over at det er en problematisk måde at definere succes for et projekt. Hele den agile bølge er kommet, fordi det er umådeligt svært at definere scope før man går i gang med den egentlige implementering, og dermed er det også svært at aftale et tidspunkt og en pris.
Et af de mest kendte fiaskoer indenfor IT projekter er Amanda projektet, hvor et af kritikpunkterne var det store antal af sider som sagsbehandlerne skulle igennem for at foretage deres registreringer. Jeg har snakket med folk som var involveret i projektet dengang, og de indrømmer alle at der var problemer med projektet, men at antallet af sider var specifikt som følge af de krav som indgik i udbuddet, og derfor var ”as specified”, eller med andre ord, var en del af det definerede scope som der skulle afleveres.
Så, med andre ord, bør vi se efter en anden måde at evaluere projekter på.
En logisk måde er at se på hvorvidt projekter giver værdi til organisationen som den udspringer af, og det kan man nemt gøre for visse typer af projekter, men ordet ”værdi” er svært at definere meningsfuldt så det virker på tværs af alle projekter. I nogle projekter vil værdien kunne måles som organisationens forøget overskud minus udgifterne til implementeringen, mens værdien i andre typer af organisationer skal måles i medarbejdertilfredshed, svartid, besparelser eller noget helt 3.
I det offentlige, handler det ofte om hvorvidt myndighederne er i stand til at servicere borgernes behov i overensstemmelse med loven.
Mere lavpraktisk, og nok den målestok som jeg vil foreslå, er at man for hvert projekt definere hvad succeskriterierne er, før projektet påbegyndes. Disse succeskriterier skal være vel defineret og være målbare – med andre ord, skal det være helt klart hvorvidt de er opnået eller ej. Gerne med en tidsramme for hvornår de skal være opnået.
Mange projekter gør allerede dette i dag, men der er skræmmende mange projekter som sættes i søen uden at nogen har foretaget denne forholdsvis essentielle øvelse. Jeg er af den opfattelse at det bør vi, som branche, ændre på, hvis vi skal blive bedre til at lave projekter – uanset om det er indenfor det offentlige eller det private.
Hvad siger I? Er dette den rigtige måde at vurdere om et projekt er succesfuldt? Eller har I nogle ideer til hvordan man burde gøre det i stedet?