Slik skriver du en problemformulering for et prosjekt + eksempler
Definisjon: En problemformulering beskriver tydelig gapet mellom nåsituasjonen og det ønskede resultatet i et prosjekt.
Fokus: En god problemformulering holder prosjekter fokuserte, hindrer ukontrollert utvidelse av omfanget og bidrar til bedre beslutninger.
Komponenter: Viktige deler av en problemformulering er problembeskrivelsen, konteksten, konsekvensene og målene.
Sammenligning: Problemformuleringer skiller seg fra prosjektmandater, forretningsplaner, hypoteser og prosjektomfang.
Feil: Unngå kompleksitet, vaghet, for tidlige løsninger, å overse interessenter og å forveksle symptomer med årsaker.
En problemformulering for et prosjekt definerer forskjellen mellom dagens situasjon og det ønskede resultatet, slik at teammedlemmene kan samordne seg før løsninger, budsjetter og tidsplaner tar over. Jeg har sett prosjekter miste flere uker fordi interessenter løste ulike versjoner av det samme problemet, eller styrte språket i retning av en foretrukket løsning.
Denne veiledningen hjelper deg med å skrive en fokusert og evidensbasert problemformulering, unngå vanlige fallgruver, bruke en praktisk mal og se gode eksempler fra virkelige prosjektkontekster.
Hva er en problemformulering for et prosjekt?
En problemformulering er en tydelig og kortfattet beskrivelse av et problem prosjektet ditt skal håndtere. Den identifiserer et spesifikt gap, et smertepunkt eller et udekket behov og forklarer hvorfor det er viktig. Tenk på den som «hvorfor» bak alt prosjektet ditt skal gjøre.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
En god problemformulering samler teamet rundt en felles forståelse av problemet. Den definerer rammene for arbeidet, begrunner ressursene du ber om og gir interessentene en grunn til å bry seg.
En sterk problemformulering har noen viktige kjennetegn:
- Spesifikk: Den identifiserer det nøyaktige problemet, ikke en vag problemkategori.
- Målbar: Den viser til data, måltall eller observerbare resultater der det er mulig.
- Kontekstuell: Den forklarer hvor og når problemet oppstår.
- Løsningsnøytral: Den beskriver problemet uten å foreskrive hvordan det skal løses.
- Interessentbevisst: Den identifiserer hvem som påvirkes, og hvordan.
Hvorfor skrive en problemformulering for et prosjekt?
Her er noen viktige grunner til at du bør skrive en problemformulering for prosjektet ditt:
- Den holder prosjektarbeidet fokusert: En problemformulering fungerer som en rettesnor for hele prosjektet. Når forespørsler kommer inn, kan du vise tilbake til formuleringen og spørre om den bidrar til å løse problemet. Dette hindrer ukontrollert utvidelse av omfanget, skjerper beslutningstakingen og skaper tydelig ansvarlighet. Prosjekter uten en skriftlig problemformulering har større sannsynlighet for å stoppe opp.
- Den rammer inn forskning og innovasjon: Problemformuleringen definerer spørsmålet du undersøker, veileder metodikken din og hjelper deg med å formulere testbare hypoteser. Den forankrer også idémyldring i brukernes problemer i stedet for abstrakte ideer. Jeg har sett team utvikle langt bedre løsninger når de bruker mer tid på å definere problemet først.
- Den bygger tillit hos interessentene: Interessenter vil vite at investeringen deres går til noe reelt. En problemformulering gir dem åpenhet og en felles forståelse. Den gjør godkjenning enklere fordi vurdererne kan se problemet, konsekvensene av det og hvor presserende det er. Den fastsetter også suksesskriterier på forhånd.
Viktige deler av en problemformulering
Alle sterke problemformuleringer dekker disse fire elementene:
Problembeskrivelse
Dette er kjernen i formuleringen din. Beskriv hva som skjer, eller hva som ikke skjer, men burde skje. Vær direkte og spesifikk. «Kundeonboarding tar for lang tid» er en begynnelse, men «Nye bedriftskunder venter i gjennomsnitt 23 dager på å fullføre onboardingen, sammenlignet med en bransjestandard på 10 dager» er mye bedre.
Bakgrunn og kontekst
Forklar hvorfor dette problemet finnes, og hvilke forhold som omgir det. Gi leseren bakgrunnsinformasjonen som trengs for å forstå situasjonen. Ta med historikk, miljøfaktorer eller organisatoriske begrensninger. En forsinkelse i onboardingen kan for eksempel skyldes at prosessen fortsatt er avhengig av manuell dataregistrering på tvers av frakoblede systemer.
Konsekvenser og relevans
Identifiser hvem problemet påvirker, og hva som skjer hvis problemet fortsetter uten tiltak. Kvantifiser konsekvensene når det er mulig.
Tapte inntekter, bortkastede arbeidstimer, synkende kundetilfredshet og oversittede frister er alle målbare konsekvenser. Denne delen besvarer spørsmålet alle interessenter vil stille: «Hvorfor skal vi bry oss om dette akkurat nå?»
Mål eller foreslått retning
Beskriv den ideelle fremtidige situasjonen. Hvordan ser suksess ut når problemet er håndtert? Dette er ikke en fullstendig løsning, men en retningsgivende formulering som forteller leserne hvor du er på vei.
For onboarding-eksempelet kan målet være «redusere den gjennomsnittlige onboardingstiden til 10 dager eller mindre innen seks måneder». Det gir prosjektet et mål uten å fastsette nøyaktig hvordan det skal nås.
Slik skriver du en problemformulering for et prosjekt
Den følgende trinnvise prosessen beskriver hvordan du utarbeider en effektiv problemformulering fra grunnen av.
1. Identifiser og beskriv problemet
Begynn med å observere. Samle inn data, gå gjennom tilbakemeldinger fra kunder, snakk med ansatte i førstelinjen og intervju interessenter. Målet er å beskrive problemet konkret, ikke å gjette seg frem til det fra et møterom. De beste problemformuleringene kommer fra personene som står nærmest problemet.
2. Still de riktige spørsmålene
Når du har identifisert problemet, må du kvalitetssikre det med målrettede spørsmål:
- Hvem påvirkes av dette problemet?
- Hvor og når oppstår det?
- Hva er forskjellen mellom den nåværende tilstanden og den ønskede tilstanden?
- Hvorfor er dette viktig akkurat nå?
Disse spørsmålene tvinger deg til å gå fra en generell klage til en presis beskrivelse. Hvis du ikke kan svare tydelig på dem, trenger du mer informasjon før du skriver noe.
3. Analyser problemet grundig
Bruk teknikker for rotårsaksanalyse for å forstå hva som faktisk driver problemet. 5 hvorfor-metoden fungerer godt her.
Ta utgangspunkt i eksempelet med onboarding fra tidligere. Du begynner med symptomet og fortsetter å spørre hvorfor:
- Hvorfor tar onboarding 23 dager? Fordi kundedata må legges inn i tre separate systemer.
- Hvorfor krever det tre separate systemer? Fordi CRM-systemet, faktureringsplattformen og klargjøringsverktøyet ble kjøpt inn uavhengig av hverandre og aldri integrert.
- Hvorfor ble de aldri integrert? Fordi hver avdeling valgte sitt eget verktøy basert på egne krav.
- Hvorfor valgte avdelingene verktøy uavhengig av hverandre? Fordi det ikke fantes tverrfunksjonelt tilsyn med teknologianskaffelser.
- Hvorfor fantes det ikke tverrfunksjonelt tilsyn? Fordi selskapet vokste raskere enn styringsprosessene.
Ved det femte spørsmålet har du gått fra at «onboarding tar for lang tid» til et strukturelt styringsproblem. Det endrer hvilken type prosjekt du utformer. Problemformuleringen kan nå vise til rotårsaken til problemet, ikke bare symptomet, noe som gjør den langt mer nyttig.
4. Utarbeid formuleringen
Bruk denne malen som utgangspunkt:
[Interessentgruppe] opplever [problem] i [kontekst], noe som fører til [konsekvens]. Dette prosjektet har som mål å [mål].
For eksempel: «Nye bedriftskunder opplever en onboarding-prosess på i gjennomsnitt 23 dager på tvers av tre frakoblede systemer, noe som fører til at 40 % faller fra før full aktivering. Dette prosjektet har som mål å redusere onboarding-tiden til 10 dager eller mindre innen seks måneder.»
Det første utkastet trenger ikke å være perfekt. Fokuser på å fange opp problemet, konteksten, konsekvensen og målet. Fjern deretter alt som ikke fortjener å være med.
5. Gå gjennom og finpuss
Les utkastet høyt. Kontroller at det er tydelig, kortfattet og spesifikt. Fjern all sjargong som personer utenfor teamet ditt ikke ville forstå. Sørg for at formuleringen forblir løsningsnøytral. Hvis det står «vi må implementere X», er det en løsning, ikke et problem. Gå tilbake til selve problemet.
6. Valider med interessentene
Del utkastet med personene som står nærmest problemet, og med personene som skal finansiere eller godkjenne prosjektet. Ta hensyn til tilbakemeldingene deres før du ferdigstiller det.
Dette trinnet høres enkelt ut, men det er her de fleste problemformuleringer enten blir bedre eller faller sammen. Slik håndterer du to vanlige problemer:
- To interessenter er uenige om problemet: Motstå fristelsen til å slå sammen perspektivene til én uklar formulering. Se på uenigheten som et signal om at du trenger mer data. Ofte beskriver begge parter symptomer på et dypere problem som ingen av dem har formulert fullt ut. Gå tilbake til 5 hvorfor-metoden.
- Ledelsen ønsker at formuleringen skal rettferdiggjøre løsningen deres: Det mest effektive grepet jeg har funnet, er å spørre: "Hvilke bevis må foreligge for at denne løsningen skal være riktig?" Formuler problemstillingen rundt disse bevisene. Hvis bevisene finnes, vil formuleringen peke mot løsningen deres. Hvis de ikke finnes, bør dere ta en samtale om antakelsene.
Validering betyr ikke å oppnå støtte og enighet for enhver pris. Det betyr å sørge for at formuleringen er korrekt, ikke bare behagelig.
Eksempler på problemformuleringer for prosjekter
Her er fem eksempler på problemformuleringer fra ulike bransjer. Legg merke til hvordan hver av dem tilpasser dokumentasjonen og innrammingen til standardene innenfor sitt fagområde.
IT og programvareutvikling
Eksempel på problemformulering: Kundestøtteagenter bruker for øyeblikket tre separate verktøy for å løse én enkelt henvendelse, noe som gir en gjennomsnittlig behandlingstid på 14 minutter per forespørsel. Bransjegjennomsnittet er 7 minutter. Dette prosjektet har som mål å redusere behandlingstiden ved å samle arbeidsflytene for kundestøtte på én enkelt plattform.
Dette er typisk for problemformuleringer innen IT. Den bygger på driftsmålinger og sammenligningsdata. Et smidig team kan komprimere dette ytterligere til én setning som mål for en sprint.
Helsevesen og folkehelse
Eksempel på problemformulering: Pasienter i distriktene i regionen med tre fylker reiser i gjennomsnitt 45 miles for å få tilgang til spesialisthelsetjenester, noe som fører til en uteblivelsesprosent på 38 % for oppfølgingsavtaler. Dette prosjektet har som mål å redusere andelen til under 15 % ved å utvide tilgangen til fjernkonsultasjoner.
Problemformuleringer innen helse må oppfylle kravene fra tilsynsmyndigheter og tilskuddskomiteer. Hvis dette var en søknad om tilskudd, ville du lagt til kildehenvisninger til publisert forskning om transportbarrierer og helseresultater.
Utdanning
Eksempel på problemformulering: Studenter som er de første i familien til å ta høyere utdanning, slutter ved universitetet med en andel som er 22 % høyere enn blant medstudentene, oftest i andre semester. Kontakten med studieveiledere for denne gruppen er i gjennomsnitt 0,8 møter per semester, sammenlignet med 2,4 for studenter der foreldre eller foresatte også har høyere utdanning. Dette prosjektet har som mål å lukke dette veiledningsgapet og forbedre gjennomføringen i andre semester.
Problemformuleringer innen utdanningssektoren drar nytte av disaggregerte data. Når du navngir den spesifikke målgruppen og det spesifikke semesteret, blir formuleringen handlingsrettet.
Forretningsdrift og prosessforbedring
Eksempel på problemformulering: Den månedlige prosessen for økonomisk avslutning tar i gjennomsnitt 12 arbeidsdager for regnskapsteamet og bruker over 400 arbeidstimer per syklus. Feil som oppdages under avstemmingen, utgjør 35 % av denne tiden. Dette prosjektet har som mål å redusere avslutningssyklusen til 7 arbeidsdager ved å håndtere de grunnleggende årsakene til feilene.
Lokalsamfunn og ideelle organisasjoner
Eksempel på problemformulering: Husholdninger som mangler matsikkerhet i sentrumskorridoren, har tilgang til bare én dagligvarebutikk innenfor en radius på to miles, og 60 % av innbyggerne mangler transportmuligheter. Besøkene til matutdelinger for nødhjelp har økt med 40 % fra år til år. Dette prosjektet har som mål å utvide matdistribusjonen og redusere reiseavstanden til kilder for fersk mat.
Problemformuleringer i ideelle organisasjoner fungerer ofte også som argumenter for innsamling. Dataene her er valgt for å skape en følelse av at det haster. Et bedriftsinternt driftsteam ville kanskje ikke nevne transport i det hele tatt, men for en finansiør i lokalsamfunnet gjør denne detaljen problemet konkret og investeringen berettiget.
Problemformulering sammenlignet med andre prosjektdokumenter
En problemformulering blir ofte forvekslet med andre prosjektdokumenter. Slik skiller de seg fra hverandre.
| Dokument | Formål | Viktigste forskjell fra problemstillingen |
|---|---|---|
| Problemstilling | Definerer det spesifikke problemet prosjektet skal løse | Fokuserer utelukkende på problemet og konsekvensene av det |
| Prosjektmandat | Godkjenner prosjektet og beskriver omfang, milepæler og budsjett | Bredere dokument; problemstillingen inngår i det |
| Forretningsgrunnlag | Begrunner investeringen ved å sammenligne kostnader og fordeler | Fokuserer på økonomisk og strategisk begrunnelse |
| Hypotese | Foreslår en testbar forklaring eller forutsigelse | Tilbyr et mulig svar; problemstillingen definerer spørsmålet |
| Prosjektomfang | Definerer grensene for arbeidet som skal gjennomføres | Beskriver hva som skal gjøres; problemstillingen beskriver hvorfor |
Problemstilling versus prosjektmandat
Problemstillingen inngår i prosjektmandatet, men mandatet er et bredere dokument. Et prosjektmandat omfatter prosjektets omfang, milepæler, budsjett, viktige interessenter og suksesskriterier.
Problemstillingen gir «hvorfor»-forklaringen som forankrer alle disse andre elementene. Skriv problemstillingen først, og bruk den deretter som grunnlag for prosjektmandatet.
Problemstilling versus forretningsgrunnlag
Et forretningsgrunnlag begrunner investeringen. Det sammenligner kostnader, fordeler, risikoer og alternativer for å fremføre en økonomisk eller strategisk begrunnelse. Problemstillingen definerer smertepunktet som forretningsgrunnlaget bygger på.
Hvis du ikke kan formulere problemet, vil forretningsgrunnlaget ditt mangle et overbevisende fundament. Skriv problemstillingen før du utarbeider forretningsgrunnlaget.
Problemstilling versus hypotese
En hypotese foreslår et testbart svar på et spørsmål. En problemstilling definerer selve spørsmålet. I forskningsprosjekter skriver du problemstillingen først, og utleder deretter én eller flere hypoteser fra den.
De to fungerer sammen, men har ulike formål. Hvis du blander dem sammen, kan problemstillingen trekke konklusjoner før undersøkelsen i det hele tatt har begynt.
Problemstilling versus prosjektomfang
Prosjektomfanget definerer grensene for arbeidet teamet ditt skal levere. Det svarer på «hva gjør vi, og hva gjør vi ikke?». Problemstillingen svarer på «hvorfor er dette arbeidet viktig?». Omfang uten en problemstilling kan virke tilfeldig.
En problemstilling uten omfang kan virke uavgrenset. Du trenger begge deler, og problemstillingen bør komme først.
Vanlige feil du bør unngå når du skriver problemstillinger
Her er noen vanlige fallgruver du bør unngå når du utarbeider problemstillingen:
- Å gjøre formuleringen unødvendig komplisert: Motstå fristelsen til å presse alle relaterte problemer inn i én enkelt formulering. Hvis problemstillingen trenger en ordliste, er den for kompleks. Hold deg til ett spesifikt problem. Bruk et språk alle kan forstå ved første gjennomlesning.
- Å være for vag eller bred: «Kundene våre er misfornøyde» gir ingen nok informasjon til å kunne handle. En nyttig problemstilling spesifiserer hvem som er berørt, hva problemet er, hvor og når det oppstår, og hvordan avstanden mellom dagens og ønskede situasjon ser ut.
- Å foreslå mulige løsninger for tidlig: Ofte sniker ikke løsningen seg inn ved et uhell. Noen med beslutningsmyndighet har allerede bestemt hva de vil bygge eller kjøpe, og formuleringen blir konstruert i etterkant for å rettferdiggjøre det.
- Å overse konsekvensene for interessentene: En problemstilling som ikke nevner hvem som er berørt, virker abstrakt. Identifiser alltid personene eller gruppene som opplever problemet, og beskriv konsekvensene for dem.
- Å hoppe over validering: Det er risikabelt å skrive en problemstilling alene. Personene som står nærmest problemet, vil oppdage ting du overser. De som godkjenner prosjektet, ønsker å se sitt perspektiv gjenspeilet. Del utkastet tidlig, få tilbakemeldinger og revider.
- Å forveksle symptomer med årsaker: Symptomer er det du legger merke til først. Grunnårsakene driver dem. «Personalutskiftingen er høy» er et symptom. «Nyansatte får ikke strukturert opplæring, noe som fører til manglende engasjement innen 90 dager» ligger nærmere grunnårsaken. Hvis problemstillingen bare nevner symptomer, vil du sannsynligvis håndtere feil problem.
Hva skjer nå?
De sterkeste prosjektene starter med tydelig tenkning, praktiske verktøy og velprøvde rammeverk. Registrer deg for en gratis DPM-medlemskonto og få tilgang til maler, ressurser og ekspertinnsikt som hjelper deg med å lede prosjekter med trygghet.
