Implementér flere programmer tak! - Peak Consulting Group

Mere program tak

Peak Consulting Group»Artikler»Mere program tak

Mere program tak

Mange organisationer svømmer over i projekter, hvorimod programmer er et noget sjældnere syn.

 

Det er ærgerligt, for de fleste projekter kunne have glæde af lidt programtryllestøv.

Det er på tide at tænke program, hvis I fx står i en situation, hvor I har brug for at koordinere en række indsatser, som kræver involvering af ledere og medarbejdere i flere (drifts)afdelinger.

En indsats, hvor der er behov for at sætte fokus på den organisatoriske implementering, så de ønskede resultater og gevinster realiseres, hvor der skal identificeres og implementeres forandringer i en længererækkende strategi, hvor der allerede er flere opgaver i pipeline, end I kan nå at afslutte.

Her er et par bud på programredskaber, der kan skabe værdi i din organisation.

Projekter er alle vegne. Hvad enten der skal bygges en Storebæltsbro eller anlægges et urtebed hjemme i haven, bliver det udråbt til et projekt. Selv planlægningen af firmajulefrokosten kandiderer til at få plads i porteføljen. Den slags kræver ressourcer, forstås.

Anderledes forholder det sig med programmer. Dem ser man ikke så ofte, og når man endelig støder på programmer, er det ofte ”bare” store projekter med en lang række underaktiviteter, der peger i forskellige retninger – altså en slags miniportefølje. Det er synd, for der er meget at hente i programtanken.

Men hvad er et program egentlig?

Best practice-rammeværket Managing Successful Programmes (MSP) siger, at hvor projekter handler om leverancer (output), vil fokus i programmer være på effekt (outcome).

Programmer leverer noget nyt, som en organisation bliver i stand til, så der opstår gevinster, der i sidste ende opfylder strategiske mål i organisationen.

En organisation bør altså etablere et program, når der er behov for en tværgående og overordnet koordineret indsats med fokus på forandringer og gevinster over en længere tidshorisont. Her vil et program sikre, at strategien implementeres. Ifølge teoribøgerne vil programmer typisk køre i flere år og rumme (dele af) gevinstrealiseringen, mens projekter leverer et produkt og overlader det til driften at høste frugten efterfølgende.

Inden vi ender i skyttegravskrig om, hvad projekter og programmer er og ikke er, så lad os henvise til den gamle traver om, at i teorien er der ikke forskel på teori og praksis – men det er der i praksis. Eller sagt på en anden måde – selvfølgelig kan man finde projekter, der anstrenger sig for at følge leverancen helt til dørs – og såkaldte programmer, der ikke gør.

Men! Vi vil altså alligevel vove den påstand, at mange organisationer lider under projekter, der er (for) snævert fokuseret på leverancerne og ikke formålet med dem. Det er ofte en udfordring i et klassisk projekt-setup, at en midlertidig organisation skyder bolden ind i feltet, men det er basisorganisationen, der skal heade den i mål. Alt muligt kan gå galt i det samspil.

Hvad er der så at hente i programtanken?

Først og fremmest skal du spørge dig selv og din organisation:  

  • Hvad er formålet med projektet?
  • Hvilke vilkår har projektet?
  • Hvem skal anvende projektets leverancer?

Hvis erfaringen og konklusionen er, at det er svært at få skruet løsningen fast på den gamle organisation – så er det værd at skele til programværktøjskassen. Og så er det langt hen ad vejen mindre vigtigt, om I kalder indsatsen et projekt eller et program. Her er tre Managing Successful Programmes-bud på emner, du bør overveje:

1.MSP-principperne

Det lyder måske lidt tørt, men vi vil gerne slå et slag for de overordnede leveregler bag MSP.

Ligesom PRINCE2 og mange andre rammeværker, opstiller MSP en række principper, man bør (skal) følge aktivt og i hvert fald ikke afvige fra – se dem her.

I en nøddeskal handler de om at orientere sig efter organisationens mål – altså hvor er vi på vej hen, hvordan kommer vi derhen, og hvordan bidrager lige netop dette projekt til målet.

Det lugter af strategisk ophæng, forandringsledelse og gevinstrealisering, som ofte er en del af projekterne, men det bliver ofte ikke omtalt sådan.

2.Business change managers

I MSP er Business change manager en prominent rolle med sæde i programstyregruppen og med en længere liste over centrale opgaver.

Termen Business change manager dækker ikke i denne sammenhæng over eksperter i forandringsledelse. De er repræsentanter fra dem, der skal bruge leverancerne.

De skal sikre, at organisationen er klar til at tage imod leverancerne og er i stand til at anvende resultaterne, så organisationen når sine mål.

Business change managers er typisk mellemledere af en art. Her er der ikke tale om en PRINCE2’sk seniorbruger, der skal udpege ressourcer og tage imod, når projektet er ved vejs ende.

Det er en anderledes aktiv funktion, der udover at være forbindelsesofficer med fingeren på pulsen ude i organisationen også sikrer den nødvendige forandring hos dem, der tager imod leverancerne, og følger op på, om det ønskede mål (gevinsterne) indfries.

3. Blueprint

Et central MSP-dokument er blueprintet. Business change manageren bidrager meget aktivt til, at det bliver udarbejdet.

De fleste direktioner har en vision for organisationen – og nogle projekter formår også at formulere en forandringsvision for, hvad projektet skal bidrage med.

Et blueprint graver spadestikket dybere og beskriver den fremtidige organisation, arbejdsgange og processer, den fornødne viden og teknologi.
Altså hvad der skal til for at nå til en ønsket the future state.

Det er mellemtingen mellem de himmelragende hensigtserklæringer og de detaljerede planer for, hvordan man så helt konkret kommer fra land.

Det er stadig overordnet nok til, at direktørerne kan være med, men konkretiserer samtidig den nye virkelighed på et niveau, der gør det muligt at ”forhandle” et fælles billede af fremtiden.

Derfor er det vigtigt, at blueprintet bliver lavet sammen med dem, der er slutmodtagere af indsatsen, så er implementeringen også allerede i gang.


Så. Programmer eller projekter. Det er ikke det centrale.

Det vigtigste er at have et helhedsperspektiv.

Du skal aldrig bare levere en dims. Løft blikket – og kig i programværkstøjskassen.