Programstyring Posts

Her er de manglende brikker mellem projekt og værdiskabelse!

Helt ned i de fineste detaljer kan vi definere alting i et projekt, men når det kommer til at beskrive elementerne i forretningsudvikling (som projekter jo oftest er en del af) så kniber det.

På ‘vores’ side af kløften har vi defineret vores leverancer, og så rækker vi ellers ud med Formål og Succeskriterier, så vi føler, at vi ved, hvad det hele drejer sig om, og ved hvordan formålsopfyldelsen skal måles op til sin tid. Vi tager ikke ansvar for det; men erklærer i stedet, at vores projekts leverancer efter vores allerbedste viden MEDVIRKER til formålsopfyldelsen. Ansvaret ligger på den anden side!

På den anden side af kløften står ledelsen sultne efter benefit’ene i cost/benefit-analysen. Ledelsen rækker ud med et budget og en deadline, og sammen med vores leverance får vi nu skabt en aftale i form af projekttrekanten. Problemet er jo bare, at den kun sikrer, at budgettet bliver brugt i en fart. Selvfølgelig kommer de leverancer, som vi lovede også, men så er forbindelsen mellem de to sider af kløften også brudt. Nu må ledelsen der ovre klare resten!

Det er ikke så meget fordi vi ikke vil knytte en bedre forbindelse. Det er snarere fordi vi ikke har et begrebsapparat til det. Hvis vi kunne beskrive og forklare processen hen til, at værdiskabelsen rent faktisk finder sted, så havde vi et grundlag for i det mindste at drøfte et mere vidtrækkende ansvar for projektlederen, end projekttrekanten lægger op til. Sproget til at beskrive processen er bare ikke ret kendt, men det findes i det efterfølgende.

Hvis  man skal beskrive forretningsudvikling, så er succeskriterier ikke nok. De beskriver en sluttilstand; men intet om vejen der hen, og det er jo netop vejen, vi er interesserede i – i vores brobygningsarbejde. Man skal i stedet have fat i begrebet kapabilitet eller formåenhed. En organisation er et samsplil mellem mange enheder, hver med sine kapabiliteter eller formåenheder. Når ledelsen ønsker forretningsudvikling, så skal der skrues op for kapabiliteten rundt omkring, så organisationen kan gøre mere, hurtigere, bedre, billigere eller hvad det nu er, der er dagsordenen. Hver del af organisationen, som er omfattet af forretningsudviklingen, skal løftes til en FØK, Forretningsmæssig Ønsket Kapabilitet. Det kræver ofte en projektleverance i form af et nyt IT-system eller en ny maskine eller en ny arbejdsproces; men det kræver sikkert også nogle ændringsaktiviteter i form af noget uddannelse, nogle organisationsændringer og måske endda nogle holdningsmæssige ændringer. Til sammen ser brikkerne eller måske rettere puslespillet således ud:

De røde brikker viser sekvensen eller logikken i opbygningen af den ønskede kapabilitet. Først må en ting løftes før en anden ting kan løftes osv. Ligesom projekter har planer for udvikling af sine leverancer, så udgør de røde brikker planen for udvikling af forretningen. De grønne viser forandringsdelen (af programmet) og de blå projektleverancerne (i programmet).

Nu mangler der kun at blive lagt nogle få brikker, før vi er ovre kløften og fremme ved værdiskabelsen og dermed pengene i kassen – hvis det var formålet. Logikker er her, at hver FØK giver nogle fordele eller benefits. Det kunne være hurtigere sagsbehandlingstid, større forsyningssikkerhed, lavere sygefravær eller f.eks. større kundetilfredshed. Fordelene kan i sig selv være værdifulde og umagen værd; men nogle af dem har sikkert også en pengemæssig værdi i form af f.eks. reducerede omkostninger, større omsætning eller måske større overskud, og det er her business casen viser, at hele manøvren er umagen værdi – indtægterne overstiger udgifterne! Værdien er imidlertid ikke statisk. Den afhænger af de værdiregulatorer som er f.eks. antal borgere, størrelsen af lageret, antal henvendelser pr. kunde og lign. Regulatorerne er vigtige at have med, fordi de forklarer, hvilke faktorer der er i spil, når benefit-siden i en businesscase skal beregnes og især når den sidenhen skal eftervises! Hermed kom puslespillet til at se således ud: Og hermed er der skabt transparens i hele forretningsudviklingen, og vi har fået en solid forbindelse over kløften. Vel at mærke en forbindelse som kan planlægges, defineres, ansvarsfordeles præcist som vi kender det i projekterne.

Har du lyst til at studere disse ting yderligere, så kik indenfor her eller tag et kursus her eller en certificering i metoden her. Det stammer alt sammen fra TotallyOptimizedProjects.com med hovedkvarter i Melbourne. Jeg er selv på vej til en certificering, så betragt dette indlæg som udtryk for min nuværende viden.

Gør som 2.300 andre. Tilmeld dig gruppen og følg blog’en her på Linkedin. Så får du automatisk mine indlæg som notifikationer.

Når alt det normale er prøvet, så er der kun det unormale tilbage!

De fleste organisationer har i årenes løb vandret håbefuldt på de mange strabadserende stier mod perfekte projekter og succesfulde projektinvesteringer. Det har hjulpet lidt; men sjældent væsentligt, så nye tiltag har måttet afprøves, og derefter nye igen; men få ledere føler vel i dag, at det virkelig har rykket noget?

Er det mon så fordi, vi ikke har tilstrækkelig gode projektværktøjer, eller kan det mon tænkes, at vi prøver at løse problemerne fra den forkerte ende? Forstået på den måde, at der tidsmæssigt er projekt i den ene ende og forretning i den anden. Vi hælder penge og tid ind i den ene ende, og håber så på, at der kommer penge ud i den anden. Vi anstrenger os vældig i den ene ende og håber så på idel lykke i den anden. Så lykkeligt ender det dog desværre sjældent, så derfor må der jo være noget i vejen med projekterne – konkluderer en ledelse hurtigt (hvis skyld skulle det ellers være?), og så er f….n løs – igen!

Når en organisation har ondt i sine projekter, drejer alle de normale tiltag sig udelukkende om den ene ende – den først ende – projektenden; men selv de fineste metoder og værktøjer i den ende hjælper jo ikke, hvis der er fejl i den anden! Man kan også sige det på den måde, at det ikke hjælper på en fejl, at den meget omhyggeligt bevares og forfines og gennemføres efter alle kunstens regler – det er stadig en fejl! Som en metodeansvarlig i en af Danmarks dygtigste projektvirksomheder meget apropos engang sagde: “Efterhånden som vi får mere og mere styr på projekterne her nede, bliver det tydeligere og tydeligere, at problemerne findes der oppe!”.

Det er på høje tide, at vi begynder at arbejde meget meget mere på den forretningsmæssige side af sagen. Vi bliver nødt til at tænke på helt nye måder. For at hjælpe vores projekter, bliver vi nødt til at vende ryggen til dem og tvinge de forretningsansvarlige ned på skolebænken for at lære at tænke forretningsudvikling på en helt ny måde. Slut med at bruge 15 minutter på ledermødet med at beslutte et projekt, som efterfølgende tager 50.000 timer at hitte ud af og føre igennem. Slut med: “Jeg har en fantastisk idé, så lad os hurtigst muligt få sat et projekt i søen”. I det hele taget slut med vanetænkningen om at “detaljerne må projektet sandelig rede ud, for nu har vi jo sat målene op!”. Ansvaret for projekterne må og skal tilbage til der, hvor det hører hjemme; nemlig hos de forretningsansvarlige. De skulle aldrig have lagt det ud til projekterne. Det er den værste og dyreste fejl ledelser har begået i 75 år. Vi må (igen) lære at tænke:

  • forretningsmål før projektmål
  • forretningsværdi før projektomkostninger
  • alle potentielle forretningsfordele i stedet for lige nok til at dække projektomkostningerne
  • forretningsfordele før økonomiske mål
  • opnåede forretnings kapabiliteter i stedet for projektleverancer
  • forretningsmæssig transparens før projektplanlægning
  • forretningsmæssige risici før projektrisici
  • benefits før costs
  • forretningsmæssig status før projektstatus
  • og meget meget mere
Gør som 2.300 andre. Tilmeld dig gruppen og følg blog’en her på Linkedin. Så får du automatisk mine indlæg som notifikationer.

En ligning med een ubekendt er stadig det største problem for alle projekter

Første linje kan vi nogenlunde forstå og styre; men det kniber stadig med næste linje, og derfor må vi igen og igen kikke i vejviseren i stedet for i kassen efter de lovede penge. Den store udfordring er at få miraklet erstattet med specifikke og især målbare og især ansvarsplacerede aktiviteter og mellemregninger, så vi helt nøjagtig kan følge op på hvert eneste skridt frem mod pengene i kassen.

Vi står med problemet, fordi projektledelse alt for længe har drejet sig om at skabe i leverancer i stedet for forretningsmæssige forbedringer. ‘IT-system implementeret’ er en typisk leverance; men det betyder jo ikke automatisk, at så kan forretningen pludselig en helt masse nye ting. Inden da, skal der uddannes, processer skal tilpasse, fødesystemer tilrettes, kultur og holdninger justeres og meget meget mere. Projekter tegner typisk skillelinjen ved leverancen, “og så må forretningen klare resten”, men det er en grænsedragning, som kun tilgodeser projektlederens behov for at vise resultater og ulykkeligvis slet ikke formålet med projektet.

Vi bliver nødt til at flytte skillelinjen og dermed projektets ansvar lidt længere ‘mod højre’ hen imod pengene i kassen. Vi bliver nødt til at gøre projekterne ansvarlig for konkrete forretningsmæssige forbedringer eller ændringer, så vi præcist kan måle, om vi kan eller ikke kan alle de nye ting, som vi ønskede, dengang vi satte projektet i søen. Kan vi alle de nye ting, så har vi fået nogle forretningsmæssige fordele, som måske og måske ikke kan føre til penge i kassen. Det sidste kan ingen projekt garantere. Det er en forretningsmæssig satsning ligesom alle andre investeringer.

Få har knækket nødden; men den kan altså knækkes!

Gør som 2.300 andre. Tilmeld dig gruppen og følg blog’en her på Linkedin. Så får du automatisk mine indlæg som notifikationer.

Programstyring javel; men hvornår er det en god idé?

Begrebet programstyring glider lige så stille ind i vores sprogbrug; men ved vi lige, hvad det er, begrebet dækker over? At programmer består af flere projekter, ved vi godt, og vi ved også, at projekterne i programmet har noget til fælles – som gør det værd at koordinere dem – altså formålet med programstyringen. Havde de ikke haft noget til fælles, kunne vi i stedet for et program have samlet dem i en portefølje. At porteføljer så ofte har et strategisk sigte og derfor alligevel bringer en fælleshed ind i samlingen af projekter, og derfor gør, at de også kunne kaldes et program, er en mindre detalje.

Det interessante er, hvilke former for fællesskab en klynge projekter har, fordi heraf kan man nemlig se, hvilke fordele der kan opnås ved at styre klyngen som et program – man kan med andre ord se formålet med programstyringen.

Nedenfor er vist nogle af de hyppigste former for fællesskaber og formålet med at koordinere dem:

Fællesskab blandt en klynge projekter Formål med programstyring Eksempel på succeskriterier for programstyringen Eksempler
De bidrager til samme produkt, og projekterne kan være innovative. At koordinere målbeskrivelserne på tværs af projekterne i takt med at idéer og erfaringer udvikler sig. Alle projekter er align’et senest 4 dage efter en godkendt ændring. Programbudget overholdt med +/- 25% Udvikling af næste iPhone omfattende projekter for bl.a. chassis, software, interface, markedsføring, produktions-tilpasning, salgskanaludvikling m.fl.
De bidrager til samme forandring; men nødvendig omfang af forandringsindsats er usikkert. At dimensionere, igangsætte, koordinere og stoppe projekter indtil forandringen er helt indarbejdet. Programmets succeskriterier er nåede Digitaliseringsstyrelsens Programmodel
De anvender den samme viden/erfaringer. Sikre at viden opsamles, distribueres og især benyttes i alle projekter. Månedligt at 90% af projektlederne føler sig godt eller meget godt opdaterede om programmet Udbredelse af konceptet Nyt Nordisk Mad overalt i hele Skandinavien.
De anvender de samme ressourcer/specialister. Sikre en prioritering af projekterne i forhold til deres vigtighed for programmets formål. At ressourcebehovene er prioriterede 6 mdr. frem. Tvister afgøres samme dag. Udviklingsprogrammer som kræver kostbart udstyr eller råmaterialer eller trækker på unikke specialister.
De har de samme risici. At sikre effektiv risikostyring og anvendelse af de indhentede erfaringer med de besluttede foranstaltninger mod risici. Foranstaltninger mod risici er ajourført og iværksat på tværs af projekterne senest 2 dage efter en uplanlagt hændelse. Større anlægs-programmer f.eks. landdelen af Øresundsforbindelsen.

Når alle fællesskaberne er til stede i samme program, er det let at se de store krav, det stiller til programlederen, og man fornemmer samtidig, at programstyring er noget helt andet end projektledelse.