Hvad koster det projekt, som du gerne vil gå i gang med? Hvordan ser det forventede udbytte ud? Og hvilke risici er forbundede med projektet? Det er alt sammen nogle spørgsmål, som du skal forholde dig til, når du udarbejder en business case.
I dette indlæg vil du lære, hvordan du udarbejder en effektiv business case til dine projekter. Du lærer med andre ord, hvordan du skaber rammerne for et realistisk projekt, hvor der er fokus på økonomien, realisering af gevinster og styring af omkostninger.
Det at lave en business case var i starten noget af det, jeg kæmpede meget med. Jeg var ikke helt sikker på, hvordan man skulle gøre, og vidste ikke, hvad den skulle indeholde.
Jeg synes, det var svært at finde ud af, hvor meget vægt man skulle lægge på problemet, på den nye løsning og på økonomien.
Så jeg har brugt en del tid på at læse op på det og taget kurser i business case skrivning. For business casen er ultimativt den som afgøre, om projektet bliver accepteret eller lagt i skuffen.
Så det er vigtigt, at den er gennemarbejdet, og at styregruppen mener, den er plausibel.
Hvad er en business case?
En business case bliver lavet relativt tidligt i projektet, det er typisk afslutningen på opstartsfasen, og den sidste opgave, inden der bliver givet et “Go!” fra projektets styregruppe. Man laver typisk en business case for alle større projekter og tiltag. Dem som typisk vil være meget ressourcekrævende (tid eller penge) eller som vil drive virksomhedens strategiske målsætninger.
Hvad består en business case af?
En idébeskrivelse, der beskriver hvad dit projekt går ud på. Projektets målsætninger, der beskriver hvilke positive effekter projektet vil levere. En projektplan, der beskriver hvordan du vil drive projektet, og hvornår det kan leveres. En business case samler alt dette i en beskrivelse, der giver et samlet overblik over projektet.
En business case er derfor “den fulde historie” der fortæller læseren om den forventede Return on Investment for en given investering.
Du skal hele tiden have dette i mente. Et projekt er som ofte en investering, og der skal derfor helst gerne kunne vises, at denne investering kan give virksomheden et positivt afkast.
En business case starter altid med at forklare, hvorfor man vil starte projektet, derefter sættes der mål for, hvad man ønsker, at få ud af projektet, og derefter fortæller man, hvordan man vil gøre det.
Derudover forudser en business case omkostninger, fordele og risici ved et projekt, så beslutningstagere kan beslutte, om et projekt er umagen værd, og hvorfor man vælger en fremgangsmåde i forhold til lignende strategier.
Hvorfor skal man lave en business case?
En business case er retfærdiggørelsen for investeringen i projektet, både når det kommer til tid, penge og ressourcer, og måler investeringen op imod den mulige gevinst, der er ved projektets slutprodukt. En business case samler derfor alle informationerne som styregruppen skal bruge for at kunne sige ja eller nej til et projekt.
En business case skal ses som et nøgledokument for en projektleder, når man planlægger, driver og evaluerer projektet. Det er det sidste dokument der skal laves inden du kan starte projektet, og meget af det har du allerede lavet i forvejen hvis du har fulgt min guide til projektledelse, som du kan downloade nederst på siden her.
En velskrevet business case flyder logisk fra at præsentere et problem eller mulighed gennem fordele og ulemper ved løsninger til beskrivelse af den anbefalede løsning. Indholdet skal være let at scanne, så den er hurtigere og mindre overvældende at læse for styregruppen. Følgende er de almindelige sektioner i en business case i rækkefølge:
- Executive summary
- Projektets idébeskrivelse
- Projektets målsætninger
- Projektets krav
- Projektplanen
- Estimering af omkostninger og gevinster
- Projektets risici
- Projektlederens anbefaling
Projektets idébeskrivelse
Dit første skridt i oprettelsen af en vellykket business case er at identificere og forstå et relevant forretningsproblem, som din business case vil løse. Hold eventuelt en brainstorming-session med din projektets interessenter og virksomhedens beslutningstagere for at forstå de problemer, der opstod, og de forretningsmæssige konsekvenser det har for virksomheden.
Det er afgørende at definere problemet og parameteren klart og tydeligt, så alle kan se problemet, og en potentiel løsning til det.
Du kan læse mere om dette i mit indlæg: Sådan laver du en god idébeskrivelse.
Du skal måske formulere det en smule anderledes, for at sikre dig at der er et godt flow i din business case, men du kan nok bruge 90% af din idébeskrivelse direkte i business casen.
Projektets målsætninger
Det næste som du skal kigge på, er at definere målene med projektet, altså hvad vil I gerne opnå ved at drive projektet.
Desværre er der mange projekter som ender med at blive set som en fiasko, ikke fordi der var noget galt med idéen, eller eksekveringen af projektet, men derimod, fordi målsætningerne for projektet var uklare.
Derfor bliver et succesfuldt projektet, nogle gange set som en fiasko, fordi man før man startede projektet ikke var blevet enige om hvornår projektet ville være en succes.
Har du fulgt min guide til projektledelse, så har du allerede lavet dette dokument, og du kan derfor bare kopiere den tekst ind i denne del af business casen. Ellers kan du læse mere om det her: Guide til at fastsætte projektets målsætninger
Skab overblik over projektets krav
Det næste du skal kigge på, er at give læseren af business casen en idé om hvordan du forventer at opnå disse mål.
Det gør du på to måder, du fortæller læseren hvad kravene til projektet kommer til at være og derefter præstere projektplanen. Men mere om det nedenfor.
Du skulle gerne have lavet en kravspecifikation for projektet inden du går i gang med din business case, så du skal bare nedkoge den en smule, og tage de vigtigste krav fra den og inkludere dem i din business case.
Har du ikke lavet en kravspecifikation, så kan du følge min guide: Sådan laver du en god kravspecifikation!
Så jeg vil ikke råde dig til at skrive alle dine krav ind i business casen, men mindre at du ikke har så mange krav i din kravspecifikation.
Der er ikke et specifikt antal du skal inkludere i businesscasen, men har nogen gange set at man bare har inkluderet de 3-4 største, og jeg har set andre hvor man har inkluderet mere end 20. Begge fungerede fint, så antallet er ikke så vigtigt.
Det er alene størrelsen af kravene som er vigtige.
Krav som du eksempelvis kunne inkludere:
- Webshoppen skal være mobilvenlig
- Webshoppen skal overholde vores designguide
- Alle kunders data skal migreres til den nye webshop
Krav som du ikke bør inkludere kunne være:
- En bruger skal kunne logge ind
- Webshoppen skal have slider på forsiden
- Købsknappen skal være grøn
Som du kan se ovenfor, så er det de større, og mere overordnet krav som du skal inkludere. De meget specifikke som farven på købsknappen skal bare forblive i kravspecifikationen, da det ikke påvirker beslutningen om der skal investeres i projektet.
Lav en projektplan for projektet
Nu skal du indsætte din projektplan i kravspecifikationen. Du har sikkert allerede lavet en, hvis ikke, så vil jeg råde dig til at læse mit indlæg: Sådan laver du en god projektplan
Der får en en trin-for-trin guide til hvordan du laver en projektplan.
Men det er vigtigt at inkludere en detaljeret tidsplan og tidsramme for projektet for at give beslutningstagerne en forståelse for omfanget af projektet.
Tag generelt at være en smule pessimistisk, det er ikke unormalt at projekter går over tid. Hvilket giver god mening, der er rigtig mange bevægende dele, så der er mange ting som kan forsinke projektet.
Jeg tager derfor tit og tilføjer omkring 20% ekstra tid og budget, netop for at “forudse” dette. Og allerede fra starten har denne buffer.
I starten var jeg lidt imod dette, men jeg så bare gang på gang, at det var nødvendigt. Så i dag tilføjer jeg altid denne buffer.
Plus, hvis der ikke sker noget uforudset, så bliver du bare færdig før tid og under budget, så det er jo kun positivt.
Estimér omkostninger og gevinster
Når projektet nu er blevet gennemgået, og alle har en god idé om hvad det går ud på, så er det tid til at kigge på omkostninger og forventede gevinster ved projektet.
For det meste vil du helst have projekter der har en højere potentiel gevinst end omkostninger, men jeg har også set flere projekter gå igennem, selvom det ikke var sådan.
Så du skal altså estimere projektets risk/reward-ratio.
Det er med andre ord en estimering af hvad det vil koste, kontra hvor meget virksomheden vil få ud af projektet. Det kan både være i form af besparelser, højere produktivitet eller øget indtjening.
Du har nok allerede estimeret dit projekt, men har du ikke det, så kan du læse mig indlæg: Lær hvordan du estimerer dine projekter
Så tag dette estimat, og sæt det op imod projektets målsætninger. Kommer projektet til at koste 500.000 kr., og projektets målsætning er at øge omsætningen med 10% de næste 3 år i en virksomhed der omsætter 200 millioner om året, så er det jo en fantastisk forrentning af pengene.
Dette var et eksempel på et meget rentabelt projekt, hvis det opnår projektets målsætninger. Men mange projekter bliver ikke tilbagebetalt allerede første eller andet år.
Jeg sigter normalt efter at have projekter som er tilbagebetalt inden for 5 år. Hvis det vil tage mere end 5 år at tilbagebetale projektet, så vil jeg hellere se på hvordan jeg kan minimere omkostningerne, eller ændre scope på projektet, som kan have en positiv effekt på projektets målsætninger.
Med eksemplet ovenfor kunne jeg enten skære noget fra, så projektet kun vil koste 450.000 kr. at lave, eller jeg kan gå den modsatte vej, og bruge 100.000 kr. mere, altså 600.000 kr. totalt set, men så sætte projektets målsætning til 15% i stedet for 10%.
Dette vil jeg kun gøre hvis jeg rent faktisk har belæg for at det er en mulighed at bevise det øget potentiale.
En hurtig note her, husk både at kigge på projektets engangsomkostninger (projektpris) og projektets løbende omkostninger (licenser, software, royalties osv.)
Projektets risici
Derefter giver det mening at forklare de potentielle konsekvenser og tab, der kan være resultatet af at drive projektet.
Det er vigtigt at være ærlige fra starten, hvis du allerede nu kan se potentielle problemer med projektet.
Det kunne eksempelvis være kunder som vil forlade virksomheden hvis I lancerer et nyt system, fordi det nye system ikke understøtter deres behov.
Det kunne også være interne arbejdsprocesser. Det er især relevant for projektledere i større organisationer, hvor der er en proces for alt.
Du kan også kigge på om det vil skabe cash flow‐problemer for virksomheden, eller hvad en forsinkelse eller budgetoverskridelse ville påvirke virksomheden.
Du kan også bruge lidt plads på at beskrive konteksten af dit projekt ved hjælp af SWOT (Styrker, Svagheder, Muligheder, Trusler) eller PESTEL (Politisk, Økonomisk, Sociologisk, Teknologisk, Miljømæssig og Juridisk forhold) analyserne.
Grunden til at du skal skrive dette ind i din business case, er at styregruppen, hvis projektet bliver godkendt, kan være med til at minimere eller fjerne disse risici.
Noget mange glemmer at inkludere i dette afsnit er tit hvilke risici som kan forekomme hvis virksomheden ikke foretager sig noget, altså ikke starter projektet.
Disse risici er lige så vigtige at huske at nævne, da mange projekter ikke bliver startet fordi styregruppen er bekymret for risikoen ved projektet. Men hvis de ser at der også er mange risici ved ikke at foretage projektet, så er der større chance for at de går med til det.
Det kunne eksempelvis være at vores konkurrent har lanceret en lignende løsning, og at vi ser at han vinder flere kunder på det seneste på grund af det. Så hvis vi ikke laver en lignende løsning til vores kunder, så vil vi blive ved med at miste kunder.
Projektlederens anbefaling
Den sidste del af din business case bør være din anbefaling. Hvad mener du? Bør I starte projektet på baggrund af det arbejde du har lavet her?
Det er ikke altid at jeg anbefaler det. Nogle gange kan denne business case proces vise mig at det ikke er det værd, det er enten for dyrt at lave projektet, eller gevinsterne er for små.
Denne del af business casen behøver ikke at være så formel. Se det som en uformel konklusion, hvor du skriver dine tanker og din anbefaling.
Husk dog at have noget fakta at bakke din anbefaling op på. Det nytter ikke at skrive “Jeg mener ikke vi skal gå videre med webshop projektet”, skriv i stedet. “Jeg mener ikke at vi skal gå videre med webshop projektet fordi omkostningerne og de mulige gevinster ved udførelsen af projektet ikke giver et tilfredsstillende afkast for virksomheden.”
Executive summary
Slut af med at skrive et Executive summary i starten af business casen, hvor du på så få ord som muligt summere alt op uden at man går glip af noget.
Dette er vigtigt fordi det er sjældent at alle du sender business casen til som læser den fra enden til anden.
Jeg vil næsten sige baseret på min erfaring, så er det under 10% som overhovedet læser den. Resten skimter den bare igennem.
Men hvis du laver en executive summary, helst på en side, så er der meget større chance for at folk får dem læst.
Den skal indeholde de vigtigste overvejelser, der senere vil blive drøftet mere detaljeret, herunder idébeskrivelse, målsætninger og projektplan, samt de forventede fordele og omkostninger ved implementering af business case.
Begynd gerne dit executive summary med sprog som f.eks. ”Denne business case forsøger at opnå [projektets målsætninger] ved at [projektets idébeskrivelse i overskrifter]. Der leveres en evaluering og analyse af alle relevante økonomiske, markedsførings- og forretningsomkostninger og overvejelser forbundet med implementering af projektet i denne business case. Projektet estimeres til at koste [kr.] og [interne ressourcer] og forventes at være færdig [dato/måned/kvartal]”
Derefter kan du gå dybere ned i din metodik og hvordan du vil løse problemerne, men husk der er begrænset plads i denne sektion af business casen. Og du skal huske på hvem det er der skal læse denne del af business casen.
Så jeg vil faktisk efter denne indledning gå direkte ned i tallene. Det er ultimativt det som styregruppen eller projektsponsoren er interesseret i.
Så hav i stedet fokus på tallene, altså projektets omkostninger, gevinster og risici. Og lav det gerne så det er let at skimte, så lav en graf, tabel eller lignende. Det er vigtigt at de meget hurtigt ser at det er en fordel at sig ja til projektet.
Etabler business casen
Vælg format
Så, nu er der nogenlunde styr på indholdet i din businesss case, så lad os kigge lidt på formatet. Med andre ord, hvordan skal du fortælle denne historie.
En business case kan både være et langt formelt, struktureret dokument; et uformelt kort dokument; eller en verbal udveksling.
Så der er altså ikke nødvendigvis et fast format for en business case.
Men for det meste ser man en business case som en PowerPoint‐præsentation, et medfølgende word-dokument som pre-read og et Excel‐ark med eventuelle estimater på projektet.
Det er typisk disse tre formater som jeg bruger, men det er ikke altid, jeg har et Excel‐ark med, det er kun hvis jeg mener det er relevant.
Jeg ville helt sikkert inkludere et Excel‐ark hvis projektets målsætninger omhandler øget omsætning eller reducering af omkostninger, og deri Excel‐arket lave dine estimeringer af hvordan du forventer at opnå målsætningen.
Lav første udkast
Start med at lave det første udkast til din business case. Husk, den skal ikke være perfekt i første forsøg. Bare få skrevet de vigtigste ting ned, og formulér det så godt som muligt for nu.
Hvis du følger guiden ovenfor, så har du det vigtigste med. Følg også gerne strukturen ovenfor, på nær executive summary, den skal gerne være på første side, men du skriver den typisk som det sidste.
Læs første udkast igennem
Når du har afsluttet et første udkast til din business case, skal dit næste skridt være at nøje gennemgå din business case for unødvendige sprog- og grammatiske fejl. Sørg for, at din business case er formateret på en måde, der er let at læse.
Få aftale og feedback fra dem, der er ansvarlige for implementeringen. Selv om de normalt ikke er beslutningstagerne, så er det den bedste måde at sikre, at din business case bliver succesfuld, ved at sørge for, at dem der skal være ansvarlige for at gennemføre planen, har mulighed for at gennemgå business casen og give forslag til ændringer.
For eksempel hvis din business case foreslår implementering af en ny markedsføringsstrategi som et middel til at komme ind på nye markeder, bør du bestemt tage dig tid til at mødes med marketingteamet for at sikre, at processerne i din business case kan implementeres af teamet.
Præsenter din business case
Din business case skal præsenteres for projektets styregruppe, de er nemlig ansvarlige for at give godkendelse til nye forretningsstrategier eller planer.
Du skal gerne begynde med det problem, eller det mål, som din business case løser. Derfra taler om den løsning, der leveres af din business case, samt de forskellige muligheder og skridt, der skal tages for at implementere løsningen.
Du behøver ikke nødvendigvis at have en powerpoint, jeg har også set folk bruge Prezi, video og en demo af en POC som deres business case.
Brainstorm på forhånd om eventuelle bekymringer, som styregruppen måtte have omkring implementeringen af business case-planen. Sørg for at have svar på disse bekymringer under din præsentation i stedet for at vente på, at styregruppen rejser deres bekymringer.
Skal man have flere alternativer i samme business case?
Det er ikke unormalt at have et par alternativer at styregruppen kan vælge imellem, men brug mest tid på det mest sandsynlige.Du kan eksempelvis have et low budget alternativ og et premium alternativ ved siden af din anbefaling. På den måde har styregruppen nogle alternativer hvis det viser sig at du har skudt for højt eller lavt i forhold til budgettet.
Hvad er en typisk fejl når man laver en business case?
Jeg har her givet dig en skabelon som du kan bruge til din business case, men den typiske fejl, som mange laver når de skriver deres business case er faktisk at de blindt følger en skabelon. Skabelonen er et godt udgangspunkt, men du skal gerne tilpasse den fra projekt til projekt og virksomhed til virksomhed. Vi er alle forskellige og har forskellige behov.
Overvej, hvem business case er til
Det næste du skal overveje, er hvem der skal læse din business case. Herunder skal du også overveje hvilken branche du arbejder i, samt hvilken formaliteter som der er i din virksomhed.
Disse kan være med til at dikterer hvad der er i dine business case, og hvordan den skal struktureres og formuleres.
Det kunne eksempelvis være at hvis du arbejder i finansverdenen, at det er standard i en business case at have et juridisk afsnit, som går i dybden med at tiltagene i business casen overholder de strenge krav til finansvirksomheder.
Men lad os sige du så arbejder for en mindre virksomhed, jamen så kan det være du kan springe denne ekstra sektion over, og du kan nok også slippe af sted med at skrive lidt mere uformelt, da du formodentlig kender styregruppen personligt.
Andre relevante dokumenter
Nogle gange kan business casen stå alene, men ofte er der andre relevante dokumenter som du bør have klar inden projektstart.
Dette kunne eksempelvis være et High-Level Solution Design (HLSD) dokument, der via et flow chart, grafisk viser en visuel repræsentation af projektet. Dette er mest almindeligt i IT-projekter, men kan også laves for strategiske marketing projekter.
Det kunne også være mere udførlige estimater hvis det er et større projekt. Eller et større budget, som er langt mere detaljeret end det som er, inkluderet i business casen.
Det kunne også være mockups på hvordan slutproduktet kunne komme til at se ud, husk dog gerne at gøre det meget klart at det kun er et eksempel, og at det nok kommer til at se anderledes ud.
Det er også tit at man laver en konkurrent analyse i forbindelse med et større strategisk projekt. Det kunne eksempelvis være en BtB virksomhed der lavede en analyse af konkurrenternes webshops, inden man selv springer ud og laver sin egen direct-to-consumer webshop.
Brug din business case
En business case skal selvfølgelig bruges til at give styregruppen en mulighed for at evaluere et projekt inden de beslutter sig for om det er investeringen værd.
Men den kan faktisk bruges til så meget mere. Du skal gerne se din business case som et styringsværktøj for dit projekt. For den kan nemlig hjælpe dig med meget andet end blot at få godkendt projektet.
Den kan derfor bruges, ikke bare før projektet, men faktisk også under og efter projektet.
Før projektet
Før projektstart er business casens primære formål at få interessenter til at købe ind på idéen, og for at få beslutningstagerne til at acceptere idéen.
Dette er selvfølgelig den primære funktion for en business case, men som du vil kunne læse nedenfor, så kan den faktisk også bruges under og efter projektet.
Under projektet
Under projektet kan man bruge business casen til en del.
Den er eksempelvis god til at hjælpe dig med at besvarer folks spørgsmål, og kan bruges som en form for FAQ.
Husk at din business case består af en idébeskrivelse, projektets målsætninger, projektplanen, kravspecifikationen og de økonomiske overvejelser, så den kan næste hjælpe dig til at besvare ethvert spørgsmål undervejs i projektet.
- Hvorfor er projektet færdigt? Kig på business casen!
- Hvor meget koster projektet? Kig på business casen!
- Hvem er med i projektet? Kig på business casen!
- Hvad får vi ud af projektet? Kig på business casen!
- osv…
Den kan også hjælpe dig som projektleder til at holde fokus, da du i business casen har opsat nogle mål for projektet, så kan du bruge den til at minde dig selv om, hvad projektet skal opnå.
Det er tit at man står i en situation, hvor man skal gå ned af to veje, og der kan det som projektleder tit være svært at vælge.
Men hvis du her går tilbage til business casen, og kigger på projektets målsætninger og krav, så står du tit tilbage med, at dit valg allerede er taget for dig, da det ikke altid er begge veje, som understøtter disse to punkter i business casen.
Så business casen hjælpe dig også til at holde fokus på det, som er vigtigt i projektet.
Derfor er det også en god idé, fra tid til anden, lige at læse business casen igennem igen.
Kan en business case ændre sig undervejs i projektet?
Der er forskellige meninger om, hvorvidt en business case må ændre sig undervejs i projektet. Personligt synes jeg ikke, der er noget i vejen for det. Man kan kun lave en business case på baggrund af den viden, man har, og man får uden tvivl mere viden omkring projektet, jo længere ind i det, man kommer. Især hvis du driver agile projekter, så synes jeg ikke, det gør noget, at den ændrer sig undervejs.
En business case kan også bruges af styregruppen til at retfærdiggøre eventuelle øgede omkostninger til projektet. Det er desværre ikke unormalt, at et projekt går over tid eller budget, og en styregruppe skal derfor kunne retfærdiggøre en yderligere investering ind i projektet.
Efter projektet
En business case spiller også en vigtig rolle, efter projektet er afsluttet.
Der bruges den nemlig til at evaluere projektet, om det var en succes eller en fiasko.
Den bruges også til at estimere afkastet af investeringen, og til at sikre, at man har fået det hele med undervejs.
Mange gange gives projektet også videre til en kollega i virksomheden, her kan business casen også hjælpe den person til at forstå projektet.
Det kunne eventuelt være, at en projektleder drev et webshop projekt, men efter projektet er lanceret, så gives ansvaret for platformen og videreudviklingen tilbage til webmasteren.
Her skal han gerne hurtigt kunne få et indblik i projektet, hvad den nye platform kan, og hvilke forventninger der er til den nye platform (projektets målsætninger).
