Godmorgen og velkommen til vores webinar om praktisk programledelse. Vi har glædet os utrolig meget til at holde det her webinar, hvor vi har halvanden, hvor vi skal tale om, hvordan vi får flere store transformationsinitiativer og programmer til at lykkes bedre. Dengang, hvor vi skrev vores bog, der tænkte vi, hvordan kan vi komme til at gå fra det teoretiske over mod det praktiske, så vi kan løse nogle af de problemstillinger, vi ser rigtig mange programmer, de lider under. Så ambitionen er simpelthen for os, at I lykkes bedre. I bliver inspireret til, hvordan I kan gribe jeres praksis an, og I får konkrete idéer til, hvad I kunne gå hjem og lave om. Og da vi skrev bogen, så var vi også ude og interviewe en masse, hvad hedder det, mennesker, som arbejder med store programmer af alle mulige forskellige slags. Og noget af det, det er også det, vi bringer med ind i seminaret, hvor I er til, at vi kunne se, der står et lille citat rundt omkring på nogle af de billeder, vi viser. Så det er rammen for, hvad vi skal igennem her til morgen. Vi har nogle målsætninger for, hvad vi godt kunne tænke os at tage jer igennem. Og det ene er selvfølgelig at give en introduktion til vores bog og til det rammeværk, som vi har bygget op. Det er den her. Bogen. Bogen. Yes. Og så vil vi gerne dykke ned i nogle udvalgte værktøjer, fordi vi når selvfølgelig ikke at gå igennem hele bogen på halvanden time. Og hvis vi kunne skabe et rum for en dialog og et fagligt netværk, og et fælles sprog, som I kan få glæde af derude, så vil vi faktisk være rigtig glade. Så det er jo det, vi ønsker os. Formatet er ikke til, at I kan stille spørgsmål i døbet af webinaret. Men hvis I nu sidder og tænker, hvad kunne det være rart, hvis jeg kunne få lov at spørge om det her, så skriv det i chatten. Så lover Mikkel og jeg, at vi besvarer det og sender svarene ud til jer alle sammen. Så det er helt legitimt at skrive løs i chatten. Hvis I skriver rigtig mange ting i chatten, så kan det godt være, at I ikke lige får det i eftermiddag. Vi lover, at vi besvarer spørgsmålet. Så giv den endelig gas. Godt. Så må vi jo hellere præsentere os også lidt. Vil du ikke starte? Jo, det kan du tro. Tak for det, Helle. Jeg hedder Mikkel Lav, og sjovt nok, så kan man sige, at jeg arbejder med store, typisk offentlige transformationer og programmer. De sidste mange år har det haft en væsentlig grad af fokus på den grønne omstilling. Altså, hvordan får vi nogle af de her meget store infrastrukturinvesteringer til at lykkes? Typisk så er der også i det, jeg laver, sådan en meget tydelig politisk ambition og deadline, samtidig med, at der er noget konkret, der ligesom skal fungere nede i leveransorganisationen, nede i projekterne. Så det er sådan, det er det, jeg har fokus på. Været konsulent i næsten halvdelen af mit liv, og altid arbejdet med projekter og programmer. Så I kan høre, Mikkel er stadig juniorkonsulent. Jeg hedder Helle Faldholdt. Jeg er partner i Implement. Jeg er lidt ældre end Mikkel. Jeg har også bukt mit liv til at arbejde med rigtig store transformationer. Og det gælder både infrastrukturtransformationer og også den grønne omstilling, men især også digitale transformationer og organisatoriske store ændringer. Og den erfaring, vi har sammen med Signe, som ikke kunne være her i dag, som også er partner i Implement og også arbejder med store transformationer, det er, at det er de samme problemer, der går igen og igen på tværs af programmerne, uanset egentlig, hvad det er, de skal levere, når det kommer til, hvordan vi griber dem an. Og det er jo så faktisk det, vi skal snakke om i dag. Vil du tage agendaen? Ja, det kan du tro. Jeg klikker lige fremad der. Og hvis vi tager vores agenda, så lægger vi sådan set ud med at give jer en introduktion til vores rammeværk i forhold til praktisk programnedelse. Og det vil sige, hvad er logikken bag? Hvad er det for nogle, man kan sige, fordele, der kan være ved at arbejde ud fra den her logik? Og også giver jeg sådan lidt et indblik i, hvordan sådan et program grundlæggende er bygget op og hvordan det styrer sig ledes. Så det er sådan det, vi bruger de første 20 minutter på. Så har vi sådan taget to steder, vi tænker, vi vil gerne gå dybt. Det er i forhold til to sådan, man kan sige, noget af det, der er svært i programmer, det er et, at ligesom få afgrænset programmets skob. Det vil sige, hvad er det, vi i programmet skal lave? Og også sådan få styr på de grænseflader, der er mellem programmet og linjeorganisationen. Det bøvler rigtig mange steder, og det er sådan en af de temaer, vi har taget med, og som også fylder i bogen. Det andet tema, vi har taget med, det handler om, hvordan programmer organiseres. Fordi når noget er stort og komplekst, så har det jo også en masse mennesker i sig. Så det der med, hvem beslutter hvad, hvornår, hvordan er det organiseret i forhold til dem, der skal beslutte, dem, der skal udføre, dem, der skal lede. Så det der med at give jer nogle af, jeg vil kalde det, de taktiske overvejelser i forhold til, hvordan du organiserer dit program, det har vi også taget med. Fordi vi igen har oplevelsen af, at det er noget af det, der rigtig tit bøvler. Og så kan man sige, at det sidste, vi gør, det er, at vi har sådan, vi har formuleret 11 hacks. Altså sådan gode anbefalinger, synes vi, som du ikke vil kunne finde i en lærerbog, som også er lidt kække, men som er super erfaringsbaseret, og som også har lidt kant i forhold til, hvad vi synes, at I skal gøre i rollen som programledere, eller som en del af et programs organisering. Vi slutter seneste 10.30. Det lover vi, fordi det er også sådan, at der er sikkert en masse af jer, der har et møde lige bagefter. Så bagkanten er 10.30. Så det er det program. Ja. Og vi vil gerne lige starte med, man kan sige, noget omkring, hvad er det for en tilgang, vi skal have i forhold til det at lede et program. Og i forbindelse med, da vi skrev bog, så som Helle siger, eller sagde, så var vi ude at interviewe en række programdirektører, ejere, programledere, også sådan, hvad kan jeg sige, programsponsorer, så beslutningstager og ledelseskræfter i programmet. Og en af dem havde sådan en citat, som vi synes er meget rammesættende, og meget sådan, giver et meget godt billede af, hvad er det egentlig for en, hvad er det for en tilgang, du skal have til det at lede et program. Og nu læser jeg det simpelthen op for jer. Det at arbejde med programmer kræver tre ting. Det kræver mod, det kræver humor, og så kræver det kærlighed. Og kærlighed, det er vigtigt. Mod, og det er fordi, du ikke kan forudse, at du bliver simpelthen nødt til at tro på, at du har de rigtige kræfter ombord. Du skal sætte et hold, der har erfaring, selvtillid, mod og tro. Der skal være en holdning til programmet, som en spændende udfordring, vi i fællesskab skal løse. Der skal skabes en kultur, hvor man byder det uforudsete velkommen og tror på, at man kan løse det sammen. Det er mod. Så er der humor, fordi der ofte vil være mange udfordringer undervejs. Og det der med, når vi har det sjovt sammen, så skabes der en gejst i programmet, som sikrer, at energien opretholdes undervejs. Og jeg vil også sige, at sådan set skaber en intern sammenhængskraft i sådan et program, der lever i mange år. Og så kærlighed. Fordi vi i programmets levetid skal kunne fagne mange forskellige aspekter og persontyper og agendaer og dagsordner. Og der vil være mange forskellige vinkler på programmet. Og man skal simpelthen ikke være for nærtagende, fordi man skal kunne fagne bredt. Og det er jo også det, der er med programmer. Typisk så rammer de lige ind i kerneforretningen. Det er en stor transformation. Så der er rigtig mange, der har interesser på spil i forhold til sådan et programs gennemførelse her. Så det siger noget omkring, hvad er det egentlig for et mindset, som vi synes, man skal tilgå programledelses, og det at være et program med. Lad os lige prøve at kigge på, hvad er det egentlig, vi taler om, når vi taler om programmer. Og senere, der kommer vi også lidt dybere ned i kendetegn. Men vi vil egentlig godt starte med at bare give tre eksempler på programmer. Det her, det er i forhold til etablering af energiøerne. Altså, der er en energiø på Bornholm. Der er en energiø i Nordsøen. Og det er noget af det, vi har været involveret i. Og man kan sige, lige nu, så er der kommet fuldt tryk på energiø Bornholm igen, mens Nordsøen der, den ligger stadigvæk i forhold til det at skulle finde legekammerater i de andre europæiske lande. Men hvis vi lige tager det her program, så kan man sige, så er det kendetegnet ved, at der skal bygges noget fysisk, en station, nogle kabler. Så der er en samlet løsning. Men samtidig med det, så er der sådan set også nye tariffer, budzone, også ny lovgivning. Der skal laves en helt ny driftsorganisation omkring det her. Og det er bare for at sige, at når vi taler om programmer, så er det jo flere parallelle projekter, der skal levere et samlet gevinst og arbejde mod nogle samlede mål. Men lige netop det her program, kan man sige, er kendetegnet ved at have en samlet løsning, og så er der en række andre indsatser og projekter, som sådan set skal lykkes for, at det kan drifts. Det er energiørende. Ja. Vil du? Det kan jeg godt. Ja. Denne her kommune, det er en stor dansk kommune, har en ambition om at blive CO2-neutral. Og det er altså ikke kommunen og kommunens egen organisering, vi taler om. Det er byen. Og når man skal gøre det, så ved man ikke nødvendigvis alt, hvad der skal til fra dag et. Så det er en helt anden måde at køre et program på, hvor man må sige, at her der har vi en fælles målsætning, og vi ved, hvad vi ønsker at skabe værdi, men vi ved faktisk ikke helt præcis, hvad alle skal levere. Der er nogle idéer, men det vil også udvikle sig over tid, fordi når man arbejder over mange år mod det her mål, så opstår der jo også nye muligheder for, hvordan man kan arbejde med at blive CO2-neutral. Og der sidder kompetencerne ude i de enkelte forvaltninger, eller magistrater, som denne her kommune kalder det. Og det er dem, der egentlig arbejder med helt konkret, hvad skal løsningen være, når vi kigger på skoleområdet, hvad skal løsningen være, når vi kigger på vores ejendomme, osv. osv. osv. og transport og alt muligt andet. Så det er en helt, helt anden måde at arbejde på i forhold til energiørende. Denne her, det er supersygehuset i Køge, der er under opførelse, og det er faktisk det supersygehus, der indtil videre i hvert fald og til synligere også kommer til at faktisk holde budgettet. Det er meget usv. Og det siger du, fordi du har været involveret inde? Det er ikke derfor, de holder budgettet, men man kan jo godt lave lidt reklame for nogen, man holder af. Det her, det er jo også et kæmpe stort program. Fordi en ting er, at her skal jo også rejses noget fysisk, og det er givet, hvordan bygningerne, hvor mange der skal rejses, hvor mange etager og alle de der ting. Men når de nu bygger, så bygger de for, at man også skal arbejde på en anden og bedre måde. Bedre for dem, der bliver indlagt, men selvfølgelig også bedre for medarbejderne, der skal bruge det her hospital. Så for eksempel på logistikssiden, jamen der skal man pludselig til at tænke helt anderledes. Der er det ikke det enkelte afstit, der skal købe deres egne udstyr, og nu skal man have et fælles udstyrsordning for eksempel. Og det lyder måske som, nå ja, hvad så? Men det er faktisk en ret stor forandring. Og det kan jo opleves på forskellige måder, at dem, som pludselig ikke har deres eget budget, og ikke selv bestemmer, om de vil købe det ene eller det andet. Så der er et meget, meget stort forandringsledelseselement, og det er der selvfølgelig også, de andre programmer, men her, der er det måske mere fremtrædende, end man umiddelbart tror, når man tænker, at vi får virkelig, virkelig travlt med at rejse de her bygninger. Fordi de virker jo ikke uden alle de digitale løsninger også fungerer. Så det er tre meget forskellige typer af programmer, som I ser her, men de har noget til fælles. Og det, som vi tænker, de har til fælles, det er jo blandt andet det, der ligger til grund for, at vi tænker, at vi kan godt skrive en bog, der adresserer alle de her forskellige problemstillinger, der er i meget forskellige artede programmer. Ja, så er det dig igen, Henne. Det er det faktisk. Så når vi nu står og siger, at I skal arbejde en programledelse, og det er en klar anbefaling fra vores side, så er det selvfølgelig, fordi der er nogle fordele forbundet med at gøre det. Og I kan se her, en af tingene, det er, at man får en effektiv organisering. Rigtig mange programmer, de lider af, at der ikke er tilstrækte beslutningskraft, der er ikke effektive beslutningsprocesser, der er ikke tydelige mandater på de forskellige niveauer i organisationen, og det gør, at programmerne ikke har den fremdrift, som man kunne ønske sig. Og at det jo også nogle gange betyder, at beslutninger bliver truffet af de forkerte mennesker på det forkerte grundlag. Så det er en af de store fordele, der er her ved det. Og det er jo ikke, fordi vi siger, at det skal være superbyråkratisk osv., men der skal være et vist nødvendigt byråkrati i det, for at vi er sikre på, at vi gør tingene effektivt. Så er der også noget med at have et ordentligt strategisk afsæt og forankring. Mikkel sagde tidligere, at det her, det er jo meget, der er jo en politisk dagsorden ofte, eller også er der i hvert fald en strategisk dagsorden med de programmer, vi kigger på. Og det gælder jo i virkeligheden også, både offentlige og private programmer. Og det at have det afsæt og sørge for, at der er en sammenhæng mellem den ambition, man har, og de målsætninger, der så er for programmet og det, som programmet leverer, det er en af de helt store fordele, ved at arbejde med programledelse. Så er der også noget med en forankring af initiativets løsninger i forhold til dem, der rent faktisk skal bruge det. Og nogle gange, så er det jo på tværs af organisationer, at der vil være en påvirkning af det, som vi laver i programmerne. Så det at få det forankret så tidligt som muligt ude hos dem, der rent faktisk skal anvende det, vi laver, det betyder utrolig meget. Dels for, at vi laver en bedre løsning til dem, men også for, at de har mulighed for at forberede sig og få det implementeret godt. Og så er der en ting, som mange programmer også lyder af. Det er det her med, hvor langt er vi egentlig kommet? Hvor mange penge har vi brugt, og hvad har vi brugt penge på? Og bliver vi færdige til tiden, og har vi det hele med osv.? Så det her med at kunne skabe en ensart styring og ledelse på tværs af et program, det kan virkelig redde en fra rigtig, rigtig mange problemstillinger. Og det betyder også, at man har mulighed for det sidste, nemlig at få et samlet overblik over realisering af de gevinster, som man skal realisere. Hvad er det for en fremdrift, vi har? Og hvordan ser vores økonomi egentlig ud? Så for at få de her fordele, der har vi lavet et rammeværk. Og det rammeværk, det har tre elementer. Og det er ikke sådan, at først laver man det ene, så laver man det andet. De her elementer er i spil samtidig. Fordi det hele, det starter og slutter sammen. Og I kan se, der står i lige citat under overskriften, der står, at der er mindst 50 ting, der skal besluttes, før man ringer til IT. Det er der nogle IT-direktører, der ikke er helt enige i. Men det er bare lidt om at sige, at nogle gange går man for hurtigt til løsningen. Og det er faktisk en af vores pointer i bogen. Det er, at man skal have styr på det første element her, der hedder programmets ambition og indhold. Og selvfølgelig er der IT, der digitaliserer i stort set alle de programmer, vi har med at gøre, i større eller mindre grad. Men det handler rigtig meget om, at vi får lagt et grundlag for, at vi kan styre vores scope, og vi har styr på, hvad det er, vi ønsker at opnå med programmet. Så når vi så siger, at man skal starte med en vision, så er det en vision, som folk kan se sig selv i. Det er en, der inspirerer en. Det er en, der siger, at det ser fedt ud, det vil vi gerne. Men det er også den første afgrænsning af programmet, når vi siger, at det er det her, der er visionen, og ikke alt muligt andet. Og måden, man så kommer videre på, det er ved at konkretisere den til at sige, jamen, hvad er det så for en værdi, vi ønsker at skabe, når vi nu skal opfylde denne her vision? Så er der nogen, der siger, prøv at høre, vores problem, det er faktisk, at vi har nogle gamle IT-systemer, så vi skal bare have nogle nye. Jamen, når I nu i livet skal ud og bruge flere hundrede millioner og genere hele jeres organisation, så er det måske meget godt, I lige tænker i, hvad kan vi opnå, når vi nu alligevel synes, vi skal gøre det? Og det er derfor, at vi synes, at vision og gevinster, de hænger sammen, og de påvirker hinanden, og de er super vigtige at være tydelige omkring begge dele. På den baggrund, der kan man begynde at konkretisere, hvad er det så, vi skal bygge for at kunne høste de gevinster og opfylde den vision, som vi har sat os. Og det er det, vi kalder en fremtidsmodel. Og det er sådan en kært barn har mange navne, og det er et af de værktøjer, som vi dykker mere ned i i dag, så det venter jeg lige med at gå i dybden med, hvad det kan. Men noget af det, det kan dog, det er, at det er programmet scope. Det her, det er vores ambition for, hvad der skal leveres og bygges for det her program, for at organisationen kan implementere det godt og høste de gevinster, som vi ønsker os. Og det er jo også det, hvad hedder det, produkt, som vi bruger, når vi så siger, hvad er det så for nogle projekter, vi fornuftigvis kunne starte, og hvordan skal vi sætte scope'et for dem? Og det gør det muligt for os, at have et projektoverblik fra dag et. Det kan godt være, at vi ikke ved alt, men vi ved, at der er nogle projekter, der skal lave forskellige ting af det her. Nogle af dem skal måske først starte om et år eller to, så de er ikke super veldefinerede i dag, men vi ved sådan cirka, hvilke dele af vores fremtidsmodel, vi skal bygge. Og baseret på det, der kan vi så begynde at lave en programplan, som rent faktisk hænger sammen, og hvor vi kan tage højde for afhængigheder mellem projekterne og alt muligt andet, vi kommer til at tale lidt om senere. Og både gevinster og programplan er selvfølgelig noget af det, der giver vigtigt input til den business case, som vi skal lave, som der jo altid er i sådan nogle store programmer her. Og det vi tit oplever, det er, at det her element er underprioriteret. Man har simpelthen tænkt over, at vi skal i gang med den her ambition, og den er vigtig, og der er en vis utølmodighed. Og det betyder, at vi ikke har lagt et godt fundament for vores program og fundament for at styre det og for at sikre, at vi leverer det rigtige. Og vi har mulighed for at styre, når det, der er det rigtige, det ændrer sig over tid. Og det vil det jo gøre, hvis programmet løber over mange år. Så det er noget, vi virkelig gerne vil slå til lyd for. Det er tid nok i den øverste, og det er det citat, der er rettet imod. At ledelsen er ikke færdig, når de har lagt en strategi. De skal være involveret i det her også. Det næste element, det er organisation og styring. Og det er jo selvfølgelig fordi, som Mikkel startede med at sige, at det er noget af det, der bøvler rigtig meget i rigtig mange programmer. Så hvordan skal vi organisere det? Og hvilke roller og ansvar skal vi have? Og der er mange organisationer, der har sådan noget beskrevet. Men det, man jo skal være opmærksom på, det er, når vi er ude i denne her type initiativ, og så skal det tilpasses. Så hvad er egentlig behovet for lige præcis det her program i forhold til, at vi får organiseret os effektivt, og folk de ved, hvad de skal byde ind med? Og hvad er det så, når vi nu så skal styre det her og levere det, som vi lagde fast i det første element? Hvad er det styrings- og ledelsessæt-op, vi skal have lavet? Så hvordan skal vi arbejde? Hvordan skal vi planlægge vores projekter? Hvordan skal vi rapportere fremdrift? Hvad har vi af krav til os udefra om, at vi skal kunne køre redde for, hvor langt vi er kommet, og hvad vi bruger pengene på, osv. osv. osv. Det er super vigtigt, og det kommer vi også til at tale lidt om, når vi snakker organisering, fordi det har også noget at gøre med ens modenhed som organisation. Hvor mange gange før har vi lavet noget, der ligner det, vi skal nu? Så kan vi ligesom sige, at det har vi 100% styr på, fordi det har vi prøvet mange gange før. Velviden af alle programmer er forskellige, eller er det her måske første gang, man kaster sig ud i noget, der er så stort og komplekst og kommer til at berøre så mange mennesker. Og så er der motoren i vores program, nemlig PMO'et, som ofte oplever vi ikke er tilstrækkeligt bemandet, fordi man måske lægger for lidt vægt på, hvor vigtigt det er at have en enshejl, styring og ledelse, og så skal der være nogen til at få det til at fungere. Og det er det, som PMO'et gør. Det tredje element, det adskiller sig jo fra de to andre ud over indholdet. Det handler om, hvordan får vi det, der bliver leveret ud at leve i organisationen, får lavet en god organisatorisk implementering, så det ikke bøvler for meget i processen for modtagerorganisationerne. De bliver godt forberedte, de tager godt imod det og er i stand til at glide over i den nye måde at arbejde på, uden at det bliver for svært for dem. Og det element adskiller sig blandt andet fra de andre ved, at her er vi jo ikke længere alene hjemme som program. Det her er noget, vi som for eksempel programledere kan understøtte, men det er jo modtagerorganisationen selv, der skal gennemføre det. Og her har vi lagt vægt på fire elementer, og det ene er at skabe ejerskab. Skabe ejerskab egentlig er i programmet, men også ude i organisationen for den forandring, der skal ske og de gevinster, der skal høstes. Og så skal vi have skabt tillidsbaserede relationer. Og det hænger jo lidt sammen med det citat, Mikkel startede med, at man skal altså have en kultur og en organisation, hvor organisationen opfatter det, vi laver som værende. Vi gør det for jer. Det er ikke for vores skyld, det er for jeres skyld. Så skal vi kunne forberede implementeringen og kommunikere effektivt. Og det er super vigtigt, og igen, det er noget, vi kan understøtte. Vi kan tilbyde struktur, vi kan tilbyde værktøjer osv. Og hjælp. Det er organisationen selv, der skal være med til at drive det her. Og så er der hele den effektive træning. Så med et fast blik for, hvad er det for en hverdag, vores brugere, dem, der skal anvende det, vi laver, kommer til at sidde i på den anden side og tage udgangspunkt i det i forhold til træningen. Hvis I tænker, hvordan har de fundet på, at det lige skulle være de her fire, så bygger det faktisk på et samarbejde, vi har med University of Oxford, der har lavet noget research sammen med Implement, der siger, hvad er de vigtigste og mest signifikante faktorer, der skaber god implementering og forandringsledelse. Og det er faktisk de her fire, som vi tilfældigvis er rigtig, rigtig enige i og har nogle idéer til og værktøjer til i vores bog, hvordan man kan arbejde med. Som I kan se, så løser vi ikke alle verdens problemer med det her. Men vores påstand er, og det er erfaringsbaseret fra Mikkel og mig og fra Signe, det er, at hvis vi får løst de her problemer, så er der mange af de andre problemer, som bliver nemmere at takle også. Så det er lidt af en påstand. Ja, men omvendt, så er det også at sige, at hvis vi sådan set har styr på kasserne her i modellen, så synes vi, det er et rigtig godt fundament for det arbejde, der skal ske i programmet. Det vi ved nu, det er at lige give jer et overblik i forhold til sådan et programs gennemførelse her. Hvordan ser livscyklus ud? Og man kan sige, at den skarpe læser vil se, at hvis man nu tog en helt klassisk projektmodel og sammenlignede med sådan en programs livscyklusmodel her, så er der ikke den helt store forskel. Altså, vi gennemfører i nogle faser. Det sagt, så er der en ret stor forskel, som ligger i det, vi har kaldt den tredje fase. Vi gennemfører i bølger. Nemlig den måde, vi går til gennemførelsen af programmet på, hvor vi deler programmet op i mindre bidder. Og det kommer jeg tilbage til lige om lidt, som vi kalder bølger. Men hvis vi lige kigger på den her, så har vi taget den med, fordi vi bliver tit spurgt om, hvordan får du egentlig etableret dit program? Og hvad skal jeg regne med i forhold til, hvor lang tid ting tager? Og hvor mange mennesker skal være engageret i det her undervejs? Og der kan man sige, at det her er vores normative bud på det. Hvis vi tager idéfasen, så er idéfasen gennemføres tit ude i linjeorganisationen eller i forretningen i forhold til at modne en idé omkring en større transformation, man gerne vil gennemføre. Så det vil sige, at i idéfasen her, der er programmet sådan set ikke etableret endnu. Det er stadigvæk en idé, der udfoldes, modnes, beskrives. Og hvis vi kigger på, hvor det sker henne, det er det, der står i fjerde række, så udføres det typisk på politisk niveau eller strategisk topledelsesniveau. Der er selvfølgelig nogen, der skal drive det, så der sidder et lille team af det. Og det, som vi har fokus på der, det er at få formuleret en vision, et formål, og også, man kan sige, få formuleret sådan en indledende bud på de her gevinster, som programmet skal realisere. Det er også her, vi laver det, man kunne kalde en high-level udkast til business case. Det er her, vi taler om, så når vi skal gennemføre det her program, hvordan vil vi så organisere det? Det vil sige, det er her, vi udarbejder det indledende billede af programmets organisering. Det vil sige, hvem der skal være programejer, programleder og så fremdeles. Og så, det vi også gør, det er, at vi kigger på, hvad sker der allerede i organisationen, som sådan set smager af det samme tema, som det her program eller den her transformation indeholder. Så det er idéfasen, og den tager sådan typisk fra 1 til 12 måneder, alt afhængig af størrelse og kompleksitet. Men pointen her er, det er typisk en mindre gruppe, der arbejder med det her. Så går vi ind i etableringsfasen. Og det er jo så her, vi skal få konkretiseret programmets indhold, og også, hvad er det egentlig, vi ønsker at opnå, og hvad skal det koste? Så det er her, vi går dybere i analytisk mode. Og hvis I kigger ned i vejheden her, så vil det typisk være fra 6 til 12 måneder, igen, alt afhængig af størrelse og kompleksitet. Der vil være nedsat et, man kan sige, et programsorganisering. Det vil sige, der er en styregruppe, en programleder, og så er der igen et mindre team. Og her, der er det vigtigt også, at selve modtagerorganisationen eller linjeorganisationen er meget tæt på i forhold til at være medskabende af de, du kan sige, ledelsesprodukter, der ligger i etableringsfasen. Det vil sige, og hvis man sådan skulle sige, hvad er det for nogle ledelsesprodukter, jamen så er det at blive tydeligt på gevinster. Det er udformet en fremtidsmodel. Herunder får I identificeret de projekter, initiativer, der ligger i programmet. Udarbejde et business case. Fastlægge programmets organisering i forhold til, når vi skal gennemføre i bølger. Og så få etableret et styringssæt op. Så det er det, der sker i etableringsfasen. Og så går vi sådan set over i programmets, man kan sige, der hvor vi udarbejder, udvikler leverancer og implementerer dem i linjeorganisationen. Og det deler vi op i bølger. Det kommer jeg tilbage til om et øjeblik. Og så den sidste ting, det er at få det lukket godt ned. Og noget af det, der tit går galt i det, det er, at man sådan set bare mic drop, når programmet er afsluttet. Og så får vi ikke rigtig sådan set samlet op, dokumenteret, får også, hvad hedder sådan noget, lukket godt ned i forhold til alle de mange mennesker, der har bidraget ind i programmets gennemførelse. Hvis vi lige tager det der med at gennemføre i bølger. Man kan sige, at programs gennemførelse, det består af en eller flere bølger. Og når vi taler om det der med at arbejde i bølger, så er ambitionen eller intentionen i det, det er at dele programmet op i mindre bidder, hvor vi i hver bid leverer en eller flere kapabiliteter. Altså, og med det menes med kapabiliteter, at når vi er færdige med bølgen, så er organisationen sådan set i stand til at kunne gøre noget nyt. Det vil sige, at vi tager hver bølge hele vejen fra udvikling, gennem implementering og over i gevinstrealisering. Så det er sådan logikken i forhold til det at arbejde med bølger. Og hvis vi lige sådan kigger på, hvad er det så vi gør i hver bølge? Jo, tanken er, at vi skal levere værdi i alle bølger. Det vil sige, at når vi afslutter en bølge, så kan vi sådan set også afslutte programmet, fordi vi har lavet noget, der er selvbærende. Vi kan godt lide at dele tingene op i mindre bidder, fordi så kan vi sådan set følge fremdrift og også vurdere effekten løbende. Vi kan skabe en synlighed omkring, hvad er det for en værdi, hver bølge skal levere. Vi skaber rum til, mens vi gennemfører den ene bølge, sådan set at have hæveblikket i forhold til, hvad er det, der kommer fremadrettet, vi skal gennemføre. Så vi kan sådan set også indarbejde nye idéer undervejs og reagere på de ændrede omstændigheder, der er. Og alt det, kan man sige, det er sådan set det, vi gør i bølgerne. Og en lille ting, som I kan se ude i højre side af den her figur, fordi I kan se, der er sådan farver i forhold til bølgens gennemførelse, i forhold til modning, planlægning, gennemførelse af projekter og opgaver, implementering af leverancer, og så vurdering og justering. Det er nemlig farverne i forhold til de røde på modtagelsenstationen, og man kunne kalde dem laksefarver måske, i programmet. Og det, den viser her, det er noget omkring, hvem er det egentlig, der har ansvaret i de her enkle dele af bølgens gennemførelse. Hvor vi starter med, at der er et ret stort ansvar og drive, kan man sige, fra programmet og programmets organiseringsside, til at når vi gennemfører projekterne og opgaverne, så er det sådan set ligeværdigt. Altså, modtagelsen og programmet leverer begge dele ind i gennemførelsen af det her. Og når vi går over til implementering og gevinstrealisering i det, så er det sådan set modtagelsen, der typisk har ansvaret for at drive forandringen. Selvfølgelig understøttet af programmet, men det er rigtigt der, det er fra modtagelsen, at de fleste ressourcer kommer fra. Og det er jo en af årsagerne til, at vi anbefaler, at man gennemfører programmet i mindre bølger. Det er jo også for, at det ikke skal være så hårdt for modtagelsen. Altså, i stedet for, at de skal vente mange, mange år, så får de en kæmpe forandring, de skal gennemføre på kort tid. Så det her, det er meget mere skånsomt over for modtagelsen, plus de oplever, at der sker noget. Altså, vi får værdi hele tiden. Det er en enorm indsats for modtagelsen at lave denne her type programmer. Så det i sig selv er en årsag til, at det er en god idé at arbejde med mange implementeringsbølger i virkeligheden, som ligesom påvirker organisationen i mindre grad, men løbende, så de hele tiden også føler, at de er med, og de får noget tilbage. Ja. Så det her, det er sådan set, nu får du den her, Helle. Men det er sådan set introduktionen til både sådan logikken, hvad er det, der er af værdi i det at arbejde med programledelse, vores rammeværk i forhold til vores programmodel, og så sådan lige et overblik i forhold til sådan en programs gennemførelse, det er et arbejde i bølger. Det vi gør nu, det er dig. Ja. Det er, at nu vil vi dykke ned i nogle fokusområder, og der lovede vi jo at tage fat i to ting. Og det ene, det handler om programmets skåb og afgrænsninger, og det er det, som jeg vil tage fat i. Og nogen af jer kan muligvis genkende noget af det, der dukker op nu her. Når vi skal starte programmet, så er der stor utålmodighed hos ledelsen, for de har sådan set drøftet det her måske i rigtig lang tid. Så vi må hellere se at komme i gang. Og det er faktisk det aller største røde flag, man kan have, det er, at der er et pres på, at vi skal begynde at levere, at vi må starte nogle projekter. Og det er der, at det her med skåb og grænseflader, det begynder at blive rigtig svært, fordi så har vi ikke overblik, men vi starter nogle af de projekter, som vi godt ved skal starte, men vi får ligesom startet dem lidt i siloer. Og det giver os, det er faktisk roden til alt lånt, vil jeg sige, næsten. Men i hvert fald en hel del ballade rundt omkring i store programmer, når vi kommer ind og kigger på dem, fordi de arbejder i siloer, og det hænger ikke sammen på tværs. Så vi starter projekterne, masser af dygtige medarbejdere bliver sat ind og gør deres allerbedste. Vi er faktisk i tvivl om, at vi er det ene med. Fordi vi jo netop skyndte os lidt at gå i gang og startede det her projekt. Så det er det ene problem omkring programmet skåb, det er, at det faktisk ikke er veldefinerede for toppen. Det andet, vi så oplever, det er, at projekterne lever hver sær, men leverancen hænger ikke sammen på tværs. Så man kan have lidt den fornemmelse, som vi illustrerer med det her billede. Det er fem projekter. I kan se, at der er huller ind imellem. Det er der ikke nogen, der laver noget ved. Og så de der projekter, de lapper over hinanden. Fordi de sidder jo hver sær og arbejder efter bedste evne og vil lave noget fedt til modtagerorganisationerne. Og så ved de jo, at når vi laver det her, så skal vi også lige lave det her over. uden egentlig at have det fulde overblik over det, der faktisk et andet projekt, der også er i gang med at lave. Og det er noget af det, der er svært, hvis ikke man får defineret programmets samlede skåb på en fornuftig måde helt fra starten af. Og så siger man, okay, det fik vi ikke gjort, så kan vi ikke bruge det her til noget. Jo, det kan I godt. Det er aldrig for sent at gå ind og kigge på det her. Fordi det her, det er jo sådan, okay, hvad er skåbet? Har vi det hele med? Kan vi finde ud af at dele det op, så vi ikke har flere projekter, der prøver at levere det samme? Så er der jo også et eller andet med, at hvis ikke man får det planlærer, at man har styr på grænsefladerne. Og her snakker vi de interne afhængigheder mellem projekterne. Så risikerer man faktisk at forsætte sit eget projekt, fordi man får startet dem i forkert rækkefølge. Og nogle gange starter man måske ikke engang med det vigtigste. Man starter bare med det, man vidste, man skulle lave. Og så bagefter finder man, gud, det havde vi egentlig ikke behøvet at lave nu. Det havde egentlig været vigtigere, at vi startede et andet sted. Plus, hvis vi står i vejen for hinanden, så har Mikkel pludselig ikke frigivet de der ressourcer, jeg skal bruge i mit projekt. Og så har jeg otte mand siden, der ikke kan lave noget, fordi vi mangler de to, som Mikkel skulle frigive, men han er ikke blevet færdig. Så det er sådan nogle ting, der også sker i programmer, hvis ikke man har ordentligt styr på skåbet og får delt projekterne ordentligt op og planlagt godt i forhold til hinanden. Så er der denne her, som også er svær. Det kan godt være, at programmet leverede som planlagt, at modtagerorganisationen var ikke klar. Så hører man sådan nogle modtagerorganisationen siger, hvorfor er det, I ikke har forberedt os på, hvad det egentlig var, vi skulle tage imod? Vi anede ikke, hvad der kom. Og programmet står og siger, at modtagerorganisationen kommer altid for sent i gang. Og det er også sådan en lidt dødssyg ting, at vi ikke har styr på de der grænseflader og det der skåb, fordi så misser vi noget af det, som vi gerne vil som program. Så tænk nu, hvis vi i stedet for at gøre sådan der, startede med at lave det her billede og sige, okay, det er det, der har skåbet. Og derefter begyndte at sige, hvem leverer hvad? Hvor mange projekter skal vi have? Hvor lang tid kommer de til at tage? Og så videre, og så videre, og så videre. Og hvis I er virkelig skarpe, så vil I kunne se, at projekterne har ændret radikal form, og der er ikke nogen, der laver det samme. Men de ved lige præcis, hvor de er syget sammen henne, og hvad der skal til, for at det hænger sammen, når vi skal til at implementere det i den sidste ende. Ja, man kan sige, i forhold til programmet scope her, så er vi også godt klar over, at det jo ikke sådan, så sidder alle og venter på, at nu er der, et færdigt scope. Så der kan sagtens være igangsatte projekter, der arbejder og indsatser, der kører. Det, der bare er humlet i det her, det er, at i forbindelse med programmets etablering, så bliver du nødt til at lave en beskrivelse af det scope, der skal leveres, sådan at du faktisk lige har dit eget overblik, og som programleder, eller for den sags skyld, program ejer, kan sætte en retning og også afgrænse, hvad vi skal lave og hvad vi ikke skal lave. Ja, og en ting er jo, at vi siger, at det her skal laves i programmets etablering. Det er aldrig for sent at lave det. Så hvad er det, vi snakker om her? Vi snakker om, at det er den her fremtidsmodel, som vi vil slå et flag for, at I begynder at arbejde med, hvis I ikke allerede gør det. Fordi fremtidsmodellen, det er det, som Mikkel siger, der afgrænser programmet, det er programmets scope, så vi kan tydeligt se, hvornår vi begynder at bevæge os ud i ønsker, der ligger uden for scope, eller hvis vi er nødt til at lave ændringer. Så siger vi, okay, det er en ændring, det var ikke med, eller der er noget af det, der var med, der ikke skal være med, fordi vi skal lave noget andet. Og vi har taget lidt eksempler med senere, bare lige, så I også er med på det. Ja. Men udover det her med beskrivelse af programmets scope og afgrænsning af programmet, så er det også vores mulighed for at sige, har vi det hele med? Og så kan vi styre ændringsønskerne ud fra det. Men det er også et super vigtigt kommunikativt værktøj over for modtagereorganisationer, over for dem, der finansierer programmet. over for dem, der har forventninger til programmet. Så det at styre de forventninger løbende igennem programmet er super, super vigtigt. Og den optræder i alle programmets faser. Jeg vil ikke gennemgå det, fordi så tror jeg, at tiden kommer til at løbe rigtig meget fra os, men den er vigtig for programmet selv, men den er lige så vigtig for modtagereorganisationen. Når vi laver det her, hvad indeholder sådan en så? Der arbejder vi i vores bog med nogle kategorier. De ser sådan her ud, og det her, vi har taget nogle eksempler med, så I kan se det bag. Kategorierne er der kun for, at vi skal prøve at tænke hele vejen rundt om skåbet, så vi ikke glemmer noget. Så når vi nu skal til at kigge på det her, hvad betyder det egentlig for at starte med produkter og services? Jamen, de bliver anderledes. Vi kommer til at lægge organisationen om og slå nogle enheder sammen, og det betyder noget for det tilbud, vi har til borgerne eller det, vi kan yde til vores kunder. Jamen, hvad har vi så af krav til teknologi, der skal understøtte det her? Vi skal have nye IT-systemer eller fysiske rammer. Hvis det er privat, kunne det være produktionsanlæg eller hvad ved jeg, en ny fabrik. Hvad betyder det for data? Hvad med den ledelsesinformation, der skal køre? Hvordan kommer den til at se ud? Har vi krav om nye KPI'er, vi skal lave op til eller andet? Hvad med de interessenter, vi arbejder med? Hvordan bliver de påvirket? Er der nye interessenter på banen? Skal vi have nye organiseringer? Så nye organisationsstrukturer? Hvad med vores arbejdsprocesser? Skal de laves om? Så det her, det er jo udelukkende til at stille spørgsmål. Det er ikke vigtigt, om man nu lige synes, at en arbejdsgang skal ligge i den ene eller anden kategori. Det her er en hjælp til, at man tænker hele vejen rundt om skåbet, så vi får det hele med. Og det er, så tænk på det som, Mærne, ikke en akademisk øvelse, men sige, har vi ikke glemt, at vi egentlig skulle have en ny hjemmeside? Eller noget andet? Du vil sige noget? Jamen, jeg er nysgerrig, Helle, fordi hvis du skulle sætte ord på, hvem er målgruppen for fremtidsmodellen? Der er flere. Der er jo dels vores ledelse, fordi de skal forstå, hvad det er, vi har tænkt os at levere, for at de kan realisere den værdi, som de har sagt, de vil have ud af programmet, og realisere den vision. Den er vigtig for eksterne interessenter for at forstå, okay, det er det, de laver. Den er vigtig for programmet for at kunne styre skåbet, og for at kunne starte de rigtige projekter, som leverer det rigtige og styrer det. Så den er egentlig vigtig hele vejen rundt, og så er den vigtig for modtagerne, fordi, og det her eksemplerne kommer til, som lige om et øjeblik, så er det her rigtig vigtigt også at vise modtagerorganisationen, hvad kommer det her til at betyde for jer? Og så vi kaster os ud i eksemplerne nu. Ja, og måske bare lige også sådan, at sådan en fremtidsmodel, det er mere et 10-siders end et 500-siders dokument. Jeg vil sige, at de kan se meget forskelligt ud, og de kan have meget forskelligt længde, men det er rigtigt stort og ikke nødvendigvis bedre. Det, der er vigtigt, det er, at den indeholder de relevante ting. Det, jeg kigger på her, det er energibåndholm, og det er, som Mikkel sagde, så det, der ofte er fokus på, det er sådan det fysiske, der skal etableres. Der skal være landstationer, der skal være kabler, men der sker rigtig meget andet. Så hvad betyder det, når vi skal have en ny bodzone? Hvad betyder det, når vi får nye tariftmodeller? Hvad nu, hvis der ikke er nogen, der gider lave de der vindmølleparker? Og så skal vi også have etableret en ny fællesorganisation med en eksterne internationale partnere. Alt det der er jo kæmpestort, og hvis I kigger over, hvis I kigger mod Jylland her, der vil I kunne se, at det kommer til at påvirke stort set hele driftsorganisationen. I større eller mindre grad på forskellige tidspunkter, men det kommer til at påvirke dem alle. Og det, der er så vigtigt, når man kigger på det, det er at sige, jamen hvad er det så, programmet leverer til modtagerorganisationen? Og hvad er det så, modtagerorganisationen selv skal gøre for at blive klar til at tage imod det, programmet kommer med? Den måde, som lige det her målbillede, de kaldte det et målbillede, det er vores fremtidsmodel, det blev bygget op på bare lige for at illustrere, hvordan kunne man gøre det. Og I kan ikke læse det, det er egentlig heller ikke meningen. Men det er, at man har nogle afsnit, man siger, at det her afsnit, det handler om drifter ved ligehold, og der drifter ved ligehold og nogle forskellige ting. Går vi ind og beskriver det ud fra de kategorier, I havde før. Så for at vi kan have en ordentlig drifter ved ligehold på den anden side, når det her er bygget, hvad er det så, vi skal have? Og så vil vi slå et slag for noget, som vi selv synes er en super effektiv ting, nemlig det tredje, I kan se her, vi kalder FaktaArk. Fordi det, vi så også kan gøre med fremtidsmodellen i hånden, det er, at vi kan have en drøftelse med modtagerorganisationen, hvor vi ligesom siger, okay, hvis vi skal levere noget herude, det her er et fiktivt eksempeløvet og har intet med energiøven at gøre, så I skal ikke undre jer over, hvorfor skal de have en centralt udstyrsdag? Det skal de sikkert også, men det er lige meget, det er bare et eksempel. Så lad os sige, at sådan, det skal vi have. Hvad betyder det? Jamen, hvad kommer programmet til at levere i forhold til det centrale udstyrsdepot? Men hvad skal modtagerorganisationen så lave? Fordi det giver modtagerorganisationen mulighed for at planlægge det arbejde, så det ikke er noget, de kommer til at lave på bagkant efter programmet har leveret. Og hvem i modtagerorganisationen skal så i øvrigt lave det? Denne her snak med modtagerorganisationen er en af de mest værdiskabende ting ved at arbejde med en fremtidsmodel. Udover alle de andre ting, vi står her og reklamerer. I kan høre de ret begejstrede fra fremtidsmodeller, men vi kan bare se, at der er så mange problemer, vi ser i de programmer, vi kommer i kontakt med, som kunne være afhjulpet, hvis man havde sådan en her. Og hvis man er kommet til at starte nogle initiativer, skal man ikke være ked af det. Man kan stadig lave det her arbejde og få gavn og glæde af det. Når man nu kigger på det her, så er nogle programmer jo vældig, vældig store, og vi snakkede om de her implementeringsbølger. Så kan det faktisk være en god idé, og det er et billede fra vores bog her, et eksempel, vi har der, hvor vi siger, jamen lad os nu dele det op, og lige det her eksempel, det er så med tre bølger. Og så går en og beskriver, hvad er det egentlig præcis, der sker i de her implementeringsbølger. For det kan sagtens være, at man nu i bølge 1 for eksempel, pludselig lander med nogle manuelle arbejdsgange, indtil man når frem til bølge 2, og har fået dem digitaliseret som eksempel. Så det er også muligt både at kommunikere, hvad får vi af positiv værdi i bølge 1, men vi får altså også nogle negative midlertidige gevinster, indtil vi når længere hen i programmet. Men det er, som Mikkel sagde, hver bølge vil ligesom levere en tilstand, der kan fungere i drift. Et andet eksempel på det, kan I se her, det er faktisk fra DSB, der jo kører et kæmpe program omkring fremtidens materialeanskaffelser. Og denne her tegne er ret bærende for dem, der siger noget om, hvornår får vi nye kapabiliteter og nyt materiale ind ad døren. Og jeg tog den med her, bare for at illustrere, at de første seks bølger, kan I se der, de er med de stiblede linjer. Der siger, her har vi nogle implementeringsbølger i organisationen, og I kan se, det er ikke nødvendigvis samtidig med, at nogle af de der hovedlemmerancer er færdige. Det er måske lidt senere eller lidt før, fordi det er her, den organisatoriske implementering ligger. Og når man så går ind og laver det her arbejde med at sige, hvad er det så, det betyder for de forskellige bølger, så har man faktisk også mulighed for at tage et første take på, hvor stort bliver det her for modtagerorganisationen. Og det har vi lige taget med her. Så I siger, jamen her, der er nogle kernefunktioner i driften, og hvordan bliver de påvirket af de forskellige bølger? Så i de der diagrammer med boblerne, det er sådan navnene på de implementeringsbølger, der er. Og det, der vi synes, der kunne være interessant at vise jer, det er, at her har man så mulighed for, som organisationer, at hvornår bliver mest påvirket, hvornår. Så hvornår skal vi have særlig kærlighed omkring den ene eller den anden kernefunktion, fordi det bliver særlig svært for dem. Nu er det her jo et kæmpe program. Det her, det giver også værdi i mindre programmer, og man kan starte det utrolig lavpraktisk. For eksempel med en tegning og en masse post-its eller papkort, vil vi jo naturligvis bruge. Så lad være med at tænke, at det her kun får store initiativer. Selv små initiativer, der medfører store forandringer, de vil have enormt stor gavn og værdi af det her, både imens det kører programmet, og især i implementeringen og samarbejdet med modtagerorganisationerne. Det var, hvad jeg ville sige om det. Ta da. Tak. Så gå ud og udarbejde en fremtidsmodel. Det er sådan hovedbudskabet i det, i forhold til at styre skob og afgrænsning. Ja. Det andet, vi gerne vil dykke ned i, det er det her omkring programmets organisering. Altså, hvad er det for forere, vi skal have? Hvad er det for ledelsesroller, der skal løftes? Hvordan designer vi vores leveranceorganisation, sådan at alle kan arbejde effektivt? Og der er sådan nogle taktiske overvejelser, som vi gerne vil give jer med. Men lad os lige prøve først at kigge på, hvad er programmets kendetegn egentlig? Og hvordan er de så afgørende for, hvordan programmet organiseres? Hvis I kigger ud i højre side, så har Helle og Signe og jeg været så kikke og lave vores egen definition af programmer. Så et program, det er en midlertidig organisation, der skabes for at koordinere og styre en række relaterede projekter og aktiviteter for at levere forretningsmæssige gevinster relateret til en eller flere af organisationens strategiske målsætninger. Så det vil sige, at vi i sin grundessens har noget, der er midlertidigt, som skal etableres og som ikke findes allerede. Så det betyder også, at når vi organiserer vores program, så er det sådan set fra scratch. Altså, at vi skal finde ud af, hvem er det, der skal bestemme her? Hvem er det, der skal løfte hvilke roller? Fordi det er ikke tegnet i linjeorganisationen fra start. Programets kendetegn, det er også sådan, at designet, kan man sige, i forhold til at skabe strategisk sammenhæng, drive ongstorisk transformation, det skulle gerne være sådan, så at programmets gevinster overstiger summen af de gevinster, som de enkelte projekter, hvis man gennemførte dem, ville skabe. Det består af flere projekter, der er forbundet gennem et fælles ongstorisk mål. Det omfatter både drifts- og ad hoc-opgaver også, altså ud over de projekter, der gennemføres. Og så er det en midlertidig organisering. Så når vi har en organisering som denne, der er stor og kompleks, så er det meget godt lige at gøre sig lidt, jeg vil kalde det taktiske overvejelser i, hvordan man så gør det. Fordi når vi har mange mennesker involveret, så kan man sige, på den ene side, så er der behov for, at programmet er forankret helt op i en topledelse. Fordi det er sådan set den måde, vi får opbakning, finansiering. Det kan også være den måde, vi får bundet det op i forhold til det, den samlede organisation skal lykkes. Et andet behov, vi har, det er at have det, jeg ville kalde sådan operationel ledelseskraft. Sådan at der faktisk er nogen, der bruger sin ledelsesenergi og sin ledelsesbåndbredde i at få det her program til at lykkes. Og det er jo nogle af de der taktiske overvejelser, og hvordan vi opnår det, som vi gerne vil ind på her. Men lad os lige prøve at kigge på sådan en skældning. Fordi når vi taler programmets organisering, så skældner vi imellem det at have et program, der er organiseret i det, vi vil kalde en stærk matrix. Man kunne også sige et program, hvor beslutningskraften ligger inde i programmets organisering. Og typisk vil det så også være, og det kan lyde lidt hårdt, men at der så er det, jeg vil kalde en svag linjeorganisation. Altså at linjen eller forretningen bestemmer mindre her. Det kommer jeg lige tilbage til. Kan I ikke synes, at de ikke samarbejder? Nej, nej, nej, nej. Samarbejder over det hele. Det andet element i det her, det er, at man kan også have et program, som var organiseret i det, man ville kalde en svag matrix. Altså det, man også kunne kalde et program med de tusind blomster. Og hvis vi sådan bare kigger på forskellene i det, så i den svage matrix, der ville vi have et program. Men hvem beslutter egentlig, hvilke projekter der skal ligge inden i programmet? Jamen det gør man ude i linjen. Det er linjens ressourcer, der anvendes til det her. Det er linjen, der hyrer og fyrer. Og hvis I lige tænker tilbage på det eksempel, vi startede med fra den store danske kommune, der gerne vil være CO2-neutral i 2030, så er det program et rigtig godt eksempel på et program, der bør være organiseret som en svag matrix. Fordi at løsningerne skal findes decentralt. Der er nemlig forskel på, hvordan løsninger i forhold til at blive CO2-neutral ser ud i teknik- og miljøforvaltningen eller i børne- og ungeforvaltningen. Og det vil sige, at vi kan ikke sidde oppefra og detaljstyre og tegne en løsning, som bare skal være. Der giver det god mening at lægge ejerskabet ud i linjeorganisationen og også lade beslutningsmandatet langt hen ad vejen ligge den. Og hvis vi tager den svage matrix, hvad er det så, vi faktisk har fokus på som programledelse der? Jamen det er at sikre en tværgående koordinering og styring i forhold til, at vi alle sammen arbejder i den samme retning. Og det er sådan noget som at blive meget tydeligt på, hvad er det egentlig for gevinster, vi skal opnå som kommune. Og også prøve at tegne et high-level billede af, hvordan ser vores kommune ud, når vi sådan set er lykkedes med det. Og gøre det ved at involvere på tværs af forvaltningerne, sådan at alle forvaltninger arbejder i samme retning. Men også med respekt for, at løsningerne, de skal langt hen ad vejen, defineres ude i forvaltningerne. Hvis vi så tager den stærke matrix i stedet for der. Så der hvor det giver rigtig god mening at have en stærk matrix, altså hvor beslutningskraften ligger i programmet. Det er programmet, der hyrer og fyrer, som har eget budget og dermed egne midler til at gøre som de vil. Nu er det sat lidt karikeret op. Det er der hvor man kan sige, at vi som program også skal levere en sammenhængende løsning. Og hvor man kan sige, at enderne gerne skal passe sammen. Fordi når vi har en stærk matrix, så er det muligt at lave meget tæt koordinering, afdække afhængigheder, være tydelig på, hvad det er for krav, hvad enkelte delprojekt skal leve op til. Sådan at vi kan levere en samlet løsning. Det er også i en stærk matrix, at vi har den mulighed for at skabe fart. Fordi sjovt nok, når vi har en centraliseret programorganisering, så er det nemmere at få beslutninger igennem. Og det er der vi ønsker en stærk matrix. Så det er sådan to yderpunkter. Og rigtig mange programmer er jo en eller anden hybrid mellem en stærk og en svag matrix. Men det er meget godt som programleder eller som program ejer at have det der blik for, hvad er det egentlig for en grundlogik, der er i de kendetegn, der er ved det program, vi har her. Og hvad gør det i forhold til, hvordan vi så skal organisere det. Nå, lad os kigge på programmets organisering. Over i venstre side, der kan I se, der har vi givet vores bud på, hvordan er det egentlig, at vi både skaber en strategisk forankring. Og sjovt nok, det gør vi så op i en strategisk styregruppe. Meget originalt. Og samtidig med, at vi også har noget operationel ledelseskraft. Og sjovt nok, det sker så nede i det, vi kalder den operationelle styregruppe. Vi har tre roller, som er væsentlige. Vi har en program ejer, som har det overordnede ansvar, som er bindeliget mellem den strategiske styregruppe og den operationelle, og som sidder i begge grupper. Vi har en programleder, som har den daglige ledelse af programmet. Og så har vi en eller flere gevinste ejer. Altså ledet, man kan sige, repræsentanter for beslutningstager i modtagerorganisationen, som sådan set i programmets gennemførelse har til opgave at have blik for, og sådan set have det som den brille, de kigger på programmet med. Hvad skal der egentlig til, for at vi i modtagerorganisationen kan anvende de løsninger, programmet kommer med? Og det er sådan tre væsentlige ledelsesroller. Hvis vi tager den strategiske styregruppe, så kan man sige, det er typisk en organisation, eller hvis det er noget, der er på tværsorganisationer, så er det organisationernes topledelse. Altså så er vi på direktørniveau, der hvor der både er økonomi og også et mandat i forhold til at sige, det her det vil vi, og det er den her vej, vi går. Så det er de større beslutninger, vi lægger op der. Og det betyder også, at den strategiske styregruppe ikke mødes lige så ofte som den operationelle styregruppe. Den operationelle styregruppe med programleder og gevinsterejer, der vil typisk også sidde på et PMO-manager der, altså den, der leder PMO'et, programkontoret, og så vil et program ejer sidde der. Og her taler vi altså om dem, der skal lægge, og nu ser jeg det bare stort set deres fuldtidsledelseskraft ind i, at vi lykkes med det her program. Og det vil sige, det er også en langt større mødefrekvens i forhold til hver uge eller hver anden uge, man mødes i den operationelle styregruppe. Fordi hvis jeg nu ikke har en operationel styregruppe, lad os lege med det, at jeg bare er programleder, så har jeg min strategiske styregruppe eller mit sponsorforum. Så det der tit sker der, det er, at vi sådan set laver det, vi skal ned i programmet, men vi mister ligesom kontakten op til det strategiske niveau, fordi det er en gang i kvartalet, at vi tjekker ind på hinanden. Og det vil sige, at den der strategiske styregruppe, den bliver simpelthen urolig i forhold til, hvad er det, der sker, og vi er enormt sådan påvirkelige i forhold til, når vi ikke har en tættere relation. Og det er jo også det, den operationelle styregruppe sådan set skal skabe sammen med en program ejer, det er en tættere relation op til den strategiske styregruppe. Så det der med at have en operationel styregruppe, der arbejder i dagligdagen på den samlede ledelse af programmet, det er super vigtigt. Nu nævnte du lige gevinstererne og sagde, at det er deres fuldtidsjob. Det er jo et fuldtidsjob selvfølgelig for programlederne her, og gevinstererne kommer til at bruge rigtig meget tid. Det man lige skal huske, det er, at de har lige en drift, der skal køre os. Så hvordan skal de egentlig balancere det arbejde, der ligger ude i driften, samtidig med, at de ligger så meget kraft ind i programmet. som det faktisk er nødvendigt, fordi det er dem, der skal stå på mål for, at vi laver det rigtige til dem. Så de skal bruge tid på det. Det kan ikke nytte noget, at de kun dukker op en gang om måneden eller noget i den stil, og har glemt, hvad det var, vi snakkede om sidst. De skal være engagerede. Det er jo dem, der skal stå på mål for, at når vi laver vores fremtidsmodel, så er det det, de har brug for. Og de glæder sig til at få det, og de forbereder deres organisation på det, de skal være klar med for at kunne tage imod det, vi laver. Så det er en meget, meget stor opgave for dem. Og derfor så, når vi så er det provokerende, at de skal være fuldtidsansatte i programmet, så handler det jo også om, at de skal have noget hjælp derhjemme i driften. De skal ligesom kigge på deres ledelsestime og sige, hvordan løfter vi det her sammen. Fordi hvis ikke man tager den snak, så bliver det svært. Så det her, det er et bud på sådan et programs grundorganisering i forhold til de beslutningsorganer, der er. Og så kan man bygge alt muligt på med Change Management Forum og derudad. Men det her, det er sådan grundlogikken. Over på højre side, der kan I se en ting, der også typisk bøvler. Det er det der med at blive meget formuleret omkring, hvad er det for nogle mandater, der ligger på hvilke niveauer. Og man kan sige, hvis ikke man er tydelig på, hvad kan jeg træffe beslutninger om som programleder? Hvad kan jeg træffe beslutninger om som projektleder? Hvad ligger af beslutninger i en operationel styregruppe? Og hvad ligger af en strategist styregruppe? Så sker der det, at beslutninger, de sådan set, de går opad. Altså forstået på den måde, at hvis ikke man ved, hvad man kan træffe beslutninger med, hvad gør man så? Så lægger man det længere op i vores midlertidige organisering. Og hvis I kigger her, så sådan en grundtommelfingerregler i forhold til en strategist styregruppe, det er, at de sådan set træffer beslutninger om alt det, der ligger uden for det mandat, programmet er givet. Så kommer der ændringer til noget, som påvirker, man kan sige, som går uden for de rammer, man er givet. Så skal det op i den strategiske styregruppe. Den operationelle styregruppe, de kan sådan set træffe beslutninger om alt det, der er inden for det mandat, den strategiske styregruppe har givet. Typisk i et programgrundlag. Programlederen har sådan set opgaven i forhold til at udmynde det. Og projektlederen har egentlig mulighed for at træffe beslutninger inden for alt det, der er inden for eget projekt, og som ikke påvirker andre projekter. Så det er sådan et billede af, hvordan vi kan arbejde med det her mandat på de enkelte niveauer. Hvis vi så kigger på leveranceorganisationen. Hvordan organiserer vi egentlig vores leveranceorganisation? I kan se ude i venstre side, der ligger PMO'et. Det kommer jeg tilbage til lige om lidt. PMO'et refererer typisk til programledere og er programlederes højre hånd. Og logikken i det, det er, at det at have et velfungerende PMO gør, at jeg som programleder kan fokusere på ledelsesopgaven og, man kan sige, mindre på den udførende styring af programmet. Og det betyder, at jeg som programleder kan fokusere på de samtaler, skabe opbakning, sådan set håndtere de issues og problemstillinger, der løbende opstår, mere end jeg skal have fokus på og skabe indblik i, hvordan det samlede program er styret og hvordan vi lykkes med det. Så det at have et PMO er super vigtigt for programlederne. Men hvis vi lige kigger i forhold til leveranceorganisationen, så her har vi tegnet fire forskellige måder, at leveranceorganisationen kan være koblet op i forhold til programmets samlede organisering. Ude i venstre side kan I se, at der står linjeledere og arbejdsgruppe. Altså programmer kan også rumme det, vi kalder ad hoc-opgaver. Altså udviklingsopgaver, der sker ude i linjeorganisationen. De er styret af den linjeleder, eller det kunne også være en chefkonsulent, eller hvad det måtte være, og har typisk en arbejdsgruppe tilkyttet. Og det er typisk det, som vi viste jer, da vi viste jer eksemplet på et faktark fra en fremtidsmodel, derude, hvor der står, at der skal drives af modtagerorganisationen. Det kunne være sådan nogle ting, der ligger der, som man har valgt ligesom også skal rapporteres ind til en opmærkslægtsstyregruppe for at sikre koordinering på tas, og sørge for, at de får den støtte, de har brug for, for at gennemføre det, de skal. Ja. Og man kan sige, at fordelen ved at have den her type organiseret tilkyttet op i programmet, det er, at den kører super selvledende. Og den måde, vi styrer dem på, kan man sige, det er det at etablere en strategisk retning, altså en vision og en fremtidsmodel. Og så er det ved at lægge nogle rammer for governance, altså hvordan man rapporterer i forhold til at gennemføre de ad hoc-opgaver, der er. Så hvis vi kigger på den næste linje, så kan man se, at der er en projektleder her og et projektteam, der refererer direkte op til programledere. Altså der, hvor programmet har en samlet løsning, de skal levere, så er det en kæmpe fordel, den her organisering, fordi der er et referenceforhold direkte fra projektledere op til programledere, Det gør, at styring, koordinering, også på tværs af projekter, er langt lettere. Vi kan simpelthen agere som en enhed, kan man sige. Udfordringen, man kan ellers sige ulempen ved den her, det er, at programledere nogle gange har tendens til at blive trukket ned i ren operationel projektgennemførelse, fordi sjovt nok, hvad er det for nogle problemer, man præsenteres for? Det er dem, der sker nede i projekterne. Så den kan have den der slagside, men omvendt, så er det også en enormt effektiv måde at arbejde på. Så kan I se, at den næste, vi har, det er der, hvor vi egentlig har projekter under programmet, som har en selvstændig styregruppe, og hvor i styregruppen, der er der en af de gevinster, der sidder i den operationelle styregruppe, som sidder med som superbruger, altså, eller seniorbruger. Så man kan sige, at gevinstejerens rolle her er fuldstændig den samme, som man har som gevinstejer, nemlig have et fokus på modtagerorganisationens behov, hvordan de realiseres, og samtidig med det, så får vi skabt en kobling mellem det, der sker i projektet, og som typisk vil være et projekt, der ligger i linjeorganisationen, og så det fokus, der er oppe i den operationelle styregruppe. Projekterne her er med egen styregruppe, og det giver selvfølgelig også sig selv. De er meget mere selvkørende, på godt og ondt, i forhold til et programs gennemførelse. En af de store fordele her, kan man sige, og det, hvis man nu tog eksemplet med den CO2-neutrale kommune, så er det, når vi har den her type leveransorganisationer under programmet, så er det her, man finder ressourcerne selv, bemander med videre. Og det har også nogle fordele. Så kan man sige, at den sidste herude, der refererer projektet op til en samlet operationel styregruppe. Der er ikke en kobling, hvor der sidder en af de tre roller nede i styregruppen, så det er endnu mere decentralt organiseret, kan man sige. Og på samme måde, som vi har med over i venstre side, i forhold til det, hvor det er ad hoc-opgaver, hvor der er en linjeledende arbejdsgruppe, så den måde, vi styrer den på, det er gennem strategisk retning, altså vision, fremtidsmodel, og så en tydelig governance. Så det her, det er forskellige måder, jeg sådan set kan koble projekter, indsatser op i min leveransorganisation på det samlede program. Og det kan jo sagtens være, at et program har alle fire måder at gøre det på. Fordi det er det, der er mest effektivt i forhold til det, de forskellige initiativer skal lave. Så man kan sagtens se et mix af det her i det samme program. Det, der er vigtigt i forhold til fremtidsmodellen, det er, at de her projekter og opgaver bestemmer ikke selv deres scope. Fordi hvis de begynder at gøre det, hvis vi har en selvstændig styregruppe, der synes, at vi vil hellere lave noget lidt andet, så begynder vores sammenhængelige leverance som program at falde lidt fra hinanden. Og det er noget af det, der tit sker, når vi går i gang og bare starter projekter, som så kører mere eller mindre selvstændigt. Uden det her organisatoriske forankring, som der er her. Og de rammer, der bliver sat for den operationelle styregruppe. Ja. En ting, vi har taget med i det her, og som vi lige vil sætte fokus på nu, det er det her omkring programmets organisering i forhold til det, vi kalder organisationens projekt og programmodenhed. Fordi der er sådan en ting, vi tit oplever i forbindelse med, at vi kommer ud og hjælper eksisterende programmer i deres gennemførelse. Det er, at man har været lidt blind for, hvad kan man sige, den modenhed, der er i den eksisterende organisation i forhold til at gennemføre et program. Og hvis I kigger på koordinatsystemet her, så opad, der har vi programmets kompleksitet. Så programmer kan være mere eller mindre komplekse. Altså, de kan være komplekse i forhold til, hvor stor en forandring det vil være for den samlede organisation. Det kan være komplekst i forhold til, hvor mange leverandører man arbejder sammen med. Det kan være komplekst i forhold til, hvor mange dele af organisationen man inddrager i forhold til programmets gennemførelse. Det går på tværs af flere organisationer med videre. Så der kan vi gå fra at have lav kompleksitet til høj kompleksitet. Og nede i bunden, der kan I se, at organisationens modenhed i forhold til det at gennemføre projekter og programmer kan ligeledes være, man kan sige fra, nu siger jeg det bare, umoden. Altså, det har vi ikke gjort før. Vi har simpelthen ikke gennemført et program før til moden, hvor der ligger en eksisterende programmodel. Det kan være, man har taget vores bare og planket dem. Og det vil sige et setup i forhold til, hvordan vi organiserer programmer. Hvad er det for ledelsesprodukter, der ligger i det? Det er vi tit oplever. Og det er meget i forhold til programmer, hvor at organisationens modenhed er lav, men programmets kompleksitet er høj. Altså op i øverste venstre hjørne. Det er, at vi ser, at der er sådan en bias i forhold til, at når man ikke har erfaring med programmer, så fastholder man ligesom, man kan sige, så har man den grundreaktion, at vi fastholder beslutningskompetencen ude i linjeorganisationen. Det vil sige, at vi typisk organiserer vores programmer i det, vi ville kalde en svag matrix. Og en anden bias, vi også ser, det er, at vi alt for ofte oplever, at organisationen sådan set ikke er klar til at investere i, man kan sige, det er styrings- og ledelses setup, der skal være. Så for os er det mere en opmærksomhed i forhold til, hvis I sidder i en organisation, hvor modenheden i forhold til at gennemføre programmer er lav, men programmets kompleksitet, den er høj, så er det sådan et ops på, åh åh, nu er der faktisk en risiko for, at vi gør ligesom mange af de andre under at investere. i hvordan vores programsetup skal være. Den sidste pointe omkring organisering, som jeg lige vil adressere, det handler om, hvordan vores støtte, ledelsesstøtte, er sat op i forhold til programkontoret, og hvor at, når vi sådan kigger på, hvordan PMO'er nogle gange er organiseret, og det vil sige den støtte, der er til en programleder og den samlede ledelse af programmet, hvordan det er organiseret og hvilke opgaver, de har fokus på, så ser vi, at PMO'er nogle gange har en tendens til at have et fokus på alene at lede op af, altså have fokus på den styregruppe, der måtte være, eller den sponsorgruppe, strategisk styregruppe, eller operationel styregruppe, har sådan en, et bestiller mindset, altså, vi skal rapportere, vil du ikke være sød at udfylde det her. Og det vil sige, hvad kan man sige, ikke på samme måde, som vi i hvert fald kunne ønske os, og som vi oplever er enormt værdiskabende, har en serviceorienteret tilgang til det at drive et PMO. Og det vil sige, at man har fokus på processerne, mødeforberedelse, og det vil sige, at det er også tit en lidt kortfattet, eller kort sigtet hedder det vel, tilgang til PMO-opgaven om, hvad skal der ske på det næste eller de næste styregruppemøder. Det er ligesom det, der er ens scope of work. Og hvis vi skal etablere PMO'er, som er en sindssygt vigtig ledelsestøtte, så ser vi, at de bæredygtige og langtidsholdbare PMO'er, altså der, hvor de opleves som en hjælp, både nede i projekterne, i programmet og ude i, man kan sige, i driftsorganisationen, det er der, hvor programmerne bevæger sig hen mod en mere serviceorienteret tilgang. Altså, hvor at PMO'et hele tiden løfter blikket, og også har det lidt længere lys på, driver på udviklingen og udarbejdelsen af selvstændige ledelsesprodukter. Det vil sige faktisk, sådan kommer helt ind i materien af, hvad er det, programmet skal levere, og kan være drivende på at udarbejde en fremtidsmodel, eller hvad det måtte være. går ind og støtter i etableringen af de projekter, der er i programmet, faciliterer workshops, sådan set støtter i udarbejdelse, når de, lad os sige, der skal laves pider, altså projektindiseringsdokumenter i de enkelte projekter, hjælper med at sikre kvalitet og onboarder folk, der skal deltage i programmet. Og det er den ændring og den tænkning, vi sådan set gerne vil lægge ned over det, vi kalder et serviceorienteret PMO. Man kan sige, at et succeskretære for det serviceorienterede PMO, det er, om projekterne ringer og beder om hjælp. Så hvis telefonen aldrig ringer, så skal man nok overveje, hvordan kan vi ellers hjælpe vores projekter med at køre mere effektivt. Og sådan så, at det styrkesætterop, vi laver i programmet, rent faktisk skaber værdi for dem. Og ikke bare til besvær, åh nej, nu skal vi rapportere igen, og det er også besværligt. Så det er en meget god kopi at have af nogen, der beder om hjælp. Ja, og bare sådan lige for at gå tilbage. Der, så PMO'et, de ligger sådan ude på siden som sådan en stabsfunktion, der typisk refererer ind til programlederne og programlederens højre hånd. Nå, det var egentlig det, vi havde med omkring programmets organisering. Og der er jo mange dybder i det her. Der er mange taktiske overvejelser i forhold til, hvordan er det egentlig, du sammensætter din organisering. Men det her, det er sådan nogle forskellige måder at skære programmets organisering og anbefalinger til, hvad det er for nogle hensyn, især de skal have for øje. Det vi gerne vil nu, det er så at konkludere og runde af, hvor vi har udarbejdet sådan 11 programlederhacks. Og Helle, vil du ikke starte? Jo, det vil jeg rigtig gerne. Så hvis I nu sidder der og tænker, åh, jeg har en direktør, som hedder programmer. Det er fuldstændig ligegyldigt, hvad I kalder initiativet. Det, der er vigtigt, det er, hvordan I styrer det. Og det, vi håber, vi kan gøre med vores bog, det er inspireret til at få det organiseret effektivt og komme godt i gang med at få styr på skåb og grænseflader og gevinster og få en effektiv styring, så I kan eksekvere effektivt og hurtigt. Og I får et super samarbejde med jeres mod. organisation. Men det er ligegyldigt, om I kalder det et program. Så det er lidt et hack. Altså, vi skal ikke holde fast i enkelt ord. Vi skal sådan set go with the flow. Det handler om, hvordan vi organiserer og styrer det. Ikke, hvad vi kalder det. Vores andet hack, det er det, der er sådan også lidt kægt og skrevet, at som program, så skal vi finde på meningsfulde opgaver, som ledelsen kan gå i gang med. Altså, hvis ikke de kan vente med at gå i gang. Og det er super provokerende sagt, det her. Men hele citat fra tidligere i forhold til, nu har vi jo besluttet, vi skal det her, så lad os da bare komme ud over stæberne, få defineret løsningerne og lad os komme i gang med at udvikle. Vi går i udbud. Ja, vi går i udbud. Og det vil sige, det kan være enormt svært som programleder ligesom at tøjle linjeorganisationens utålmodighed i forhold til at sætte resultater. Og det er fornuftigt nok. Man kan godt forstå en linjeorganisation. En beslutningsproces har været længe undervejs. Men noget af det, vi kan gøre, det er, at vi som program sådan set på den ene side kan sige, jamen, vi er i fuld gang med at eksekvere og kære ledelse. Vi har brug for jeres hjælp, så vil I ikke hjælpe med at finde det her og det her og det her, fordi vi har brug for et ordentligt grundlag. Og det kan sådan set tøjle organisationens tålmodighed samtidig med, at vi etablerer vores program, altså få defineret en vision, fremtidsmodel for lige sådan en ting lige, hvad er de større bølger, og dermed også få afgrænset skub for vores program. Og de to ting kan godt køre simultant, men vi skal på en eller anden måde tøjle organisationens utålmodighed. Og det er jo ikke altid, vi kan det. Rigtig ofte, når programmer starter, så er der jo allerede initiativer i gang i organisationen, som har med det program at gøre. Og der må vi jo prøve at hjælpe dem at løbe så hurtigt, vi kan, for eksempel med fremtidsmodellen, for at sige, laver I nu også det rigtige? Eller hvis det der er givet, hvad betyder det så for fremtidsmodellen, hvis det nu bliver sådan der, og vi har købt noget? Altså så man bliver nødt til at være rigtig pragmatisk på det der. Og måden at gøre alle de her ting på, det er jo vores tredje hack, det er at sige, ansæt en PMO-ressource fra dag 1. Fordi det her med, at der er nogen, der skal have styr på styringen, og have styr på processerne, og sørge for, at vi får onboardet projekterne rigtigt, og hjælpe dem godt i gang, sådan så de ikke pludselig stikker af, og tror, de skal lave noget andet, eller har lov til at træffe beslutninger om skub, de ikke har lov til at træffe, og sådan nogle ting, er super, super vigtigt. Og i og med, at man formentlig både skal tøjle udtålmodighed, og i gangværende initiativer og alt muligt andet, så har man simpelthen brug for nogen, der kan eksekvere på den del af det, så man har en god dialog om, hvordan gør vi tingene, hvordan planlægger vi det, hvordan rapporterer vi osv., og så er der nogen, der kan eksekvere det for en, og man kan tage sig af de andre opgaver, fordi det er langt vigtigere for en for den langsigtige succes med programmet. 4. Etabler en smal operationel styregruppe, og mød din program ejer en gang om ugen. Og det var egentlig en pointe, som jeg også fik sagt op underkring organiseringen, at det her med, at vi har en operationel styregruppe, lad os bare sige så smalt som den kan være, nemlig på 3 plus en PMO-manager, der ved de er den, og som bruger deres ledelseskraft ind i at lykkes med programmet. Det er super vigtigt, fordi hvis du bare sidder helt palle alene, hvad vil jeg sige, som programleder, så gør det det svært at lykkes, hvis du har anden ledelseskraft. Og så det her med at møde ens programmer en gang om ugen, det er super vigtigt i forhold til at minske støj, øge forståelighed, og hele tiden kunne forventningsafstemmen i forhold til de valg, vi laver i programmet. af programmet, og som man som programleder hele tiden laver. Og det der med den smalle styregruppe, det er altså også fordi, vi tit ser, at man bedriver interessent håndtering i styregrupper. Så man har inviteret hele verden ind i styregruppen, fordi de godt kunne tænke sig at følge med i, hvad der foregår. Det er ikke en god idé, fordi så begynder det også at have meninger om noget, som ikke berører dem overhovedet. Smalt styregruppe. Den femte, det her med at kræve at få kompetente ressourcer for modtagerorganisationen og oplære dem. Og det handler jo om, at vi er nødt til at få vores gevinstejere til at forstå, at de er nødt til at give os nogle af deres dygtigste medarbejdere. Og det er supersvært, fordi det er jo det, der gør mest ondt på deres drift. Men vi er nødt til at få nogen ind, der har de rigtige kompetencer, hvis vi skal lave gode løsninger til dem. Fordi hvis det giver os dem, der har bedst tid og måske er nyansatte, kan godt være, at de er super dygtige, men de ved ikke så meget om organisationen endnu. Så hvad er det så for nogle løsninger, vi laver? Og rammer vi jo i øvrigt det rigtige behov? Vi er nødt til at få de rigtige. Men det vi så også har en pligt til som program, det er at oplære dem i, hvad de skal lave hos os. Sådan så vi rent faktisk siger, at nu skulle du bare høre, at vi er superglade for, at du kommer ombord, og vi skal bruge dig til det og til det og til det. Og nu skal du se, hvordan planen ser ud. Du bliver særligt behov for dig i de her perioder osv. Så vi har en ordentlig planlægning, der har respekt for de mennesker, de er også super efterspurgt ude i driften. Så de skal også føle, at de gør gavn og nytte inde i programmet, for ellers gider de ikke være der. Og hvis vi når derhen til, så har vi pludselig ikke en rigtig god ambassadør ude i driften, så har vi nogen, der synes, at det er noget værd at ro i det her. Så meget, meget vigtigt. Oplære dem i, hvad det er, de skal i programmet, forventningsafstem med dem, så de har de rigtige kompetencer og greb til, at de kan være værdiskabende i programmet og få en følelse af, at det her er vigtigt og det er sjovt. Og det smitter også af på modtagerorganisationen, når der sådan set er god energi at opleve, at man bliver modtaget på en kærlig måde. Vores sjette hack, det er at få budgetteret midler i modtagerorganisationen til implementering og gevinstrealiserning. Og når vi har den med og ligesom siger, at som programleder, så skal du også orientere dig og sådan set have blik for, hvad det er for midler, der sættes af i modtagerorganisationen til implementering og gevinstrealiserning, så er det en bitter erfaring. Nemlig erfaringen af at have siddet i en række programmer, hvor vi har udviklet løsninger, og så siver luften totalt ud af ballongen, fordi at modtager eller linjeorganisationen sådan set ikke har tænkt over, at der skulle være ressourcer i forhold til at sikre og understøtte en implementering. Så det der med at gå ind i de dialoger med modtagerorganisationen i forhold til, hvad det er for ressourcer, der skal sættes af, det er noget af det, der gør, at når vi så kommer dertil, så synes de sådan set også, at de er klar. Det er super ærgerligt. Det er sådan lidt, at operationen lykkes, men patienten døde, når de der ting sker. Og det er der, hvor modtagerorganisationen synes, de skal rydde op, fordi programmet gjorde det jo ikke helt færdigt, at typisk udtalelser, man hører i sådan nogle af organisationer. Så er det nummer syv. Det er lidt tilbage til, at vi skal mødes med den der programmerer hver uge, fordi en programmerer kan ikke tage ansvar for noget, de ikke forstår. Så programmererne skal kunne vågne op midt om natten og udtale sig om programmets vision med overbevisning og begejstring. Og det skal de i øvrigt også alle fem år, det her program, det kører. Lige fra dag et til afslutningen af programmet. De skal have 100% styr på, hvad er det egentlig, der skal leveres, det vil sige, at de skal forstå fremtidsmodellen. Og de skal have et rigtig fast fokus på, hvad er det, vi måske. prøver at opnå, det vil sige, gevinsterne. Så programmererne skal også have nogle dialoger med gevinsterne, der ligesom handler om, tror I stadig på, at vi kan realisere de her gevinster, som I har sagt, vi kan realisere med det her, for eksempel. Men det kan de jo kun, hvis de forstår, hvad det er, vi leverer. Det vil sige, at de skal bruge tid på det. Så programmerer, de kan godt have en tendens at sige, jeg har da ikke tid til at mødes engang om ugen, og budskaber forstå den der fremtidsmodellen. Det er ikke super kompliceret, og jeg er ikke særlig teknisk. Det behøver man heller ikke være for at forstå en fremtidsmodel, fordi så har vi misset noget i fremtidsmodellen. Men de er virkelig nødt til at være tæt på. Fordi det betyder også, at de er en god ambassadør. Det betyder også, at de skærmer programmet i forhold til alle mulige eksterne krav og holdninger og meninger. Og det har vi virkelig brug for, for ellers at forvikle arbejdsgrunden. Og de skal helt op på ølkassen og også kommunikere om programmet ud i organisationen. Det er også en af vejene at få dem ombord og give dem sådan, at de er der, hvor de faktisk ved, hvad essensen i programmet er. Så otteren her, det er, at du skal ikke bruge 100 mand på programmets første dag. Det, der er så fantastisk ved mennesker, det er, at de finder altid på noget, som de selv synes er begavet at lave. Det er det også nogle gange. Ja, ja. Men det, der så også kan ske, det er, at hvis jeg har for stor en organisation for hurtigt, så bliver der simpelthen arbejdet for mange retninger. Fordi folk, de tager selv initiativ. Så det er det der med at finde balancen i programmets etablering i at få kompetencer ombord. men ikke flere end, at vi sådan set har begavet opgaver, som vi er styrende af til dem. Så er der nieren her. Skærmprogrammets deltagere fra linjeorganisationens byråkrati. Det lyder måske lidt provokerende, men det handler virkelig om, at hvis vi skal være effektive i vores leveranceorganisation, så kan det ikke nytte noget. Vi skal lave indstillinger, ministerbesvarelser og alt muligt andet midt i det hele. Vi bliver simpelthen nødt til i vores programorganisation at være bemandet på en sådan måde, at leverancerorganisationen skal levere. Og så ved jeg jo godt, at hvis det er nede i projekterne eksperten, der kan svare på det spørgsmål, der er blevet stillet, så er vi selvfølgelig nødt til at forstyrre dem. Men så kan de give input. Det er ikke dem, der sidder og skal udarbejde lange notater om det ene, det andet, det tredje, eller projektleder, der sidder i programmet, der skal rapportere i tre forskellige formater til tre forskellige instanser. Det fik sig programmet. Projekterne skal levere. Vores tiende hack, det er at være pragmatisk omkring din leverancemodel. Altså de der metode-apostle, som ligesom har en løsning, som skal implementeres alle steder, det kører bare i hegnet. Så den hænger lidt sammen med etteren i forhold til, hvad vi kalder det. Men vores leverancemodel skal være designet i forhold til det behov, der er i programmet, og vi skal passe på ikke at blive for dogmatiske. Og det er fint, hvis det giver mening, at der er nogle af projekterne, der fx har en agil leverancemodel. Hvis det giver mening, så er det sådan set fint, men vi skal stadig have styr på governanceen og den styring, der ligger ned over det agile, fordi ellers så hænger det ikke sammen på tværs. Så skal vi fastlægge programmet styringssæt op, så vi kan sove roligt om natten. Det vil sige, at vi ved, at vi kan svare på, hvor langt vi er kommet. Vi kan svare på, hvor mange penge vi har brugt. Vi kan svare på, hvad vi har færdiggjort og hvad vi mangler. Og vi kan svare på de største risici osv. osv. osv. og fortælle, hvad er det, vi leverer i den kommende periode. Ja. Så det her, det er 11 hacks, som vi tænker. Lidt kægt, men hvis man gør det, så bliver ens opgave som programleder, det letter. Og vi synes sådan set også, at vejen til succes, den kommer lettere. Vi er igennem programmet. Men bare lige sådan i forhold til, det kan være, at du er blevet nysgerrig på mere. Det kan være, at du sidder med et program, som kører helt af helvede til. Eller at du skal starte noget op, og sådan set rigtig gerne vil have noget at støtte i det. Der står både Helles og mine kontaktoplysninger, og I skal være særdeles velkommen til at kontakte os. I kan også vælge den anden vej. Det er, hvis det har givet mening, det I har hørt på her, så køb vores bog. Og så det sidste, det er, at vi den 6. oktober, der går vi ind i noget andet, end vi har gjort i dag. Vi går ind i temet omkring, hvordan får du modtaget organisationen ombord på dit program. Og hvem er det, vi har inviteret? Ja, I har faktisk fået en teaser i dag, fordi det webinar holder vi sammen med DSB's store program, som kommer og fortæller noget om, hvordan får du skabt et pull for modtagereorganisationen frem for, at du som program står og prøver at pushe ting ud til dem. Så hvordan gør du egentlig det, så du får lagt grundlaget for vores tredje element, kan man jo kalde det? Omkring implementering og gevinstrealisering. Præcis. Og efter det her, det bliver ikke lige sådan om en time, men I får slides ud, udvalgte slides, og I får også et link til, man kan sige, den her session, som I kan dele med jeres kollegaer og se, så de kan se det. Det er ganske gratis, skulle vi måske tilføje. Det må man sige. Og vi har lovet at svare på spørgsmålet, der er nogen. Ja, det har vi også. Så tusind tak for i dag, og vi håber, at det har været inspirerende. Hæn det sig taget efter mulig. Abraham