Det har blitt mer og mer vanlig med caseoppgaver både i undervisningssammenheng og i arbeidslivet. Å jobbe med case er svært utfordrende, fordi det ikke er noen fasitsvar. Jeg husker selv hvor vanskelig jeg syntes det var da jeg som førstekullist på NHH jobbet med min første caseoppgave i bachelorkurset SOL1 Psykologi og ledelse. Den første caseoppgaven jeg skrev var ikke spesielt imponerende. Det var flere ting jeg fant utfordrende, men spesielt vanskelig var det å utforme problemstillingen, velge passende teorigrunnlag, og sist men ikke minst hvordan drøfte. Det tok tid før jeg knakk «casekoden». Den som hjalp meg med dette var Daniel Flokenes, studentassistenten jeg hadde i SOL1. De som har fulgt bloggen min vet kanskje allerede hvem Daniel er. Han har lang erfaring som studentassistent på NHH, både i SOL1 Psykologi og Ledelse og SOL3 Organisasjonsteori, som begge er casebaserte fag. Daniel har også omfattende erfaring med case utover studentassistentjobben, blant annet ved å ha representert NHH i Global Business Case Competition i Seattle. Siden Daniel hjalp meg med å knekke casekoden, tenkte jeg at flere kan ha nytte av å høre hans råd til hvordan skrive case.

I dette innlegget vil derfor Daniel skrive sine beste råd og tips for å lykkes i casearbeidet.

Daniel og jeg har for øvrig også skrevet et innlegg i to deler hvor vi diskuterer hvordan man kan forberede seg til casebasert eksamen, hvordan velge problemstilling og teori, og hvordan drøfte og skrive akademisk. Del 1 kan leses her, mens del 2 kan leses her.

---

Noe av det kuleste som det gikk an å være i antikkens Hellas var en dude med langt skjegg som brukte hele dagen på å tenke. Noen var så god på å gro langt skjegg og sitte med grubleriene sine, at vi husker dem selv den dag i dag, godt over to tusen år senere. To slike skjeggete tenkere var Platon og Aristoteles.

Platon var kjempeopptatt av det universelle. Han mente at det måtte finnes en perfekt løsning hvor alt hadde sin rettmessige plass. Slik tenkte han også om menneskelig atferd – han så for seg en idealstat hvor hver rolle var fylt av den personen som hadde de beste iboende egenskapene for jobben. Et slags deterministisk teknokrati.

Aristoteles var eleven til Platon, men kjøpte aldri helt sin læremesters higen etter denne perfekte, universelle løsningen. Han mente tvert i mot at noe slikt var praktisk umulig å løse teoretisk og at menneskelig atferd måtte forstås gjennom det partikulære. Det er fra denne tradisjonen casestudier har oppstått.

Et case er nettopp et studie av det partikulære. Vi bruker casestudier for å forstå spesifikke situasjoner for spesifikke mennesker eller organisasjoner. Et eksempel innenfor økonomifaget er Lego-konsernets omveltning på starten og midten av 2000-tallet, hvor leketøysprodusenten gikk fra konkursens rand til å i dag være verdens største. Ved å studere hva som skjedde de årene Lego sto på kanten av stupet kan en få innsikter i endringsledelse, innovasjon, effektiv organisering og mye annet. Et case slik som Legos omveltning er også mye mer illustrerende og levende (det er jo ekte!) enn hva en ren teoretisk avhandling kan være.

Det var en kort introduksjon til hvor case kommer fra og hvorfor vi har dem. I studiehverdagen er det imidlertid langt mer interessant å vite hvordan en kan løse case. I resten av dette innlegget skal jeg forsøke å beskrive hvordan en kan tilnærme seg det på et overordnet nivå og gi mine tips for å lykkes. Jeg vil spesielt vektlegge hva som er viktig når en skriver case i NHH-fagene SOL1 Psykologi og Ledelse og SOL3 Organisasjonsteori, men hva jeg skriver vil i stor grad være overførbart til ethvert fag innenfor strategi, ledelse, økonomi og styring.

Valg av case

Ethvert case starter med en situasjon og en problemstilling. Eller, hva er caset og hvorfor skal vi bry oss. I enkelte tilfeller vil situasjonen være gitt (i SOL1 får alle studentene presentert samme case), mens i andre tilfeller kan en selv velge situasjonen (semesteroppgaven i SOL3). Når en kan velge case fritt har jeg ett enkelt råd: Velg noe som virker interessant. Det er så enkelt, og så vanskelig.

Det sagt er det fremdeles enkelte ting en kan se etter når en velger en situasjon. For det første, se etter situasjoner hvor det finnes en eller annen form for konflikt, motsetning eller gnisning. Det trenger ikke være en stor historisk endring eller krise, men det bør være noe med situasjonen som gjør at en kan si «på den ene siden… på den andre siden». Det kan være alt fra at en bedrift har en stor mulighet til å vokse internasjonalt, til at den mest erfarne ingeniøren avdelingen var avhengig skal pensjonere seg om et år. Og igjen, se etter noe som virker interessant. Jeg tror det er nesten umulig å trå feil om det er kriteriet!

Problemstilling

Problemstillingen er imidlertid vanskeligere. Veldig mange uerfarne studenter trår feil når de lager sin første problemstilling. Og veldig mange erfarne studenter (meg selv inkludert) synes fremdeles det er meget krevende. Heldigvis finnes det enkelte «best practises» en kan tenke på når en utformer problemstillingen. Det første er rett og slett å spørre seg hvilket spørsmål en har. En problemstilling bør være reflekterende og utfordre situasjonen på et eller annet vis. Da trenger en også et reflekterende spørreord. Hvorfor er bra, og hvordan eller i hvilken grad er med i den reflekterende gjengen også. Hva, hvem, hvor, når og ja/nei-formuleringer, derimot, bør henvises til skammekroken.

Det er imidlertid også viktig at problemstillingen er knyttet til situasjonen på en interessant måte. For å oppnå det gjelder det å være spesifikk og unik. Med spesifikk mener jeg at en må avgrense hva en ser på. Om en har en begrensning på ord eller sidetall er det i praksis umulig å lage en interessant casebesvarelse som ser på «alt». Om jeg skulle skrevet om Lego-caset jeg nevnte innledningsvis kunne jeg sett enten på endringsledelse eller effektiv organisering, men jeg kunne ikke gjort begge på 4000 ord eller 15 sider. Med unikt mener jeg at problemstillingen bør berøre noe som er annerledes med situasjonen eller organisasjonen eller begge. Noe unikt med Lego ville være hvorfor de sto på konkursens rand til tross for mange tiår med lønnsom internasjonal ekspansjon, eller at de hadde fått sin første CEO som ikke het Kirk Christiansen til etternavn og hvordan skulle de holde på identiteten uten en fra familien ved roret.

Basert på prinsippene beskrevet over kan vi finne eksempler både på hvordan en god og en dårlig problemstilling ser ut. En dårlig problemstilling kan være følgende:

Hva skjedde da Jørgen Vig Knudstorp tok over som CEO for Lego Gruppen?

Siden spørreordet er hva legges det kun opp til beskrivelse. Formuleringen er også veldig generell. Det eneste avgrensende er byttet av CEO, som i seg selv ikke trenger å være særlig interessant. Det skjer jo stadig vekk at selskaper bytter CEO. Et bedre alternativ kunne derfor vært følgende:

Hvorfor lykkes Lego Gruppen med å snu det dramatiske underskuddet i 2004 og igjen oppnå lønnsom vekst i kjernevirksomheten?

Dette er bedre av flere grunner. For det første åpner hvorfor-formuleringen for refleksjon og å se på bakenforliggende årsaker. Det er nå også et mer unikt fokus, gjennom den reelle krisesituasjonen akkurat Lego sto ovenfor i 2004. Til sist kommer det frem en klar konflikt mellom at bedriften befant seg i en krisesituasjon, og at de oppnådde lønnsom vekst i kjernevirksomheten (som en forøvrig må huske å definere!). Noe må åpenbart ha endret seg dramatisk!

En annen ting som er verd å bemerke med problemstillingen er at den er utgangspunktet for hele oppgaven. Når en har bestemt seg for problemstillingen bør en holde seg helt og holdent til å besvare den. All teori og empiri som ikke er relevant for problemstillingen kan legges til siden. Alle argumenter som ikke hjelper å besvare og finne en løsning på problemstillingen er irrelevante og bør kuttes bort. Problemstillingen er og skal være den røde tråden. Det er historien som fortelles i casebesvarelsen.

Det sagt bør en være forsiktig med å låse seg for tidlig. Om en oppdager at det er en rekke kjempeinteressante argumenter og sammenhenger som ikke passer til problemstillingen kan det være like kurant å endre nettopp problemstillingen, som å droppe de interessante argumentene. En casebesvarelse vil ikke ha et fasitsvar, men vil være levende og utvikle seg i takt med innsikten til de som skriver den. Det må den få lov til! Når en har kommet godt i gang og føler seg sikker på problemstillingen bør en selvsagt holde seg til den for å jobbe effektivt, men en bør ikke låse seg for tidlig. Da er det nemlig lett å gå i den fellen at en gjør for snevert research og ender opp med å velge feil teorigrunnlag eller gå glipp av viktige sammenhenger.

Teorivalg

Etter at en har valgt problemstilling må en også bygge et fundament for å besvare problemstillingen. Det er her teorigrunnlag kommer inn. Når en skriver case i en akademisk setting, slik som i SOL1 og SOL3, eller i de fleste andre fag med caseløsning på NHH eller andre utdanningsinstitusjoner, er det viktig at en viser at en forstår teorien i faget og evner å anvende teorien. I et rent business-case, slik en kan møte i casekonkurranser eller på jobbintervjuer, er et teoretisk fundament også viktig. Forskjellen er at en da gjerne ikke viser det så eksplisitt som i den akademiske settingen.

I fag som SOL1 er det imidlertid viktig at en er eksplisitt om teorivalgene sine. En bør tenke grundig over hvilke teorier som er spesielt godt egnet til å belyse problemstillingen og også fortelle leseren (når en skriver) om begrunnelsen en finner. Denne begrunnelsen bør være spesifikk og konkret. For eksempel anvende teamet mitt i faget Global Strategy and Management rammeverket Liability of Foreignness for å belyse eBays forsøk på å etablere seg i Kina fordi det er et rammeverk som beskriver utfordringene et selskap møter når det skal etablere seg i et annet land, og spesifikt inkluderer utfordringer knyttet til lokal konkurranse, som var viktig grunnet aggressiv respons fra det kinesiske selskapet Alibaba. Dersom en kan knytte teorivalget til helt konkrete aspekter ved problemstillingen, spesielt om det er noe unikt ved situasjonen, er en god indikator på at en har gjort en grundig og riktig jobb i å bygge et fundament for å besvare problemstillingen.

Med problemstillingen og det teoretiske fundamentet på plass har en gjort de viktigste store valgene for å besvare et case. Da kan en slappe av, sant? Ehh, nei. Dessverre gjenstår det vanskeligste. Nemlig å faktisk løse caset! Før en knekker i gang er det tre ting som er viktig å forstå. For det første, hvordan en strukturerer en case og får argumenter til å henge sammen. For det andre, forskjellen mellom redegjørelse og drøfting. For det tredje, forskjellen mellom passiv og aktiv drøfting.

Struktur og argumentasjon

La oss først se på struktur. På et helt overordnet nivå handler dette om hvilke seksjoner besvarelsen deles inn i og i hvilke rekkefølge disse kommer. I fag som SOL1 og SOL3 er det klare føringer på dette: innledning, deretter kontekst, teori, drøfting, oppsummering. Jeg kommer kort tilbake avslutningsvis på noen tips til hver enkelt del. Det utfordrende med strukturen er imidlertid ikke å få riktige seksjoner på riktig plass, men å skape en helhetlig, sammenhengende historie. Det er to ting som kreves for å få det til. For det første må en selv ha en tydelig historie i hodet. Det andre er at en faktisk må kommunisere denne historien gjennom hva jeg pleier å kalle «bindetekst». Det er setninger og fraser som forteller leseren hva som skjer nå og hva som skal skje videre i teksten, og hvordan det hele henger sammen.

Struktur er viktig i presentasjoner også. Dette er et utdrag fra en forelesning Daniel har holdt på NHH om hvordan en kan lage gode presentasjoner.

En vanlig feil mange gjør er at de har mange ideer, vurderinger og påstander. Mye av dette er gjerne skikkelig smart tenkt, så naturlig nok vil en vise leseren alt en har tenkt. Det som skjer da er at en bruker veldig mye plass på å legge frem en rekke påstander slik at en ikke har plass til at hver enkelt får «puste», og en ikke bruker plass i teksten på å knytte disse sammen og forklare hvilke rolle de spiller i den overordnede strukturen. Da blir argumentasjonen vanskelig å følge, og besvarelsen ironisk nok mindre overbevisende enn om en hadde færre argumenter.

Basert på utfordringen over er det lurt å begrense hvor mange argumenter en faktisk legger frem, men gjøre en ekstra grundig jobb med hvordan en strukturerer disse argumentene og knytter dem opp mot. Det er flere modeller for hvordan en kan gjøre dette, men personlig støtter jeg meg i hovedsak på to tilnærminger. Disse kan forkortes som FFU og TUR.

FFU står for Forbered, Fokuser og Utdyp. Poenget her er at en starter et argument ved å forberede leseren på hva som skal skje og gjerne hvordan det henger sammen med den overordnede historien. Deretter fokuserer eller spisser en argumentet inn mot et avgrenset område, slik at leseren vet nøyaktig hva som er viktig akkurat nå. Først når leseren har blitt forberedt og fokusert begynner en å utdype og gå mer i detalj, fordi en da kan forvente at leseren henger med på hvorfor disse detaljene er relevant og hvordan de passer inn.

TUR står for Tema, Utdypning og Relevans. Her starter en ved å presentere det overordnede temaet, slik at leseren vet hvilke område en befinner seg i, for eksempel ved å komme med en påstand. Neste steg er så å utdype dette temaet slik at leseren får en forståelse for hva det handler om. Det innebærer gjerne å komme med underbyggende «bevis» om en startet med en påstand. Til sist er relevans, hvor en tydelig knytter temaet opp mot problemstillingen og viser hvorfor argumentet er viktig.

Å strukturere måten en skriver på gjennom teknikker som FFU og TUR gjør det enklere for leseren å henge med i argumentasjonen. En må imidlertid også vite når en skal benytte disse teknikkene til å presentere informasjon, og når en skal komme med egne påstander og vurderinger; når en skal drøfte eller redegjøre.

Redegjørelse og drøfting

Neste ting som er viktig å forstå er altså forskjellen mellom redegjørelse og drøfting. I en casebesvarelse i SOL1 eller SOL3 må en kunne gjøre begge deler. Å redegjøre betyr å beskrive eller presentere noe. Når en redegjør skal en ikke vurdere innholdet – om det er bra, dårlig, anerkjent, relevant – eller blande inn sine egne meninger. Poenget her er at en har forstått hva en legger frem og evner å få frem viktig informasjon til leseren. I konteksten og teoridelen (med unntak av begrunnelse for teorivalg) skal en kun redegjøre.

Drøfting, derimot, innebærer å utvikle synspunkter og drive frem nye poenger eller innsikter gjennom argumentasjon. Drøftingen i en case skal ta utgangspunkt i informasjonen som er redegjort for tidligere, men kan nå inneholde egne synspunkter og vurderinger. En kan komme med påstander, men disse må være rimelige og ha et fundament i informasjonen som er presentert, og brukes til å bygge argumenter som besvarer problemstillingen.

Til sist er det forskjellen mellom passiv og aktiv drøfting. Her er poenget at en ønsker mest mulig aktiv drøfting, men det er vanskelig å oppnå. Passiv drøfting er beskrivende heller enn reflekterende, mens aktiv er omvendt. En måte å forstå hva dette innebærer er at passiv drøfting svarer på hva, hvor, hvem, når, ja eller nei. Aktiv drøfting svarer på hvordan og spesielt hvorfor. Ofte er det slik at en passiv drøfting vil være at en legger frem en påstand og beskriver den, og så går videre til neste påstand. Ved aktiv drøfting vil en derimot legge frem påstanden og så «bevise» denne gjennom eksempelvis å vise hvorfor den samsvarer med teori eller empiri, for så å gi en vurdering (i form av argumenter, ikke god/dårlig) på hvorfor denne påstanden er relevant. En kan også tenke på det gjennom TUR-modellen. Passiv drøfting er Tu, hvor hovedvekten ligger i å presentere temaet og kanskje utdype litt, men rent beskrivende. Aktiv drøfting er tUR, hvor temaet kun setter scenen og fokuset ligger på å utdype, underbygge og knytte sammenhenger.

Nå har vi sett på hvordan en kan lage en god problemstilling, viktigheten av teorivalg, struktur og hvordan en skal gå frem for å argumentere og drøfte på en god måte. Til sist vil jeg gi noen korte tips om hva jeg ser etter i hver enkelt del – innledning, kontekst, teori, drøfting og oppsummering – av en casebesvarelse.

Innledning

Det viktige med innledningen er å «sette scenen» eller pitche casebesvarelsen. Innledningen er førsteinntrykket, så den bør være skrevet for å fange leserens interesse. Da gjelder det å starte med å få frem noe unikt og spennende ved situasjonen som bygger opp til problemstillingen. Deretter bør en selvsagt legge frem hva problemstillingen er, slik at leseren vet hva besvarelsen faktisk handler om. Til sist er det alltid smart å forberede leseren kort på hva som kommer videre.

Kontekst

Kontekstet er en kortfattet, nøktern og presis situasjonsbeskrivelse. Hensikten er å gi leseren nok informasjon til å forstå grunnlaget for drøftingen som kommer senere. Det betyr at en bør få frem aspektene ved caseorganisasjonen og eventuelt dens omgivelser som er relevant for besvarelsen, men ikke bruke tid på annet. Det er sjeldent viktig å skrive utdypende om organisasjonens historie, og aldri relevant å bruke plass på egne vurderinger.

Teori

Teoridelen har to viktige formål, hvorav de fleste klarer det første og få tenker på det andre, i alle fall de første gangene de skriver case. Det første formålet er enkelt og greit å redegjøre for teorigrunnlaget til drøftingen. Akkurat som med konteksten betyr det en kortfattet og presis gjennomgang uten egne vurderinger. En skal vise at en har forstått teorien og si nok til at leseren har en viss forståelse også, men ikke mer. Teoridelen skal være gjensidig eksklusiv med drøftingen, som betyr at kun den teorien som faktisk anvendes blir presentert, og ingen teori som ikke er presentert blir anvendet.

Det andre, og vanskeligere formålet, er å vise innsikt gjennom valg og sammenhenger. Det første innebærer å få frem begrunnelsen for teorivalget (og her er det selvsagt naturlig med egne vurderinger). Det andre innebærer å få frem hvordan forskjellige teorier eller aspekter ved teorier henger sammen, samt vise begrensninger ved dem. Det betyr eksempelvis å redegjøre for sammenhengen mellom ledelse og ekstrarolleatferd hvis det er et sentralt tema i casebesvarelsen, og å beskrive relevant kritikk av teorien.

Drøfting

Nøkkelen til en god drøfting ligger i stor grad ved å jobbe for en oversiktlig struktur og mest mulig aktiv drøfting. Et viktig poeng er imidlertid å holde seg strengt til problemstillingen. En bør tilstrebe at hvert avsnitt har ett – og kun ett – sentralt poeng, og at dette poenget tydelig bidrar til å besvare problemstillingen. En bør også sørge for at det er en klar overordnet sammenheng mellom argumentene. Selv om hvert avsnitt har hvert sitt spisse poeng, bør de bygge på hverandre slik at det andre avsnittet naturlig følger etter det første. Rekkefølgen på argumentene bør altså være forsterkende, heller enn at en kan bytte om på avsnitt uten at det har noe å si.

Som nevnt skal drøfting og teoridel være gjensidig eksklusiv. Det sagt er det lov å komme med eksempler og empiri som ikke er nevnt i kontekst og teoridel for å underbygge argumenter. Gode eksempler er ofte en veldig effektiv måte å utdype eller vise relevans!

Oppsummering

En god oppsummering gjør nøyaktig hva som står i tittelen. Den sier kortfattet hva som er blitt gjennomgått og får dermed tydelig frem hovedfunnene. Det bør være mulig å lese innledningen og så hoppe rett til oppsummeringen, og på den måten få besvart problemstillingen. Det er også viktig å huske at det aldri skal komme ny informasjon i oppsummeringen.

I en casebesvarelse er det gjerne også forventet at en skal komme med tiltak for å forbedre situasjonen. I SOL1 blir dette spurt om eksplisitt og presisert at de skal plasseres i oppsummeringen. Da er det imidlertid viktig å bemerke at de ikke kan dukke opp fra ingensteds. Drøftingen bør tydeliggjøre hvorfor tiltak er nødvendig og hvilke type tiltak som er hensiktsmessig. Når de da kommer i oppsummeringen bør dermed leseren tenke «ja, akkurat, det gir mening» heller enn «men hvor kommer dette fra». En bør også tilstrebe at tiltakene er så konkret og realistisk gjennomførbare som mulig. Da viser en både at en forstår hvordan teorien faktisk kan anvendes i praksis og situasjonen organisasjonen er i.

To eksempler på dårlige tiltak vil være:
– Bedriften bør bytte lederstil fra oppgavebasert- til relasjonsbasert ledelse.
– For å skape bedre samarbeid i teamet bør teambonusordningen avvikles og erstattes med individuell bonus basert på leveransemål.

Det første tiltaket er dårlig fordi det er så generelt, slik at det er umulig for en leder å vite hva som faktisk bør gjøres når hun kommer på jobb i morgen. Det andre tiltaket er dårlig fordi det virker å misforstå situasjonen og teorien, og dermed virker mot sin hensikt.

Bedre tiltak vil kunne være:

– Lederen bør stoppe å skrive oppgaveinstrukser og heller kommunisere hensikten med oppgaven, slik at hver enkelt medarbeider får anledning til å gjøre hensiktsmessige tilpasninger i utførelsen.
– For å skape bedre samarbeidet i teamet bør bonusordningen justeres slik at utbetaling er basert både på leveranse og på graden av informasjonsdeling.

Dette er ikke nødvendigvis perfekte tiltak, men de lykkes langt bedre både i å være konkrete og henge sammen med situasjonen og teorien.

Da jeg startet å skrive var tanken å gi noen korte, enkle tips, men jeg eier dessverre (heldigvis?) ikke måtehold. Så det ble litt mer enn noen korte, enkle tips. Det siste jeg kan si er derfor kanskje at i motsetning til hvordan jeg ender opp med å skrive og skrive, er det ikke dumt å holde seg kortfattet og presis.

---

Tusen takk til Daniel for å ha delt såpass omfattende om hvordan man kan lykkes i casearbeid! Jeg håper dette kan være nyttig, spesielt for studentene i SOL1, som akkurat har fått utdelt sitt case nummer to. Rådene vil imidlertid være relevant for alle oppgaver og eksamener som er casebasert.

Jeg trodde jeg hadde god kontroll på casearbeid, men nå lærte jeg også masse nytt som jeg vil få bruk for i resten av studietiden min.

Hvis dere trenger litt inspirasjon i casearbeidet kan dere se på caseoppgaven som jeg skrev da jeg hadde SOL1. Den ligger tilgjengelig her: SOL1 Caseoppgave. Det var denne besvarelsen jeg vant casekonkurransen med, og Daniel regner det blant de beste SOL1-casene han har lest.