Opråb til it-branchen: Kun hvert femte projekt kan betale sig

Projektledere aner ofte ikke, om deres it-projekt giver en gevinst. Og det er ikke nok at måle på det leverede produkt for at se, om projektet kunne betale sig, siger konsulent.

Der er brugt millioner af kroner på at købe, tilrette og implementere et it-system, og brugerne har brugt timer på at lære den nye brugerflade at kende. Men hvad får virksomheden så til gengæld for denne store investering? Alt for ofte slet ingenting.

Sådan lyder det fra Jacob Primault, manager i Rambøll Management Consulting, der har specialiseret sig i gevinstrealisering i projekter. Ifølge ham er det hele 40 procent af større projekter i offentlige og private virksomheder, der ender uden den ønskede gevinst, mens andre 40 procent kun henter nogle af gevinsterne.

Tallene gælder alle slags projekter, men it-projekter skiller sig ikke ud med langt bedre gevinster end gennemsnittet.

»Det koster mange penge at gennemføre it-projekter, og det kan kun begrundes med, at man får nogle gevinster i den anden ende. Men det fejler tit. Alt for ofte bliver der investeret, uden at den planlagte gevinst realiseres. I mange tilfælde er gevinsten ikke engang tydeligt defineret.,« siger han til Version2.

Jacob Primault uddyber sine pointer ved Dansk IT's konference om projektledelse onsdag den 6. februar på Hotel Scandic i Københavns Sydhavn.

En af udfordringerne er, at mange forveksler en leverance med en gevinst. Leverancen er for eksempel et it-system, der lever op til alle kravene i den kravspecifikation, leverandøren har arbejdet efter. Så gennemgår kunden det leverede system, og når der er sat flueben ud for alle kravene, tænker mange, at målet er nået.

Men it-systemet er i sig selv kun et værktøj til at opnå en gevinst, for eksempel at medarbejderne med nye, it-hjulpne arbejdsgange kan behandle samme sag på kortere tid.

»Hvis man bare forholder sig til sin kravspecifikation, får man måske et fantastisk it-system. Men det, man var på jagt efter, var i virkeligheden, at firmaet kan tjene flere penge, ved at arbejdet går hurtigere,« siger Jacob Primault.

Første trin i ethvert it-projekt skal derfor være, at man helt klart definerer, hvilke gevinster man ønsker.

»Tegn et præcist billede af, hvor du gerne vil hen. Desværre bliver projekter ofte sat i gang, uden at folk fra starten kan svare på hvorfor, og så er man på et forkert spor fra starten af,« siger Jacob Primault.

De gevinster, man ønsker, skal så konkretiseres så meget, at de kan måles. For eksempel at en gennemsnitlig sagsbehandlingstid reduceres fra 28 minutter til 22 minutter. Den slags mål kræver selvfølgelig også, at man har målt på den nuværende situation, så man har en baseline.

Mål ikke kun leverancen, men se på gevinsterne

Som tommelfingerregel mener Jacob Primault, at projektlederne skal bruge lige så meget tid på at se, om gevinsterne bliver realiseret, som de bruger på at holde øje med leverancen.

»Når man sidder på styregruppemøder i dag, er det typisk leverancen, man monitorerer, når man ser på projektets status. Men har man ikke samtidig blik for gevinsterne, bliver det som at gå over åen efter vand. Man skal også måle fremdriften i forhold til realisering af gevinster ved et nyt it-system, så man om nødvendigt kan igangsætte tiltag, der retter op på situationen,« siger han.

Opstår det behov, må man gennemgå forudsætningerne nøje og fastlægge, hvor nye tiltag er relevante. Måske spærrer en anden arbejdsgang for de forventede effektiviseringer, eller måske mangler brugerne forståelse for, hvorfor der indføres forandringer.

»Meget af den udvikling vi laver, handler om mennesker, der har holdninger til de arbejdsmæssige forandringer, de indgår i, og som reagerer på dem. De kan blive nervøse for, om de mister deres arbejde, eller klager over, at organisationen ikke tilgodeser dem. Sådanne følelser betyder, at det er svært i praksis at lave de nødvendige forandringer. Så kan det være nemmere bare at tegne en projektplan og følge den.«

Jacob Primault er blandt oplægsholderne til Dansk IT's konference om projektledelse, der finder sted onsdag d. 6. februar på Hotel Scandic i Københavns Sydhavn. Version2 er mediepartner på konferencen.

Kommentarer (7)

Thomas Hagedorn

Kan ikke være mere enig, men mener nu også denne del om baselines bliver tillagt lidt for ringe betydning..

"Den slags mål kræver selvfølgelig også, at man har målt på den nuværende situation, så man har en baseline"

Laver man "kun" baselines på baggrund af et kommende projekt er man allerede et beslutnings niveau for dybt, og vil reelt få et snævert og forsimplet beslutnings grundlag.

Baselines og den indsigt de kan give (hvis man ellers kan magte at overskue de store mængder af data) og om de services man leverer, bør være grundlaget for en samlet vurdering - som herefter gerne skulle pege i retning af de konkrete projekter hvor der kan hentes yderligere gevinster.

Viden er som bekendt magt, men hvem har den?

Allan Astrup Jensen

Måske er det mere relevant med et opråb til politikerne og andre beslutningstagere om ikke at tro på de løfter om besparelser, som projekterne sælges på grundlag af! IT kan ikke lave mirakler og guld.

Henrik Korsgaard

Jeg synes det er fint at begynde at se på effekt og hvilken forandring man gerne vil opnå med et nyt system, men det er uhyre kompliceret, alene fordi billedet af hvordan man opnår effekten er uklart. Samme gevinst kan opnås med forskellige tilgange. Hvordan gør man et system til sagsbehandling mere effektivt? - en hel systemrevision, bedre brugergrænseflade, uddannelse af sagsbehandlere i det eksisterende system eller skrotte et system der måske understøtter bureaukratiske kontrolstrukturer, frem for sagsbehandling - kage hver fredag?

Hvordan måler man gevinst når det er muligt at udvikle systemer der kan få folk til at gå ned med stress? Hvor er gevinsten i et system - medarbejdertilfredshed, sygefravær, fleksibilitet i arbejdsgange? Jeg har svært ved at se hvordan man skal måle effekt kvantitativt og isoleret i forhold til et enkelt system - det er sikkert bare mig :)

Jeg håber da at det nye K03 giver mulighed for en bedre veksling mellem kravspecifikationer og det endelige system - gerne i forhold til en løbende evaluering af effekt og gevinst.

»Meget af den udvikling vi laver, handler om mennesker, der har holdninger til de arbejdsmæssige forandringer, de indgår i, og som reagerer på dem. De kan blive nervøse for, om de mister deres arbejde, eller klager over, at organisationen ikke tilgodeser dem. Sådanne følelser betyder, at det er svært i praksis at lave de nødvendige forandringer. Så kan det være nemmere bare at tegne en projektplan og følge den.«

Spot on - men så skal vi vel have fat i en coach før en IT professionel :)

...og så én til trolden: Selvfølgelig kan nye IT-systemer betale sig, hvordan skulle de store leverandører ellers kunne overleve :P - det gælder vel også for konsulentbranchen...

David Walland

Turing felt that the real test of a computer system was whether it could be distinguished from a human being by a human being.

My experience of writing a very succcessful expert system and having it professionally programmed is somewhat different. The first thing to remember is that not all humans are nerds, so the system has to be designed with a human interface which ordinary users are either used to or find themselves quickly comfortable with.
I had very wide experience with the specialism (Radiation Safety/Control of Radioactive Substances) from being a lowly laboratory technician actually doing the work, right through to being a Radiation Protection Adviser trying to ensure that the law was followed both to the letter and in its intentions. So I have an encyclopaedic knowledge of this area. Computers are an interest of mine and have been since the mid 1960s. So I had both the knowledge of what the system needed to achieve for the various agencies policing our work, for the University itself to be able to satisfy itself what was needed was being done and for the input and output available at the various levels of the University to be both easy and natural to the users and to be readily used by the user and to be realistic about what a computer system could achieve.

It took me around two years to satisfy myself and others that the systematics contained everything necessary for an adequate system to be programmed, about 4 months for the programmer to achieve a working system another 3 years to get all the misunderstandings and glitches out of the system and to input and correct all the preexisting data. I then ran it for a year in one department to get a good feel of how well it worked in practice and to fine tune it. So we are talking of a system which from the first attempt to describe the expert system for programming to the pilot run being completed, had taken approaching 6 years. There was then a training phase which must have taken at least a year to get everyone who needed to use the system on-board and using it (I had had a major breakdown by then, due to overwork and did not see this last phase to completion).
Now I had had in mind from the first that the user must be bribed into using the system. It must take the user far less time than the previous paper system, which it copied very closely. But users now had access to powerful tools to allow them to do more experiments with each batch of radioactive material and to do the most difficult calculations for them. Once logged on, their entire holding of radioactive materials was available to them. The system even prints labels for them with all of the information needed to fully identify an aliquot of material. The result is a system which is enthusiastically used by the users and which handles the very complex web of holding and disposing of these materials thoughout their lifetime and prevents the purchase of them by unauthorised persons, keeps all records correct in the background and even prints out annual returns, legally required by the various authorities, all generated in the correct format ready to be posted on.

Clearly, this was a very specialised area but there are some very clear issues which I can identify as to why the system works and is so well regarded even years later:
* It was designed by someone who thoroughly understood the system and the often apparently opposing requirements for each part of the whole.
* It was designed with consideration of (and discussion with) those who had to use it not just those who thought they knew how it would be used. I discussed and fine tuned the system as a system with people at every level to ensure that everything they felt would make things easier for them was incorporated in the system. This was not just a chat with the senior people involved in the work (I do talk to myself but...) but especially people like the staff who received packages and the store staff who then ensured they went to the correct destination. They helped to get the system tightened as much as possible, so that it became very difficult for radioactive material to be brought on-site with out being ordered through the system or declared.
* The system as a system had been working for some time beforehand (rather badly) as a paper system. There were no surprises - we knew what the system had to encompass.
*The programmer was someone who was used to programming in this area of radioactive materials and radiation. He brought enough knowledge of the area not to make simple mistakes through lack of understanding of words and concepts.

And so on.

I think there are several reasons for failures under different conditions. First the system needs to be designed by someone who both understands what IT can do and what it can't AND what the system needs to achieve to work as envisaged. I strongly suspect that this is seldom achieved.
Next it has to be put together in a way that allows for the opposing requirements to be achieveable. This can require jiggery-pokery with databases etc to achieve but it is astonishing what you can achieve if you always have in mind how the system will (as against should) be used. If necessary run tests to find out...

A complex computer system/program seldom has one single requirement one can test it against. It usually has an over-riding idea (all too often very difficult to test) but usually a plethora of other requirements, from security to usability, from clear easily understood instructions to user-friendly ways of reaching them. Testing in this morass is clearly open to all sorts of abuse and problems.

Recently, my (Danish) wife and I had to use the London Oyster card system for the first time. It was not until the next person in the queue explained how to get our ticket and how to reach the help information we needed that we managed to put some more money on our card and buy the tickets we wanted. That system fails at the most fundamental level!

Never mind the Turing test. Any system which has to communicate with human beings who only think in a human way, has to COMMUNICATE WITH THEM where they are not as the nerds of this world think they ought to be able to manange.

Klaus Kvorning Hansen

Det er en utroligt vigtig diskussion, Jacob rejser. Som kommentarerne viser, er det heller ikke en enkel sag at forbedre sig på gevinstrealiseringen. Hverken før projektet etableres, mens det kører, eller efter det er afsluttet.

Men det er ikke desto mindre indlysende rigtigt, at der gøres noget på området, hvis hele historien om business-cases skal have noget på sig. Hvorfor være omhyggelig med at opstille detaljerede business-cases for at prioritere projekterne ud fra de rigtige kriterier, hvis ikke der følges op på, om de holder?

DANSK IT har faktisk en konference i marts måned, der er dedikeret bl.a. disse problemstillinger.

Nils Bøjden

"Det koster mange penge at gennemføre it-projekter, og det kan kun begrundes med, at man får nogle gevinster i den anden ende. Men det fejler tit. Alt for ofte bliver der investeret, uden at den planlagte gevinst realiseres. I mange tilfælde er gevinsten ikke engang tydeligt defineret."

Det lyder sgu' da mere som om diverse forretningsenheder der står for projekterne, overhovedet ikke er i stand til at vurdere hverken indhold, tidsplaner eller økonomi for projekterne. Sig "Rejseplanen".

Mads Randstoft

Og hvordan måler man lige det? Hvis systemet er et salgs hjælpe system, hvordan måler du så lige om det har kunnet betale sig? Skal sælgerne sælge mere? Er det nok at der bare er kommet et bedre arbejdsmiljø fordi alle "abe opgaverne" nu bliver lavet af en computer? Skal dokumenterne der bliver genereret overholde en given standard? Gjorde den det før systemet?

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Spring - The Spring Framework 3 - Foundation

Hvornår: 2015-12-01 Hvor: Storkøbenhavn Pris: kr. 15300.00

DB2 9 for Linux, UNIX and Windows Application Programming Advanced [CL110G]

Hvornår: 2015-09-07 Hvor: Storkøbenhavn Pris: kr. 12000.00

Adobe Illustrator kursus udvidet

Hvornår: 2015-10-14 Hvor: Storkøbenhavn Pris: kr. 5900.00

Arbejdspraksis og it

Hvornår: 2016-02-01 Hvor: Østjylland Pris: kr. 15000.00

CXD-205 Citrix XenDesktop 7.5 Skills Update

Hvornår: 2015-09-28 Hvor: Østjylland Pris: kr. 16050.00