Press på IT-chefen

Kronikk av : Jeppe Hedaa, 7N

Foråret har været interessant for mig med 21 rejser til 11 lande og besøg hos mange af vores store kunder. De største med mere end 15.000 IT-udviklere og de mindste med et par hundrede – alle virksomheder med IT som et strategisk værktøj og som kompetitiv fordel, ja nogle opfatter IT som deres kerneydelse, selvom de står registreret i en helt anden branche.

Det er et stort privilegium at få lov til at se på tværs af så mange virksomheder, og man står tilbage med en stor ærefrygt for det arbejde en moderne IT afdeling skal gøre for at lykkes med hvad vi kalder Kompleks Systemudvikling. Det mest pressede enkeltindivid i denne verden må være CIO’en.

Det er faktisk skræmmende mange fagområder en IT-chef (CIO) skal dække i dag. For bare 20 år siden bestod de store IT systemer groft sagt af grønne terminaler og et stort centralt IBM system. I dag skal man selvfølgelig stadig kunne håndtere de tusinder MIPS, men man skal også kunne leve med et hav af brugerinterfaces på alt fra PC’er over tablets til mobiltelefoner og diverse håndholdte systemer af forskelligt fabrikat. Herudover skal man mere end nogensinde før mestre kravspecifikation og kravstyring, arkitektur, udviklingsmetoder, vedligeholdelse af legacy-systemer, integration fra alle vinkler, test, performance optimering, drift, sikkerhed, gigantiske organisationer, autonome brugere, købesystemer blandet med egenudvikling, øgede lovkrav, indblanding fra en økonomichef der ikke har den dybe indsigt i hvad alt det ovenstående kræver og en forretning der skal bruge det dobbelte i går. Pyha..!

Jeg har brugt noget tid på refleksion oven på min rejse. Hvilke mønstre kan jeg genkende på tværs af lande, virksomheder og afdelinger?  Findes der nogle grundsandheder og hvad kan vi i givet fald lære af dem? Kan vi gøre noget nemmere for os selv?

Den vigtigste lektie overhovedet er, at IT specialister ikke bare er IT speicialister. Nogle individer er bare SÅ meget mere efficiente. Det var også hvad Sackman et al allerede i 1968 nåede frem til i den første videnskabelige undersøgelse på området. Blandt en stor gruppe udviklere med samme CV og gennemsnitligt 7 års anciennitet producerede den enkelte vidt forskellige resultater på samme opgave. Nogle udviklede 20 gange hurtigere end andre. Nogle debuggede 25 gange hurtigere end andre. Nogles kode fyldte fem gange mindre end andres. Nogles applikationer performede 10 gange bedre end andres. Undersøgelsen er senere blevet udbygget og bekræftet af Curtis 1981, Mills 1983, Demarco og Lister 1985, Curtis et al 1986, Card 1987, Boehm og Papaccio 1988, Valett og McGarry 1989 og Boehm et al 2000. Hvis jeg kan tillade mig at supplere med en gut-feeling fra mine 30 års erfaring, så vil jeg sige, at en god tommelfingeregel er, at nogle IT specialister er 10 gange mere effektive end andre.

Den anden væsentlige lektie er, at store hold kører i grøften. Man kan ikke bare øge ”produktionsfaktorerne” hvis man vælger at køre sine projekter med store hold. Law of Diminishing Marginal Return og Communication Complexity ((n2-n)/2), hvor produktivitetskurven i udviklingssammenhænge typisk knækker over omkring de 8-10 personer. Loven siger, at marginale afkast aftager, når man øger netop 1 produktionsfaktor og holder alle andre uændrede. Den faktor som vanskeligt lader sig skalere i udviklingsafdelinger er viden og adgang til information, pga den eksponentielle stigning i kompleksiteten af kommunikation. Det er selvfølgelig ikke en eksakt videnskab, når det gælder udviklingsafdelinger, men en god tommelfingerregel er, at man helst ikke må bemande et enkelt hold med mere end 8 specialister. Tallet kan påvirkes af mange omstændigheder, herunder anvendelse af ny teknologi (mindre hold), støj fra organisationen (mindre hold), vilde time-to-market krav (mindre hold) osv. Her er det måske også relevant at mindes Brooks law: Hvis man mander op på et forsinket projekt, forsinker man det yderligere.

Der er en gammel sandhed som er utroligt vigtig i denne sammenhæng, nemlig: Den der står tættest på et problem, er også den der bedst genkender den rigtige løsning.

Derfor er den tredje store lektie, at det er den ansvarlige projektleder der skal bemande sit hold. Det er i min optik et ufravigeligt krav, hvis man skal lykkes med vanskelige IT-opgaver. HR og indkøbsafdelingerne skal ikke blande sig for meget i den enkelte ansættelse eller det konkrete køb af den individuelle specialist-konsulent. Jeg har flere gange besøgt store udenlandske virksomheder, hvor IT er blevet frataget indflydelsen, og hvor resultatet er en helt opgivende organisation, uden en rimelig chance for at nå i mål.

Virksomhedernes velmenende stabe bør primært få til opgave at forhandle generelle betingelser, styre kontrakter og administrere lønbreve eller aftaler, og så ellers støtte fagområdernes bemandingsproces.

Med ovenstående tre lektioner kan man så spørge sig selv, hvorfor vi ser store IT-projekter indkøbe kæmpe pyramide-formede teams, når vi nu ved, at man skal etablere små elitære hold for at lykkes med sine svære projekter. Svaret er rystende enkelt… Der er ufatteligt mange penge (for leverandøren) i at fylde pyramide-organisationen med junior profiler, der endnu ikke helt er opgaven voksen. Det er dybt ulykkeligt i en tid hvor der, mere end nogensinde før, er brug for super kompetent faglighed.

Det har aldrig været mere krævende at arbejde med kompleks systemudvikling. Vi skal arbejde fokuseret på at skabe et miljø af bred og høj faglig ekspertise, med dygtige mennesker som er drevet af kærlighed til IT.

Jeg foreslår derfor, at vi genindfører tilliden til IT-chefen. Lader ham/hende tage ansvaret for at bygge små elitære enheder, som ansvarligt og professionelt kan bygge og vedligeholde de IT systemer der kan gøre organisationen i stand til at klare sig endnu bedre fremover. Og lad nu være med at blive smittet af økonomifunktionens bedrevidende mistro. Dine IT folk ER på samme hold som dig. De elsker også butikken og vil gøre deres bedste og lidt til, for at I alle lykkes både billigere og bedre.