It-udvikling: Læring og politik i rationelle klæder - brahm.dk

Projektledelse og projektkoordinering
variere idet en udvikler beretter, at ”der har været (situationer) hvor det hele begyndte at løbe
stærkt, der hvor jeg begyndte sådan rigtig at komme op i gear, der gik det for stærkt til at vi
overhovedet fik de her informationer projekterne imellem”. Dvs. når processen, som jo hele
tiden genskabes, ændrer karakter, bryder nogle mekanismer sammen, som tidligere fungerede.
Alt er ændring - en skabelsesproces bringes aldrig til afslutning.
De mange delprojekter gør det også svært at placere eller fordele ansvaret når noget går galt,
og der er tendens til at når tingene spidser til, så opstår der interne stridigheder der ikke tjener
fællesskabets interesse. En medarbejder udtrykker, at hun savner ”Team Spirit. Den der med
at ‟det er ikke os der har lavet en fejl, det er de andre projekter‟, den er begyndt at komme
lidt. Der er en abe, der ryger rundt en gang i mellem - og til hvad nytte, ikke? Jeg kunne godt
savne lidt den der med at ‟vi kommer alle sammen i mål, eller også kommer ingen i mål‟”
Jeg har i det ovenstående præsenteret et forløb hvor den samlede udviklingsindsats opdeles i
løst koblede projekter, hvor opdelingen ikke er indlysende fornuftig for aktørerne og derfor
løbende forhandles, hvor viden er personbåren og svær at dele både i og mellem
udviklingsinitiativer, og hvor der er et stort behov for kollektiv læring om behov og løsning.
Jeg har desuden argumenteret for at en retrospektiv antagelse om, at man kunne have
analyseret bedre næppe er rigtig, men organiseringen kan i højere eller mindre grad tage højde
for processens natur. Et eksempel herpå ser jeg i den fælles gennemgang hvor specifikation
og kode læses højt og holdes op imod hverandre for at identificere afvigelser. Det enkelte
projekt kan principielt komme til at skulle ændre i en hvilken som helst del af den
eksisterende it-portefølje, også meget centrale dele. Da sådanne ændringer i it kan have
konsekvenser for andre it-løsninger, er det vigtigt at projekterne er opmærksomme på hvilke
andre projekter der berører samme område af it-porteføljen. Når der er mange samtidig
projekter med mange gensidige afhængigheder øges kompleksiteten. Måden vi udvikler på
med SOA (service orienteret arkitektur) giver flere samtidige projekter med flere gensidige
afhængigheder, og mere der skal læres undervejs, hvilket sandsynligvis bidrager til en mere
selv-organiserende proces og emergerende it-løsninger og it-portefølje, samt behov for, at
organiseringen tager højde for dets lærende og emergerende natur.
It-udvikling: Læring og politik i rationelle klæder 52