Kan det virkelig være så enkelt? Er der nogle få årsager som får store IT-projekter til at fejle, faktorer som ikke findes i markedsrettede projekter der udvikler standardsoftware og produkter. De ser nemlig ud til at have en væsentligt højere succesrate.
Det virker sådan, når jeg tænker på nogle af de store offentlige projekter som er gået galt.
I et markedsprojekt er kunden nødt til at tilpasse sin organisation og arbejdsmåde til softwaren. Det kan være dyrt og besværligt, men det er generelt lettere at tilpasse en organisation end at tilpasse en software.
I et offentligt IT-projekt er det derimod en styregruppe eller beslutningstagere udenfor selve projektet, som skal beslutte om organisationen skal tilpasses til begrænsninger i software. Det kan gøre det næsten umuligt at udvikle en software som passer, når det skal ske ud fra en eksisterende platform.
Især når de reelle behov i organisationen langt fra er undersøgt grundigt nok. Der er måske skrevet en grundig kravspecifikation, men den er ikke baseret på viden der er indsamlet om det arbejde der skal udføres og de reelle behov.
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.
Lad mig give to eksempler.
Det nok største problem i rejsekortet er implementeringen af takstzoner i systemet. I virkeligheden er det en nærmest umulig opgave. Der er uklarheder og ulogiske dele i fortolkningen af takstzoner, noget der normalt bliver løst af tog- og buspersonale, uden særlige problemer.
Der er altså en lang række løse og skjulte regler som er nødvendige for at det nuværende system kan fungere, men dem har ingen været opmærksomme på, da de lavede det nye rejsekort.
Den digitale tinglysning var baseret på at de fleste brugere ville anvende digital signatur – kan I huske den? Ledelsen af projektet og foreningen Danske Boligadvokater gik ud fra at det var tilfældet, men der var ingen som undersøgte om det var realistisk.
Samtidig havde advokaterne ikke fået deres systemer på plads, så de i hvert fald i første omgang var henvist til at bruge den grænseflade der var lavet til private med meget få transaktioner. De havde altså ikke fået tilpasse deres udstyr og arbejdsgange.
Jeg vil gerne læse nogle kommentarer. Hvis det her er de afgørende faktorer, ved vi hvordan det kan være muligt at få offentlige IT-projekter til at lykkes.
Jeg tror bestemt du har ret, men er det ikke noget alle har vidst i mange år? PHK har i flere blogindlæg været inde på dine pointer før, og det er almindelig kendt at det skrøbeligste led fx i SCRUM er "Product Owner"-rollen. Mine egne erfaringer med offentlige projekter er også at der ofte er for mange ledelseslag mellem dem der bestemmer, og dem der skal anvende systemerne.
De ser nemlig ud til at have en væsentligt højere succesrate.
Har du en kilde til det?
Store offentlige projekter har selvfølgelig større offentlig bevågenhed of fejler derfor mere spektakulært. Men når vi taler projekter i prisklassen nogle få millioner lønkroner, så er det absolut ikke min personlige erfaring at det offentlige er specielt meget dårligere - selv ikke når projekterne har departementets bevågenhed.
Jeg tror, at du har fat i noget af det rigtige - både i forhold til IT-projekter i det offentlige og i forhold til interne projekter i store virksomheder. Især det med, at man må helst ikke lave om i arbejdsgangen, for så kunne man jo "bare" have valgt en standard-løsning i stedet.
Så den slags projekter bliver ofte til noget med, at man vil lave det hele selv, fordi det skal tilpasses "vores måde at gøre tingene på". Men den måde er nok så forskellig fra person til person internt i organisationen og derfor bliver kravene flydende og successen svær at måle, fordi ikke alle fik deres måde at gøre tingene på, med.
Det jeg ser som det store problem ved den tilgang til en opgave er, at kravene bliver "vi vil gøre alting præcis som idag, bare digitalt/i et nyt system/i skyen/..." - Det er ikke noget godt udgangspunkt, for der kunne jo være ting, der kunne gøres smartere ved at lave om på arbejdsgangen, nu hvor man er i gang...
Så et mere generisk projekt kan sige "når nu det her skal gøres med en SW, hvordan gør man det så smartest", men det mere specifikke projekt er nødt til at sige "den her arbejdsgang passer ikke så godt til SW, hvordan laver vi en SW til den".
Så det korte svar fra mig må være: Hvis man vil digitalisere og modernisere, så må man også være parat til at lave arbejdsgange grundlæggende om, så de passer til et digitaliseret eller moderniseret system...
Påstand: Der er lige så mange private it-projekter, der fejler, som der er offentlige it-projekter, som går skævt og lukkes ned. Forskellen er bare, at de offentlige projekter har større bevågenhed fordi, at det er skattekroner der bruges.
Som ansat i en stor kommunal virksomhed oplever jeg meget ofte, at forretningen er villig til, at modernisere og digitalisere, Men det skal ske på forretningens præmisser og ikke pga. af tekniske finurligheder. Jeg oplever stort set altid, at holdningen er, at et system skal understøtte og modernisere arbejdsgange, men ikke diktere kursen for, hvordan man skal gøre sit arbejde. Dette gælder iøvrigt både når vi snakker implementering af standardsystemer og udvikling af løsninger.
Jeg tror du er inde på noget af det rigtige - om hvorvidt det så kun er det offentlige der fejler er svært at sige, for vi ved ikke nødvendigvis hvad fejlraten er i private virksomheder.
Det minder lidt om hvad Walter Burke siger i The Recruit:
"Our failures are known - Our successes are not."
Det er afgørende at man, før man begynder at hælde magisk IT-sovs ud, helt gør sig klart hvordan ens arbejdsgange osv. er, og man får simplificeret i videst muligt omfang.
Jeg faldt en gang i unåde hos en kunde, der havde fået den fantastiske ide at de ville have e-kontor (sic!) uden overhovedet at have gjort sig klar over hvad de egentlig ville have.
Det huede dem ikke at jeg sagde at før de havde styr på deres arbejdsprocesser, informationsflow, ryddet op i underlige krumspring for at tilgodese enkelte individers underlige arbejdsvaner etc, etc, så kunne de godt glemme alt om det.
Tilsvarende med rejsekortet - udgangspunket er tåbeligt, i stedet for at man startede med at finde ud af hvordan man simplificerede zonesystemet voldsomt - selv om det så havde betydet at priserne måske endda måtte sættes ned, så kunne det sagtens have været opvejet af de milliarder der allerede er hældt i kloakken, og den kundeflugt over til bilerne som rejsekortet vil medføre.
Uanset størrelsen af et projekt eller hvorvidt det er offentligt eller privat, går der ofte de samme ting galt. Der er blot større fokus på de offentlige projekter, dels fordi de altid er store, dels fordi de bliver betal af vores skattekroner.
Man regner med, at IT kan løse næsten alt. Et nyt IT-system forventes at kunne løse problemer, der er relaterede til arbejdsgange, dårlig kommunikation eller ringe ledelse. Dette er urealistisk; f.eks. er dårlig kommunikation mere et spørgsmål om kultur og interne regler, end det er et spørgsmål om, hvorvidt man bruger et avanceret system til vidensdeling, email eller brevduer.
Nye løsninger bliver ikke ”nytænkt”, men bliver ofte lavet sådan, at man skeler til gamle måder at gøre tingene på. Et eksempel er Rejsekortet; det ville have været oplagt, hvis man gjorde op med de gamle takstzoner, rabatordninger osv.. I stedet bliver det gamle ”tænkt ind” i det nye, hvilket øger kompleksiteten. Man bibeholder det uhensigtmæssige i de gamle måder at gøre tingene på, blot fordi man har vænnet sig til dem og indrettet relaterede arbejdsgange til dem.
Nye IT-systemer medfører ofte nye arbejdsgange. Dette kræver, at det ikke kun er slutbrugeren, der er involveret, men også dennes chef. Jeg har før oplevet, at manglende engagement fra ledelse / projektejer, resulterede i, at beslutninger om arbejdsgange ender med at blive taget af en programmør - senere til projektejerens store overraskelse. Alt for ofte sættes projekter i gang som papirflyvere; intentionen og den generelle retning er fin nok i begyndelsen, men uden styring aner man ikke, hvor de ender.
Man bør altid regne med, at et nyt system medfører nye måder at gøre tingene på. Hvis man erstatter sin hammer med en skruetrækker, må man også udskifte sømmene med skruer. Og desuden instruere brugeren, så han ikke sidder og hamrer skruer i med en skruetrækker. :-)
Dette kan betragtes som en ulempe, men er i virkeligheden ønskeligt; vi lever i en dynamisk verden, der hele tiden er under forandring. En organisation, der ikke kan følge med og være lige så dynamisk, kan ende med at gøre sig selv overflødig (hvis den er privat) eller bliver bureaukratisk, ineffektiv og dyr (hvis den er offentlig).
Implementering af IT-systemer er kun sjældent lige så nemt som at ringe til Peter fra Leasy. Det skulle lige være, hvis projektet er lige så enkelt og overskueligt som et nyt fjernsyn :-)
Jeg tror dog, at Georg Strøm har en pointe i, at markedsrettede projekter ofte har mere succes. Arbejdsbetingelserne er simpelthen anderledes. Man udvikler et generelt system, hvor man i højere grad selv er herre over, hvad der systemet skal kunne. Man drukner ikke i alt for lange kravspecifikationer, hvor nogle krav har rod i gamle måder at gøre tingene på. Og features der er svære at implementere, kan nedprioriteres. Det kan kunderne ofte også leve med, da det er billigere og hurtigere at ændre på arbejdsgange, end det er at tvinge et IT-system til at passe til en organisation med skohorn og skruetvinger.
En blandt mange klassikere indenfor store IT udviklingsprojekter er at de store alvorlige teknik beslutninger, såsom programmeringssprog, metodik, database, hosting leverandør, ansættelse af it nøglepersoner etc. bliver taget af en forretningsmæssig chef uden it baggrund, mens de store dybe vidtrækkende forretningsmæssige beslutninger ikke finder en afklaring iblandt de forretningsmæssige chefer, og følgeligt bliver besluttet af programmører og andet teknisk personel når de i deres arbejde når til det punkt hvor en beslutning må tages for nu skal softwaren skrives. Ekstra sjovt er det når pågældende programmører er eksterne konsulenter med få månederrs ancinitet i organisationen når de tager disse beslutninger.
"Især når de reelle behov i organisationen langt fra er undersøgt grundigt nok. Der er måske skrevet en grundig kravspecifikation, men den er ikke baseret på viden der er indsamlet om det arbejde der skal udføres og de reelle behov."
(2013, fra artiklen ovenfor).
"Det farligste inden for softwareudvikling som alle ser ud til at følge - at du specificerer præcis, hvad du skal gøre, og så gør du det. Det er der, de fleste af vores problemer stammer fra. De projekter, der blivende kaldt en succes, har levet op til deres kravspecifikationer. Men de specifikationer var baseret på softwaredesignernes uvidenhed, før de gik i gang med arbejdet.«
(1968, udtalt af en deltager på et FN-møde om tilstanden i IT projekter.)
http://www.version2.dk/artikel/dataloger-i-1968-drop-nu-big-bang-modelle...
(Det var så et NATO-møde, citatet fra 1968 stammer fra, tsk tsk...)
Jeg kom til at tænke på endnu en forskel mellem markedsprojekter og projekter der skal producere et system til en bestemt kunde. Ved et markedsprojekt er der som regel en marketingsafdeling som indsamler kundeønsker og behov, og samtidig har tilstrækkelig gennemslagskraft til at få dem med i projektet. I et kundeprojekt er der ikke en tilsvarende funktion, så nogle væsentlige behov hos kunderne først bliver opdaget når kunden forsøger at tage systemet i drift.
Ved et markedsprojekt er der som regel en marketingsafdeling som indsamler kundeønsker og behov, og samtidig har tilstrækkelig gennemslagskraft til at få dem med i projektet.
Det er jo så lidt et tveægget svær.
Måske giver det på overfladen et system der mere ligner det kunden (eventuelt stærkt hjulpet af en overivrig sælger) forestillede sig, så sker det ofte på bekostning af systemets integritet.
Jeg tror netop at mange af problemerne i mellemstore offentlige projekter skyldes at der har siddet en markedføringsafdeling og tænkt 'ingen problemer', hvorefter at systemet så er fejlet på at det der er aftalt kræver meget dybe tilrettelser i leveradørens hyldevare.
Så markedtingafdelingens rolle bør højst række til ønsker til hvilke egenskaber der bør tilføjes til virksomhedens hyldeprodukt. Det vil kunen styrke produktet, eller i det mindste give udviklerne en chance for at designe egenskaberne ordentligt. Markedtingsafdelingen må aldrig nævne muligheder for kunder der ikke allerede er en del af de implementerede standardegenskaber!
Det er jo så lidt et tveægget svær.
Lad mig lige uddybe det lidt:
Det er helt klart en fordel for et produkt at der sidder en afdeling og vurdere nye egenskaber baseret på reel viden om kundernes ønsker og behov.
Jeg tror at det svageste led i mange projekter netop er når markedtingsafdelingen lover kunderne ting uden at have taget resten af organisationen i ed. For eksempel når en sælger har solgt et ESDH-system og sagt at det sagtens kan opfylde kundes nuværende forretningsgang og det efterfølgende så viser sig at kræve gennemgruibende ændringer i grundsystemet.
Så markedtingsafdelingens opgave er både at sørge for at virksomheden bliver klogere på kunderne og deres behov, men de må ikke af egen drift love nye egenskaber. (Og de skal være meget varsomme med at ekstrapolere fra andre specialtilretninger til hvor let det er at løse nye kunders specialønsker)
Jeg støder MEGET ofte ind i trafikuheldet imellem marketing, teknik og virkeligheden:
Marketing aner brik om hvad, kunden rent faktisk vil bruge systemet til. Hvad systemet / teknikken kan, men for satan, det skal sælges!
Udviklerne ( teknikkerne ) er så fokuserede på deres lille område, at ALT simpelthen ligner et søm ( for at bruge hammer-metaforet ).
Og kunden sidder tilbage med et underligt sammensurium og tænker "QUE?!?!"
Et eksempel :
Vi skulle integrere en web flade op mod NAV, og diskussionen drejede sig hurtigt over mod filtre og andet NAV snask, hvorefter jeg stiller spørgsmålet : "Det kan godt være, at NAV kan nogle lækre ting, men brugeren har brug for en dato og et tal - så hvad får vi ud af de ekstra features ?".
Jeg synes, at der bruges for lidt tid på at stille spørgsmålene :
"Hvad skal systemet gøre for brugeren og hvordan?"
Hiv nu nogle folk, som kan stille spørgsmålene, med ind til kundemøderne FØR projektopstart.. Klarlæg om det nu ER nødvendigt at bruge teknologi X. I nogle brancher har man Application Engineers - en hybrid mellem en udvikler og en sælger, som rent faktisk har brancheviden og kan bygge bro imellem verdenerne. Luk udviklerne ud i den "farlige" verden og lad dem finde ud af, at der også er brugere i den anden ende.
Kære alle
Super gode indlæg i alle har... min erfaring stemmer fuldt overens med jeres oplevelser så "check mark" til det... men denne debat visere min optik netop symtomet.... alt vores viden, når ikke beslutningstagerene(politikerne), dertil skal skal lægges vores rationelle tankegang som konflikter med den politiske tankemodel og dermed stor sansynlighed for at der anvendes politiske referancer som beslutningsmodel....
Jeg har arbejdet i flere virksomheder der lavede markedsprojekter, og kender problemstillingen med at kunderne bliver lovet noget som ikke kan leveres. Mine erfaringer er, at det alt andet lige er en fordel at have en slagkraftig gruppe som kan indsamle ønsker fra kunderne og bringe dem videre til projektet. Det er også min erfaring at marketing og udviklingsfolk gennemgående kunne tale åbent om hvad det ville koste at medtage forskellige ønsker.
Endelig at det især var salgsorganisationen som lovede noget der ikke kunne opfyldes, eller hvor det var uforholdsmæsigt dyrt at få med. Det problem var det samme uanset om firmaet primært lavede markeds- eller kundeprojekter. Her spiller det ind, at sælgerne ofte har en kommisionsløn der får dem til at tænke kortsigtet, mens marketingsafdelingen mest bliver målt på om de nye produkter lever op til hvad der oprindelig blev lovet.
Jo større et projekt er, jo større sandsynlighed er der for at slutbrugerne ikke deltager i projektarbejdet. Da der bliver nedsat en ekspertgruppe. Hos de slutbrugere der ikke deltager, opstår der let mistro til formålet med projektet. Eksempelvis at det indføres for at spare arbejdspladser. Der er så også stor risiko for, at slutbrugerne ikke synes projektet løser deres største udfordringer, og det derfor bare er generende ekstra bureakrati. Bureakrati er tit "et kort" der spilles, uden at have konkrete målinger, men der er en fornemmelse og "noget nyt der presses ned over hovedet".
- Danmarks største job- og karrieresite for ingeniører og it-professionelle.
