Jeg er utdannet utvikler, men allerede etter få år fikk jeg ansvar som prosjektleder. I store deler av min tid i Telenor, jobbet jeg i som prosjektleder samtidig som jeg hadde et linjeansvar i en avdeling først som utvikler så som avdelingsleder. Virksomhetsprosessene som omfavnet disse to strukturene, var ganske forskjellig. Som avdelingsleder hadde jeg personalansvar for 10-15 ansatte, og forvaltningsansvar for en rekke tjenester. Årlig budsjettforhandling handlet i stor grad om kvaliteten på våre tjenester, og om vi trengte å løfte kvaliteten eller fase ut en tjeneste. Kontinuitet var nøkkelordet. Av og til fikk jeg beskjed om å klare å forvalte tjenestene med færre ansatte, uten at kvaliteten på tjenesten ble noe dårligere for kundene. Dette var alltid utfordrende, men noe som måtte gjøres.
Prosjektene ble styrt på en ganske så forskjellig måte. Dersom jeg ønsket å bygge opp en ny tjeneste, så måtte jeg få støtte fra andre enheter som server og applikasjonsdrift, kundeservice, markedsføring og salg. Jeg satte dermed opp et prosjektforslag som jeg fikk besluttet i ledergruppen. Når prosjektet startet, fikk jeg tilgang til ressurser fra mange ulike avdelinger som samarbeidet en prosentandel av tiden på å lage denne nye tjenesten. Dette var ikke uten utfordringer, da forvaltnings og avdelingsansvaret for prosjektdeltagerne alltid gikk foran prosjektansvaret. Min jobb som prosjektleder var alltid å engasjere prosjektdeltagerne til å lage dette nye systemet. Men det lå i kortene at prosjektet ville avsluttes en dag, og resultatet skulle overleveres til avdelingene.
Avdelings-prosjektkonstruksjonen var ikke uten utfordringer, og da spesielt denne overleveringen til avdelingene ved prosjektets slutt var smertefull. Prosjektets tverrfaglige natur lot informasjonen flyte mellom fagområder mer effektivt enn hva avdelingenes hierarkier klarte. Når prosjektet ble avsluttet opplevde mange at kunnskap forsvant ut av organisasjonen, og den lovte gevinsten fra når prosjektforslaget ble godkjent ble ikke fulgt opp av linja etter overleveringen. Flere opplevde også at prosjektet, som er en midlertidig organisasjon, ofte hadde fokus på å lage de funksjonene de hadde lovt mer enn å tenke på brukereffekt. I FINN.no gav konflikten mellom prosjekter og linja så store utfordringer, at vi måtte gjøre noe. Mange hundre feil, få ansatte som tok ansvar, og store deler av løsningen som ikke ble brukt eller likt av kundene førte til at vi måtte tenke nytt rundt både struktur og ledelse.
Løsningen var permanente tverrfaglige team, altså et giftemål mellom prosjektet og linja, for våre mest innovative deler. Vi ble her inspirert av Lean Software Development og Mary Poppendieck. Dette betydde ikke at FINN.no sluttet med avdelinger, og fortsatt har FINN.no og de fleste smidige virksomheter avdelinger. Men for de delene av FINN.no som jobbet med produktutvikling, som tidligere jobbet delvis i et prosjekt og delvis i en avdeling, så fikk de nå en ny permanent stilling i et tverrfaglig team. Denne overgangen til smidige tverrfaglige team førte til en reaksjon i FINN.no: Ordet prosjekt ble «forbudt», flere prosjektledere mistet jobben sin, og FINN erklærte at tiden for prosjekter er slutt. Selvfølgelig var det riktig for FINN.no å etablere tverrfaglige smidige team, og jeg har hjulpet mange organisasjoner i å gå over til slike tverrfaglige strukturer siden. Men jeg tror det var feil å «forby» prosjekter i samme omgang. Av og til har man behov for å sette opp en midlertidig organisasjon som skal løse et ikke alt for vanskelig problem, og prosjektet kan være en passende struktur. Feilen FINN.no gjorde var å presse prosjektet til å jobbe med komplekse problemer hvor få har erfaring og hvor planleggingen blir av svak kvalitet.
Jeg tror derfor de fleste organisasjoner er tjent med å se på tverrfaglige team som en tredje organisasjonsstruktur i tillegg til avdelinger og prosjekter. Tverrfaglige team trenger egne budsjettprosesser og ledelse på samme måte som at man etablerte prosjektstrukturen på siden av avdelings og linjeorganisasjonen.
Dessverre er det mange som blir forvirret av den tverrfaglige strukturen i smidig, da det ligner litt på prosjekter og litt på avdelinger. De virksomheter som tidligere hadde prosjektfinansiering av sine utviklingsprosjekter forsøker å gradvis endre denne til å bli mer smidig. Dermed må de tverrfaglige teamene levere prosjektforslag til toppledergrupper, noe som var en naturlig del av et prosjekts struktur, men som mangler i det tverrfaglige teamets verktøykasse. Dette er forvirrende, spesielt om man fortsatt gjennomfører prosjekter. Har vi et prosjekt så leverer vi et prosjektforslag, men har vi et tverrfaglig team så gjør vi noe annet.
Det som kjennetegner et godt tverrfaglig team, er at de gradvis avdekker kompleksitet og lærer mens de utvikler. Vi ønsker derfor å oppfordre til eksperimentering og læring, og trenger derfor ledelse som deltar i denne eksperimenteringen. Vi starter med en hypotese, og forsøker å lære mer om den på billigst mulig måte. Prosjekter derimot baserer seg på at vi allerede har den kunnskapen vi trenger for å kunne planlegge gjennomføringen i detalj. Dette er ganske så forskjellige forutsetninger. Dersom man er tydelig på at ledelse av smidige tverrfaglige team er noe annet enn både prosjekter og avdelinger, og derfor krever en annen type ledelse og andre virksomhetsprosesser, så vil du se at jobben blir mye enklere. Her er noen spørsmål som kan hjelpe din ledergruppe i å få etablert noen gode virksomhetsprosesser knyttet til tverrfaglige team:
Mange virksomheter har forstått dette, og bygger i dag en parallell organisasjon for de tverrfaglige teamene. Disse blir ledet og styrt etter nye prinsipper adskilt fra både prosjekter og avdelinger. Dersom du har en egen avdeling for prosjekt og programutvikling, så bør du etablere en avdeling for ledelse av de tverrfaglige teamene på siden av prosjekt og programutviklingssjefen din. Dersom du sammenligner ulike toppledergrupper, så vil du se at de i sin struktur og agenda fram til i dag har forsøkt å balansere styringen av avdelingene og prosjektene. En tredje smidig organisasjonsstruktur kan derfor bli litt for mye. Jeg tror at toppledergrupper må velge hva de setter søkelyset på, og om man setter ledelsen av de tverrfaglige teamene til andre enn toppledelsen så mister man etter min mening sin styringsrett over det som i størst grad påvirker brukerne og kundene. Jeg tror derfor at samtlige norske toppledergrupper bør lære seg tverrfaglig ledelse og tverrfaglig styring gjennom å sette ambisiøse og engasjerende mål, og lære av effektene.
CoWork støtter organisasjoner i å etablere styringsstrukturer for sine tverrfaglige team gjennom smidig toppledelse og Tight Loose Tight modellen.
