Gæstebloggen

It-udvikling: Brug hele teamets viden – i tide!

It-udviklingsprojekter kører stadig ikke godt nok. Desværre ved vi det kun alt for godt – både fra medierne, fra kollegerne og sikkert også fra egne erfaringer.

Det kan blive meget bedre! Vel at mærke hvis vi bruger ressourcerne i projektet – teamet – til at indgå i styringen af projektet.

Vores påstand er, at menneskerne inde i projekterne overses, når vi taler om at sikre bedre styring af projektet. Viden fra teamet tages ikke alvorligt - i rette tid.

Projektteamet ser og oplever hver især en hel del, de er tilmed oftest veluddannede fra landets universiteter og veltrænede i at deltage i projekter fra en lang række virksomheder.

Annette Lotz er til daglig IT-udviklingschef på sundhed.dk og ekstern lektor på CBS samt medlem af IDAs panel af tekniske talspersoner og fageksperter og har i en årrække beskæftiget sig med projektledelse og it-udvikling. Illustration: Privatfoto
Diego Børresen Lladó er partner og CTO i rådgivningsvirksomheden Proces360 samt medlem af IDAs panel af tekniske talspersoner og fageksperter og har i en årrække beskæftiget sig med projektledelse og it-udvikling. Illustration: Privatfoto

Set i det lys er det bemærkelsesværdigt, hvor lidt teamets iagttagelser egentlig bliver sat i system, når det gælder om at tage temperaturen på projektets faktiske status.

Standish Group har siden 1994 gennemført undersøgelser af softwareudviklingsindustrien. De peger på, at der stadig er flere projekter med udfordringer end succeser.

Ifølge Standish Group er mindre end en tredjedel af it-udviklingsprojekterne en succes.

Vi ønsker at ændre på det – det er simpelthen for dyrt for samfundet og virksomhederne, når store it-udviklingsprojekter fejler.

Der mangler hverken artikler, kodeks eller gode råd om principper for gennemførsel af it-udviklingsprojekter. Alle meget fornuftige, og vi forstår rationalet, men grundlæggende har de alle fokus på at gøre det, vi altid har gjort – bare bedre.

Nogle iagttagelser stammer helt tilbage fra Bonnerup-rapporten 2001. Vi er nok mange, der har undret os: Hvad er det, der er så svært, at vi ikke er blevet så forfærdeligt meget bedre her 17 år efter, at den rapport udkom?

Transparens øger indsigt

Uanset projektmodel handler det om at opnå større transparens - indblik i teamets indsigt, teamets adfærd og handlinger - og derved et faktabaseret grundlag for at påvirke begivenhedernes gang.

Det handler om at tage problemer i opløbet, enten gennem målrettet facilitering (eller nudging) af teamet eller ved tidligt at få løfte en konkret og faktabaseret problemstilling til styregruppe/projektejer.

Den agile udviklingsmodel fik sit indtog i starten af 2000, og især det ændrede mindset, hvor teamet i højere grad involveres, har allerede givet flere succeser.

Det ses i statistikker, såsom Chaos-rapporten (PDF), og hos en lang række danske virksomheder, som er gået over til at køre mere agilt – hvor vi hører om deres oplevelse af mere succes, når flere beslutninger kan træffes i teamet.

Ifølge Standish Group (PDF) giver anvendelsen af de agile metoder statistisk set en noget højere grad af succes – hele 16 procentpoint er der at hente ved at ændre mindset.

Forudsætter vi, at alle projekter rent faktisk kan køres agilt, giver det en succesrate på 42 pct. Det efterlader dog stadig flere udfordringer end succeser – nemlig 58 pct!

42 pct. af de agile projekter har succes – mod 26 pct, der kører som vandfaldsprojekt.

Vores pointe er, at vi stadig kan lytte til artikler og tiltag med fokus på at blive bedre til det, vi allerede gør, men at der skal andet og mere til end træning i det velkendte for markant at forbedre muligheden for succes i it-udviklingsprojekter.

Men 58 pct. af projekterne er stadig udfordret – selv med et agilt mindset.

»Hvis vi tænker, som vi plejer, og bruger de samme værktøjer og fremgangsmåder, som vi plejer, så kan vi ikke forvente noget nyt,« sagde Albert Einstein.

Inddrag teamet i styringen af projektet

Skal vi følge Einsteins mindset, kan vi måske hente noget af potentialet - de 58 pct. - ved at gøre noget, vi ikke plejer.

Det kan være svært at disrupte sig selv, for hvad er det nu vi ikke plejer at gøre?

Vi kan udelukke mere økonomistyring, flere planer og risikoanalyser og ordrige statusrapporter – det gør vi nemlig allerede.

Men at lade projektets deltagere – teamet – indgå som del af styringen vil være noget nyt. Projektdeltagere udgør den absolut største ressource i de fleste it-udviklingsprojekter, og derved den største udgift.

I dag fylder teams imidlertid meget lidt i rapporteringer, på styregruppemøders dagsordenspunkter, og de fylder ikke meget i de dialoger, som beskrives i 'kodeks for det gode kunde-leverandørsamarbejde'. Men det kunne de jo komme til.

Har vi forstået målet – og er det realistisk?

I et projekts livscyklus er der forskellige 'TouchPoints' – hændelser, hvor lederen har muligheder for påvirke begivenhedernes gang gennem indsigt og dialog. Nogle af disse TouchPoints er mere vigtige end andre at have fokus på i et it-udviklingsprojekt.

For eksempel: I projektet, hvor teamet ikke har forstået, hvilket behov projektet skal indfri, er sandsynligheden for, at de misfortolker informationer, helt klart til stede.

Det er derfor væsentligt at få adresseret, hvorvidt teamet har forståelsen af projektets formål – kontekst om man vil.

Viser det sig ikke at være tilfældet, må projektleder/scrummaster facilitere teamet til at finde en løsning.

Det kan f.eks. være et it-system, som skal sikre opkrævning af beløb, som er udeblevet ift. forventning – det er da væsentligt for teamet, at formålet er håndtering af velgørenhedsbidrag og ikke rykkere for en manglende betaling.

Et andet eksempel – om end lidt inde i projektets forløb – er, hvor teamet oplever, at målsætningen er urealistisk.

Hvorvidt teamet har ret eller ej er ligegyldigt. Sandsynligheden for at et projekt lykkes, når teamet ikke tror på det, er minimal. Det er en mulighed for, at projektledelsen kan gribe ind – foregribe begivenhedernes gang – og få behandlet oplevelsen sammen med teamet.

Måske kan det løses inden for teamet, måske skal det løftes til styregruppen. Det væsentlige er at få gjort noget ved det, før konsekvensen af 'tilstanden' bliver synlig, f.eks. i form af udskudte deadlines eller ringere kvalitet.

Struktureret brug af TouchPoints kan - foruden højere grad af forudsigelighed og transparens i projektet – føre til større grad af medarbejdertilfredshed og tillid til hinanden i teamet – en væsentlig faktor for succes især i agile teams.

Vi vil alle sammen gerne lyttes til og inddrages i et fælles ansvar for et større hele.

Problemstillingen er ikke alene kendt i it-udviklingsprojekter – også forandringsprojekter, hvor nye metoder, værktøjer mv. skal indføres, kan være udfordret.

Også her vil Touchpoints, der løbende tager temperaturen i teamet på en struktureret måde, hjælpe.

Ved forandringsprojekter bringes medarbejdere typisk i en usikker situation, hvor gamle vaner' skal afløses af nye.

En hyppig dialog, baseret på faktabaseret opsamling af viden om, hvad der foregår mellem linjerne, vil være essentiel for succesfuld forankring af de nye rutiner.

Fakta: Brug af TouchPoints

  • Involver alle i teamet - så data om projektet ikke kun kommer fra dem, der råber højest.
  • Få faktabaseret rapportering - følelser og oplevelser omsat til noget målbart og faktuelt.
  • It-udviklingsprojekter fejler stadig meget - Der skal andet og mere til, end det vi gør i dag.
  • Udnyt muligheden for at foregribe begivenhedernes gang - skab et TouchPoint.
Kommentarer (8)
Bjarne Nielsen

Der er mange, som interesserer sig for, hvordan "teamet" performer ... og ofte er det nogen, som står udenfor og vil noget.

Og det både vigtigt og også ganske cool, hvad man kan få ud af et velfungerende team. Det svarer lidt til at tune en motor, så den får kræfter nok til at køretøjet kan køre 300 km/t.

Men hvad hjælper det med en toptunet motor, hvis man kører på hullede skovveje? Hvis chassisset er fra en slidt go-cart? Hvis chaufføren er bange for at køre hurtigt? Hvis chaufføren synes at det vigtigere at snakke med passagerne og lægge make-up, end at køre?

Og selv hvis alt det er på plads, så ser man tit, at chaufføren ikke aner, hvor man skal hen, eller kan læse hverken kort eller terræn, så man kører imod nord i stedet for syd. Her kan en toptunet motor være en ulempe, for så kan man nå at brænde meget og dyrt brændstof af, og nu rigtigt langt ud i det ukendte og fremmede, før nogen undrer sig.

Eller sagt på en anden måde, så er det sjældent at maskinmesteren opdager navigationsfejl (det skulle lige være i rygepausen), og selvom han kan være den første til at se effekten af en grundstødning, så er det som regel for sent på det tidspunkt.

Men bevares, heller en toptunet motor og en erfaren maskinmester, end noget taget fra en misligholdt og slidt plæneklipper kørt af en teenager.

Henrik Wivel

Touchpoints er et godt værktøj at have i bæltet, men det skal, som med alle andre værktøjer, bruges med måde.

Jeg vil prøve at fatte mig i korthed, da der kan være utroligt mange årsager til manglende performance i et team, og Touchpoints kan også risikere at blive en af dem. Det er vigtigt at trække på alles erfaring i et team, hvilket også er grundlæggende viden for alle projektledere, men det er under 'ansvar' i mangel af et bedre ord.

Jeg har set mange eksempler på at det ender som en kaffeklub, hvor alle meninger, irritationer og mindre relevante ting drøftes igen og igen, uden et mål og retning. Næsten genudsendelser af foregående touchpoint. Dertil kommer også at man i mange større organisationer hurtigt rammer det overflødige fedtlag, mellemlederlaget, hvor sund fornuft ofte taber til budgetter, koordinering af planer og deadlines på tværs og hvor det at skabe en succes for det enkelt projekt mange gange tabes/ofres for de store linier.

I nævner at Agile projekter, hvor kommunikation er en del af konceptet, har større succes end vandfald, men at der stadig er langt igen. Jeg vi gå så lang som til at sige at mange af de projekter og organisationer, der kalder sig agile langt fra er agile. De er enten er vandfald, eller ad-hocrati under dække af agile rammer, hvorfor tallene nok er misvisende.

Min erfaring er at de største udfordringer for succes med IT er at man gerne vil det agile, men at man ikke vil tage konsekvensen af det teknisk, ledelsesmæssigt, organisatorisk, budgetmæssigt, med rapportering og så videre.

Diego Børresen Lladó

Tak for dit indlæg Henrik, som jo næsten er universelt gældende for mange ting. Det kræver som bekendt meget energi at holde entropien nede, og analogt til dette kræver det også ledelsesvilje og ambition at inddrage folk og håndtere deres input. Jeg har set retrospectives, touchpoints mv virke, når netop ambition og ønske om succes for teamet er i fokus. Men det er klart, at når disse udføres uden mål og måske blot fordi man skal, ja så kommer der i bedste fald en kaffeklub ud af det og dermed lidt team-socialisering - i værste fald blot lede ved aktiviteten.
Når en organisation er endt med at tillade “kaffeklubben” som resultat af en aktivitet, er det et sygdomstegn og på tide at få ryddet op, og det kan være et langt sejt træk (eller en nedlukning ...).
Organisationer, som ser en værdi i og som tør høre på deres dygtige medarbejdere i alle lag en løbende dialog, tror jeg, opnår langt større faglighed og vilje til at flytte sig i en bedre retning, både fagligt og socialt. Dette tror jeg godt kan starte med en “bottom up” tilgang, hvor de gode kræfter og fagligheder findes frem og skaber energi, omend det måske skal starte som protest, som så bliver synliggjort i stigende omfang. Det kan flytte bjerge - det tager bare lidt tid, men det kan lade sig gøre, ved jeg :-)

Bjarne Nielsen

Kære Annette.

Jeg indrømmer, at det er super-pinligt, men jeg kan altså ikke huske, hvor vi kender hinanden fra.

Det er godt, at du er klar til en diskussion. Jeg har igennem mange år, som deltager i adskillige velfungerende teams, blevet udsat for udefrakommendes mange velmenende initiativer, som oftest iklædt buzzwords opfundet til lejligheden, Og hvis man så tillader sig at "male udenfor rammerne", og være så utaknemmelig ikke ukritisk at ville "lege med", men derimod begynder at stille spørgsmåltegn ved relevansen, så bliver folk tit fornærmede.

Nogle bliver endda direkte nedladende.

Godt at høre, at det ikke er tilfældet her.

Chris Bagge

Al denne snak om optimering af teamet virker som om man går uden om den varme grød. For mig er et team et hold mennesker, op til omkring 10-12 der arbejder på en fælles delopgave. Der er så, ved siden af dette, et projekt som der er mange teams der arbejder på.
Uanset hvor godt teamet måtte arbejde sammen, så hjælper det ikke en sk.. hvis organisationen er "siloficeret", dette er ikke nødvendigvis officielt/organisatorisk men derimod i praksis. Kontering af timer o.l. Hvor projektledere bruger tiden på at administrere i stedet for at lede. Hvor manglende overholdelse bliver timebudgetter bliver straffet. Hvor der mangler en fokus på fremdrift og kvalitet.
Når der tales om projektet der blev / ikke blev succes se man meget sjældent at der er lavet en ordentlig analyse af hvad der gik godt og hvad det gik skidt. En analyse der er ærlig og ikke bare leverer det svar opdragsgiveren har bedt om.
Der er alt for mange gange hvor udtryk som "at holde sig under radarhøjde" bliver brugt. Det er et tegn på at nogen i et lavere lag godt ved at der er alvorlige problemer men at de også ved at lag højere oppe helst ikke vil vide det da det er besværligt. Dette betyder i praksis at man vil stå i første række næste gang der er "omstruktureringer" på vej hvis man siger sin mening.
Når vi er ved afslutningen af et projekt lad os så få en ordentligt evaluering. Hvor var der punkter hvor der skete forsinkelser? Hvor var der store forskelle mellem forventninger og virkelighed? Hvorfor fik vi flere tilbageløb end vi regnede med? Hvad var årsagen til dette.? Når svaret så er; - ja men kunden ændrede mening, eller _ ja men vi får ikke lov til at indregne så mange tilbageløb i planen, så hjælper nok så meget at forsøge at optimere (brugen af) det enkelte team. Man kan trække nok så meget viden ud af et "touchpoint" men hvis dem der skal handle på det ikke kan lide at høre det og ikke handler på det, så er vi ikke kommet videre.

Annette Lotz

Kære Chris
Jeg er helt enig i din betragtning af, at touchpoints som nemt og enkelt kan trække det mest væsentlige frem er fuldstændig ligegyldige, såfremt der sidder en styregruppe, som ikke er interesseret i at få viden, der kan handles på.
Kan se, der tales om teamets performance, men det vi addresserer er projektets succes - og styregruppe er her en væsentlig spiller. Med andre ord gør touchpoints kun en forskel, hvis kulturen er åben og man ønsker at ‘gøre noget ved tingene’. I modsat fald skaber det falske forventninger hos dem, som gerne vil tage ansvar og frembringe indsigt i dét, som er det mest væsentlige.
En enkel side bemærkning er, at teamet også selv bliver stærkere i at få fokus på det mest væsentlige og derved tage udfordringer i opløbet.

Annette Lotz

Kære Bjarne
Mht hvor vi kender hinanden fra, har jeg været aktiv i IDA-IT (helt fra det hed DIF). Kan det være derfra? 😊
Og de oplevelser, du beskriver, lyder jo rædselsfulde - at nogen decideret bliver nedladende.
Tankerne bag det, som Diego og jeg beskriver, bygger på en filosofi om, at teamet skal tages alvorligt - dets viden skal medtages i styringen.
Jeg oplever selv, at teamdeltegere er højere uddannet, end jeg selv er - og deres viden i særdeleshed er værd at medtage i styringen af, hvad der skal gøres. Og mange gange kan teamet faktisk helt selv.
Touchpoint passer ind i en virksomhedskultur med åbenhed og respekt for hinanden.

Log ind eller Opret konto for at kommentere