En it-afdeling indeholder mange af de processer, der indgår i et normalt produktionsforløb: Eksempelvis design, udvikling, fremstilling, test, leverance og support. Alligevel har de fleste it-afdelinger i 50 år selv fået lov til at tilrettelægge deres processer, som de ville.

Måske fordi de fleste it-folk har en særlig evne til at krydre de mest enkle udsagn med indviklede tekniske termer. Samtidig har de fleste topledere begrænset kendskab til it. Så hvis der er problemer med en it-afdeling, går de ikke i dialog med it-chefen. I stedet fyrer de ham – eller outsourcer hele it-afdelingen. Ville det samme ske, hvis der var problemer i salgsafdelingen? Næppe!

Men det er snart ved at være slut: De kommende generationer af ledere er ikke it-analfabeter. Samtidig er der også kommet anerkendte metoder, som beskriver hvordan it-arbejde bør udføres. På den måde kan man bedre vurdere, om en it-afdeling arbejder optimalt.

På leverance- og supportområderne er den mest anerkendte standard ITIL (som står for Information Technology Infrastructure Library). Metoden ligner meget Lean-produktionsmetoden, som oprindeligt blev udviklet af Toyota, og siden anvendt i en række virksomheder i verdenen.

Som i Lean fokuserer ITIL meget på at standardisere arbejdsprocesser og løbende effektivisere arbejdet. Det er en stor mundfuld for de fleste it-afdelinger at indføre ITIL – og for dens omverden. Men min erfaring er, at de fleste it-afdelinger ved hjælp af ITIL hurtigt kan levere en langt mere stabil drift og derefter bliver mellem mellem 20 og 50 % mere effektive.

Enhver it-ansvarlig, som ikke er i gang med at indføre ITIL, bør derfor vurderes meget nøje. For vedkommende er næppe den rette til jobbet.

På design- og udviklingsområdet er situationen en anden. Her anvender de fleste metoder, der oprindeligt er udviklet til byggeri af eksempelvis broer. Idéen er, at man først kan specificere alt hvad man har behov for og derefter sende ”byggeriet” i udbud. ”Byggeriet” gennemføres som beskrevet af den valgte leverandør, og når det er leveret, vedligeholdes det.

Sådan er it-projekter ikke. Dels kan man sjældent beskrive detaljeret, hvad et it-system skal kunne, og dels bliver man meget ofte klogere undervejs i projektet. Eller bør blive det. Derudover skal der ofte udvikles videre på et it-system, når første udgave er klar.

Derfor har mange it-folk siden 2001 forsøgt at definere nye – såkaldte agile – udviklingsmetoder.

Mange virksomheder har oplevet effektivitetsforbedringer i deres udviklingshold på mellem 50 og 100 % når de anvendte metoderne. Ikke så ringe endda. De anvendes i en række forskellige virksomheder. I egentlige it-virksomheder, men også i andre typer virksomheder. Lige fra finansielle virksomheder som pengeinstituttet Spar Nord til medievirksomheder som min. Metoderne tager oftest udgangspunkt i, at projektet består af en række korte delprojekter, og at udviklerne udgør et selvstyrende team, som har en meget tæt, daglig dialog med forretningen.

Men der er også problemer med metoderne. Den største mentale udfordring for forretningen er typisk, at de skal nøjes med at udtrykke hvad de vil opnå. I stedet for hvordan det skal laves. Samtidig indeholder metoderne ikke en garanti: Det eneste, der er fast, er tidsplanen og ressourceforbruget. Hvad der kommer til at indgå i det endelige resultat garanteres ikke. Men igen: traditionelle metoder lover en masse, men det holdes sjældent.

Selve teamet risikerer også at blive meget indadvendte – og selvtilstrækkelige. Dermed kan der opstå problemer den dag systemerne skal i drift.

Men det bør ikke afholde virksomheder og myndigheder fra at bruge de agile metoder. For der kan peges på masser af it-skandaler, som anvendte forældede projektmetoder, som er beregnet til byggeri af 100 % forudsigelige ting. Hvad it-projekter sjældent er.

Bragt som kommmentar i Morgenavisen Jyllands-Posten d. 9. marts 2010