”Vi skal forkorte tiden fra ide til leverance”… Aha. Jaså. Hvorfor?

Læste overskriften på LinkedIn fra en nytiltrådt IT-leder. Og tilføjer nu selv min egen umiddelbare refleksion bagefter. Hvorfor egentlig? Hvorfor forkorte? Hvorfor ikke forlænge? Og hvad er rammerne for at det altid skal gå hurtigt? Især når vi igen og igen kan se at hastighed giver stress og fjerner fokus fra overblik og kvalitet?

geralt / Pixabay

”Vi skal forkorte tiden fra ide til leverance”…. Jeg synes at overskriften tegner et alt for naivt billede af hvad tid, leverance og kvalitet er.

Jeg tror vi overser, hvad der sker, når alting skal gå hurtigt.

I projekttrekanten er der tre elementer:

1. Kvalitet
2. Ressourcer/økonomi
3. Tid

Ideen er at det ikke er muligt kun at ændre på én af faktorerne, uden at mindst én af de andre også skal tilpasses. I udtalelsen er der altså fokus på tid. Måske fordi IT-projekter ofte trækker ud?

Og så tænker enhver god IT-chef, at vi jo så må fokusere der! På tiden. Den hurtige tid. Den korteste. Time-to-market!

Det jeg har oplevet i mine 10 år som IT-konsulent er, at vi igen og igen fucker tidsplanerne op. Jeg har ikke set en eneste tidsplan endnu, som har holdt vand. Jeg har til gengæld set masser af frustration, pres, stress og sygdom, fordi vi forsøger at leve op til en forudsigelse af fremtiden, som ingen troldmand kan levere.

Måske overser vi, at der er to mulige bevægelser på ”tidsaksen”:

Den første er rigtigt nok at vi kan gøre tingene hastigere og mere overfladisk; og vi kan gøre tingene langsommere og mere grundigt. Begge ”tids-kvaliteter” har stort potentiale.

Langsomheden har bare ikke rigtigt plads i dagens IT-projekter?

Forestil jer at en ny IT-direktør sagde:

”Vi skal gøre tingene langsommere. Tænke os grundigt om før vi kaster os ud i noget. Lave kvalitet hele tiden. Tage tiden til kvalitet. Kvalitet fra ide over planlægning til dagligdagen efter vi er gået i produktion. Kvalitet i specifikationen, kvalitet i koden, kvalitet i testen, kvalitet i leverancehastigheden og kvalitet i slut-produktet. Det kan vi kun, hvis vi sætter tiden af til det.”

Hende ville jeg gerne arbejde med!

Jamen Jørn, det kan vi jo ikke. Det er jo ikke effektivt?

Effektivt og effektivt.

Er det effektivt at samle enorme mængder af fejl op efter kunderne er kommet på?

Er det effektivt at håndtere frustrerede interessenter, fordi vi alligevel ikke leverede det de forventede?

Er det effektivt at overlade manuelle procedurer til organisationen?

Er det effektivt at de fleste IT-organisationer kæmper med stress, hyppige jobskifte og sygemeldinger?

Men Jørn! Langsomhed er jo i hvert fald heller ikke effektivt?

Ah! Jo, jeg tror faktisk langsomhed er mest effektivt på mellem og lang sigt.

Det kan synes som om, der hersker næsten kaotiske tilstande i de IT-organisationer, jeg arbejder med som konsulent.

Der sættes alt muligt i gang. Der er (på overfladen) en overordnet prioritering, men da vi i prioriteringen ikke kan forudsige eller tage højde for hvad der sker i fremtiden, ender vi ofte med at stå i konflikter, fordi vi kun kan lave en ting af gangen.

Og tiden skrider. Planerne flyttes; en, to, tre gange fordi vi har mistet overblikket. Jo mere vi bliver forsinket, jo højere pres bliver der på at få genplanlagt og komme videre igen. Og jo mere tillokkende bliver det at sænke kvalitet.

Men dårlig kvalitet giver flere tids-problemer. Skidtet virker ikke. Vi må fejlfinde. Debugge. Måske refactoring af store områder af koden. Øv.

Hvorfor, spørger nogen? Hvad gik galt? IT-ledelsen vil have svar. Men der er ingen rigtig gode svar.

Ledelse, der løber væk fra frygten

Frygten hos IT-projektlederne og IT-mellemlederne får overtaget og der dykkes ned i materien for at finde én eller anden – eller ét eller andet – som vi kan skyde skylden på. Frygten for hvad der sker, hvis vi fortæller hvad der reelt er årsagen – og udstiller at ledelsen selv er skyld i forsinkelserne og den dårlige kvalitet, gør at vi finder en undskyldningen. Reel eller ej.

Fordi ”vi skal forkorte tiden fra ide til leverance”. Og fordi vi tænker, at vores eneste mulighed er at sætte farten op, hvis vi kommer bagefter.

Jeg tror, vi i stedet bør stoppe op og kigge på, hvorfor vi fejler i første omgang. Vi fejler, ikke, fordi tingene gør for langsomt. Vi fejler, fordi tingene går for hurtigt. Måske handler det ikke om Time-to-market, men om Timing-to-market.

Jeg tror ikke længere på at hurtighed ALTID er det rette valg. Jeg ser, at det oftere og oftere er langsomhed, der er det mest effektive valg på såvel den korte, den mellemste og den lange bane. Jeg tror, at vi ved at bremse op og lave tingene ordentligt, kan gøre mange IT-projekter mere effektive. Og få dem afsluttet hurtigere.

Hurtighed er vigtig. Men langsomhed er i min forståelse faktisk vigtigere.

Måske kan jeg endda ane at langsomhed og meningsfuldhed i arbejdslivet vil være den perfekte cocktail for mange IT-mennesker? At langsomhed, at skabe mening på jobbet og at være med til at lave gode løsninger, vil være tiltrækkende på mange i min branche?

Måske kan jeg håbe at en visionær IT-leder forstår det. Og fortæller om det. Begynder at fokusere på kvalitet. Og gode projekter. Og langsomhed.

I det øjeblik er jeg helt overbevist om at hun kommer til at svømme i ansøgninger fra IT-fagfolk.

Naturen skynder sig aldrig. Og dog når den altid frem.

Kærlig hilsen

Jørn