2. Typer af teams og formål - introduktion til POUL-modellen
Ikke alle teams er ens – og det er meningen. POUL-modellen hjælper os med at oprette teams med tydeligt formål, korrekt type og klare navne. Her finder du introduktion til modellen samt eksempler, minimumskrav og en tjekliste, som skal sikre, at nye Teams lever op til kommunens standarder – og at vi undgår kaos og navneforvirring.
Formål og anvendelse af POUL-modellen
For at skabe klarhed, struktur og genkendelighed i brugen af Microsoft Teams arbejder Aabenraa Kommune med POUL-modellen.
POUL står for Projekt, Organisation, Udvalg og Ledelse – de fire primære formål og samarbejdsformer, som et team kan være oprettet til i kommunen.
Modellen anvendes både som styringsprincip for oprettelse af nye teams og som ramme for navngivning, ejerskab og adgang.
Den skal sikre, at vi undgår kaos i Teams, at vi genkender teamtyper på tværs af kommunen, og at det er tydeligt, hvad et team bruges til.
Teamtypernes formål og typiske brug:
- P – Projekt
Projekter, forbedringsinitiativer, faglige samarbejder, leverandørsamarbejde.
Tidsbegrænset, med tydeligt leverancemål. - O – Organisation
Dagligt og løbende samarbejde i faste organisatoriske enheder, fx et plejehjem, IT-afdelingen eller Jobcenter og Borgerservice. - U – Udvalg
Koordinering og samarbejde i faste faglige netværk, MED-udvalg, arbejdsmiljøgrupper, tværgående erfa- og udviklingsfora. - L – Ledelse
Strategiske ledelsesrum med faste deltagere, fx direktions- og chefgrupper, forvaltningsteams mv.
Rammer for match mellem teamtype og formål
Når et nyt team bestilles, skal formålet passe til den valgte teamtype.
Et mismatch mellem type og formål skaber forvirring, dårlige arbejdsgange og ringere søgbarhed.
Retningslinjer:
- Er formålet tidsbegrænset og med et klart leverancemål? → Vælg P – Projekt
- Er det en fast organisatorisk enhed? → Vælg O – Organisation
- Er det et fast udvalg eller netværk? → Vælg U – Udvalg
- Er det et strategisk ledelsesrum? → Vælg L – Ledelse
Gråzoner – sådan håndteres nogle af dem:
- Et udviklingsforløb med fast varighed og leverancemål → Projekt (P)
- Et tværgående samarbejdsforum uden fast organisatorisk forankring → Udvalg (U)
- En ledelsesgruppe, der også driver projekter → Ledelse (L) med særskilte projektteams (P) til de enkelte projekter.
Navnestandard – minimumskrav til kvalitet
Alle teams navngives efter en fast konvention for at sikre genkendelse og sammenhæng:
[Teamtypebogstav] – [Beskrivende formål]
Krav til navnet:
- Skal tydeligt afspejle formålet med teamet.
- Skal indeholde tilknytning: afdeling, skole, område, årgang eller lignende.
- Skal være unikt på tværs af kommunen.
- Må ikke indeholde forkortelser (medmindre bredt kendte) eller personoplysninger.
- For midlertidige teams: angiv årstal eller projektperiode i navnet.
Eksempler på dårlig vs. god navngivning
Skoleeksempel:
- Dårligt: 4B → For generisk, ingen tilknytning.
- Dårligt: 4B Kongehøjsskolen → Bedre, men ingen årgang angivet.
- Godt: 4B Kongehøjsskolen 25/26 → Tydelig tilknytning, årgang, unikhed.
Projekteksempel:
- Dårligt: Ny hjemmeside → For bredt, ingen kontekst.
- Godt: Ny hjemmeside Hjælpemiddelhuset 2025 → Klart formål, kontekst, årstal.
Udvalgseksempel:
- Dårligt: Arbejdsmiljø → For generelt, ingen tilknytning.
- Godt: Arbejdsmiljøudvalg Pleje & Omsorg → Klart formål og organisatorisk kontekst.
Tjekliste ved behandling af bestillinger
På artikelsiden Struktur, oprettelse og adgang kan du læse, hvordan teams bestilles og oprettes. Når en bestilling på et nyt team modtages, skal følgende vurderes:
- Er teamtype korrekt? Matcher formålet den valgte POUL-type?
- Er formålet tydeligt? Er det klart beskrevet i bestillingen?
- Er navnet entydigt og unikt? Kan forveksling med andre teams undgås?
- Er tilknytning angivet? Afdeling, område, årgang eller tilsvarende.
- Er årstal angivet for midlertidige teams?
- Er der forbudte elementer? Forkortelser, personoplysninger, specialtegn.
- Overholder navnet kommunens navnestandard fuldt ud?
Hvis et af punkterne ikke er opfyldt, skal bestillingen sendes retur til rekvirenten med begrundelse og forslag til rettelser. Ved mindre rettelser kan behandler i IT vælge at justere det selv i blanketten og godkende.
Konsekvenser af dårlige navne
- Vanskeligt at finde det rigtige team.
- Navnekonflikter ved nye oprettelser.
- Dårlig genkendelighed på tværs af kommunen.
- Øget forvirring om formål og ejerskab.
- Mindre effektivt samarbejde.