Det svageste led i projekter

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...)

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....

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".