Leavitts model: et værktøj til ledelsesudvikling

Når en forandring går skævt, handler det sjældent om én enkelt ting. Et nyt IT-system kan være udløseren, men modstanden opstår måske, fordi arbejdsgange ikke er afklaret, roller er uklare, eller kompetencer ikke følger med. Leavitts model er et af de mest brugte greb til at få det overblik hurtigt.

Modellen kaldes ofte Leavitt-diamanten, fordi den beskriver organisationen som fire hjørner, der hænger sammen. Pointen er enkel og praktisk: Flytter du på ét hjørne, bevæger de andre sig også, uanset om du har planlagt det eller ej.

Hvorfor en enkel diamant stadig hjælper projektledere

Projektledere står tit i krydsfeltet mellem drift og udvikling. Man får et mandat til at “implementere en løsning”, men løsningen lever først rigtigt, når mennesker, opgaver og rammer spiller sammen.

Leavitts model fungerer godt i både klassisk projektledelse og agile set-ups, fordi den kan bruges som fælles sprog i styregrupper, projektteams og linjeorganisationen. Den er også god som tidlig diagnose, når symptomerne er tydelige, men årsagen er uklar.

Og så giver den ro: Når man kan se sammenhængene, bliver det nemmere at prioritere de næste skridt i stedet for at slukke brande.

De fire byggesten i Leavitt-diamanten

Leavitts model beskriver organisationen som et system af fire gensidigt afhængige elementer: opgaver, mennesker, struktur og teknologi. Du kan tænke dem som fire “kontrolpunkter”, der bør være i balance.

Opgaver: Hvad skal leveres, og hvordan ser arbejdet ud?

Opgaver handler om organisationens arbejdsprocesser og leverancer. I projekter er det tit her, krav, scope og procesdesign bor.

Når opgaver ændres (ny service, ny arbejdsgang, nye kvalitetskrav), påvirker det både hvilke kompetencer der kræves, hvilke værktøjer der er nødvendige, og hvordan arbejdet skal organiseres.

Mennesker: Hvem skal lykkes med forandringen?

Mennesker dækker kompetencer, erfaring, motivation, uformelle normer og forventninger. I projekter betyder det bl.a. stakeholder-adfærd, læringskurver, og hvordan teams samarbejder i praksis.

Hvis du undervurderer “mennesker”-hjørnet, ender du ofte med en teknisk implementering uden adoption.

Struktur: Hvem beslutter hvad, og hvordan koordineres arbejdet?

Struktur er de formelle rammer: roller, ansvar, beslutningsveje, mødestrukturer, governance, politikker og procedurer. I en projektkontekst omfatter det også projektorganisering, styregruppearbejde, change control og snitflader til drift.

Små ændringer i struktur kan give store effekter, fordi de ændrer tempo, prioritering og tydelighed.

Teknologi: Hvilke værktøjer og systemer understøtter arbejdet?

Teknologi er både IT-systemer, værktøjer og metoder, men også hvordan de faktisk bruges. Et værktøj kan være “indført” uden at være integreret i hverdagen.

Teknologi hænger tæt sammen med opgaver: Automatiserer man noget, ændrer opgaverne sig. Indfører man et nyt værktøj uden at tilpasse opgaver og struktur, kommer friktionen hurtigt.

Her er en tabel, du kan bruge som tjekliste i analyse, projektopstart eller scope-afklaring:

Element	Typiske spørgsmål	Projektartefakter der kan hjælpe
Opgaver	Hvilke arbejdsgange ændres? Hvilke leverancer bliver nye eller forsvinder?	Proceskort, user stories, kravspec, definition of done
Mennesker	Hvilke kompetencer mangler? Hvem mister/tilføjer ansvar? Hvad skaber modstand?	Stakeholderanalyse, kompetencematrix, træningsplan
Struktur	Hvem ejer processen efter go-live? Hvem godkender ændringer?	RACI, governance-model, mødeplan, beslutningslog
Teknologi	Hvilke systemer berøres? Hvordan måles drift og kvalitet?	Systemarkitektur, integrationsoversigt, testplan, driftskoncept

Sådan læser du sammenhængene mellem hjørnerne

Leavitts model bruges ofte forkert som en “tjekliste”, hvor man gennemgår fire felter og sætter flueben. Værdien ligger i forbindelserne.

Et praktisk greb er at vælge den ændring, der fylder mest (tit teknologi eller struktur) og derefter spørge: Hvad bliver påvirkningen på de tre andre hjørner?

• Skifter teknologien, ændres opgaverne: Hvad kan automatiseres, og hvad skal kontrolleres manuelt?
• Skifter opgaverne, ændres kompetencebehovet: Hvem skal oplæres, og hvem skal aflastes i en periode?
• Skifter strukturen, ændres samarbejdsflader: Hvilke beslutninger flytter sig, og hvor opstår ventetid?

En enkelt ubalance kan være nok til at skabe en kædereaktion. Derfor er modellen også et godt værn mod “lappeløsninger”, hvor man reparerer ét sted og skaber nye problemer et andet.

Brug modellen i praksis: tre arbejdsgange, der virker i projekter

Når du vil gøre Leavitts model operationel, skal den omsættes til konkrete aktiviteter. Her er tre måder, mange projektteams får hurtig effekt af den:

1. Lav en hurtig “nu og næste”-kortlægning: Beskriv nuværende situation og ønsket situation i hvert hjørne på én side.
2. Byg risikolog og ændringsplan ud fra hjørnerne: Hvis en risiko primært er teknologisk, så tilføj altid mindst én afledt risiko under mennesker, opgaver eller struktur.
3. Brug modellen som scope-værn i styregruppen: Når nye ønsker kommer ind, placér dem i diamanten og spørg, hvilke andre hjørner der skal ændres for at ønsket giver mening.

Det lyder simpelt. Det er også meningen. Styrken er, at du får et fælles sprog til at sige: “Ja, vi kan godt gøre det her, men så skal vi også gøre de her to ting.”

Typiske faldgruber modellen kan forebygge

Mange forandringer snubler over de samme mønstre. Leavitts model gør det lettere at se dem tidligt, mens det stadig er billigt at rette op.

Her er klassiske faresignaler, du kan holde øje med efter en projektworkshop eller en sprint review, når snakken mest handler om ét hjørne:

• Nyt system, men gamle arbejdsgange
• Uklare roller og dobbeltgodkendelser
• Træning planlagt “til sidst”
• Teknologi uden opgave-design: Løsningen er valgt, men ingen kan forklare den nye proces fra start til slut.
• Struktur uden kompetenceløft: Man flytter ansvar, men ikke viden, tid eller støtte til at løfte ansvaret.
• Opgaver uden driftsforankring: Projektet leverer, men der er ingen tydelig ejer efter go-live.

Listen kan bruges som en hurtig diagnose, når projektet mister fremdrift: Hvilket hjørne er vi blinde for lige nu?

Når diamanten ikke er nok: omverden og kultur

Leavitts model er bevidst enkel, og den ser primært på organisationen indefra. I mange projekter er det helt fint som start.

I praksis støder man dog tit på to forhold, der ligger udenfor eller mellem hjørnerne:

• Omverden: Lovkrav, leverandører, konkurrence, borgerkrav, sikkerhedskrav og økonomi kan ændre opgaver og teknologi over natten.
• Kultur: Normer, vaner og “sådan gør vi her” kan være den stærkeste styring af adfærd, også når strukturen på papiret siger noget andet.

Et enkelt greb er at tilføje en ring rundt om diamanten, hvor du samler de eksterne påvirkninger. Og når du arbejder med mennesker-hjørnet, kan du skrive “mennesker og kultur” som en påmindelse om, at motivation og normer sjældent kan adskilles.

Eksempel: nyt system i en projektorganisation

Forestil dig et projekt, der indfører et nyt CRM eller ERP. Projektet starter typisk i teknologihjørnet: licenser, konfiguration, integrationer, test og data.

Med Leavitts model kan du tvinge en mere realistisk plan igennem ved at stille fire sæt spørgsmål:

Teknologi: Hvilke funktioner skal være klare ved go-live, og hvad kan vente? Hvilke integrationer er kritiske?

Opgaver: Hvem registrerer hvad, hvornår, og med hvilken kvalitet? Hvilke trin i salgs- eller sagsflowet ændres?

Struktur: Hvem ejer masterdata? Hvem godkender rabatter, kreditter, eller ændringer i kundedata? Hvem prioriterer ændringsønsker efter go-live?

Mennesker: Hvilke roller rammes hårdest de første 4 uger? Hvad kræver træning, og hvad kræver træning plus sidemandsoplæring? Hvilke superbrugere skal have tid frigivet?

Hvis du kun styrer efter teknologiplanen, ser alt ofte grønt ud lige indtil organisationen skal arbejde i systemet. Når de fire hjørner planlægges samlet, får du en implementering, der også kan leve på en tirsdag i drift.

Skabelon til en workshop på 60 minutter

Hvis du vil bruge modellen uden at gøre det tungt, kan du køre en kort session med projektteam, linjerepræsentanter og evt. en nøglebruger. Sørg for at output bliver dokumenteret, så det kan blive til handlinger i planen.

Start med en kort problemformulering i plenum, og kør så diamanten igennem. Efterfølgende samler du “afledte konsekvenser” som konkrete opgaver.

• Formål: Afklare hvilke ændringer der følger med, når vi ændrer X.
• Post-its i fire felter
• Spørgsmål pr. hjørne: Hvad bliver anderledes om 3 måneder? Hvad bliver sværere den første måned?
• Top 5 afhængigheder: Hvilke to hjørner er mest sårbare, hvis vi rammer ved siden af?
• Aftal ejerskab pr. afhængighed
• Næste skridt i projektplanen

Det vigtigste er, at workshoppen ikke ender som en “snak om alt”. Brug tiden på at vælge de 5 til 10 konsekvenser, der er mest afgørende for at komme sikkert i mål.

Et enkelt spørgsmål, der ofte flytter mest

Hvis du kun tager én sætning med videre til dit næste projektmøde, så brug denne:

Hvilket hjørne betaler prisen, hvis vi ændrer det her uden at justere de tre andre?