Redigerer Problembeskrivelse (avsnitt)

== Definering av problemet ==
Før problembeskrivelsen kan formuleres må problemet være definert. Det ligger i den menneskelige natur å begynne å arbeide med å løse problemet så fort som mulig og neglisjere å definere det virkelige problemet som må løses. Imidlertid vil et dårlig definert problem øke risikoen for å implementere en løsning som ikke gir de forventede resultatene. Et problem kan ikke løses dersom det ikke er helt forstått.<ref name="shaffer-ba">{{Kilde www|url=https://www.batimes.com/articles/cooking-up-business-analysis-success.html|tittel=Cooking Up Business Analysis Success|besøksdato=2018-04-10|fornavn=David|etternavn=Shaffer}}</ref>

Prosessen med å definere et problem er ofte en gruppeinnsats. Den starter med et møte med interessentene, kundene og/eller brukerne som påvirkes av problemet (hvis mulig) og for å lære om hvilke problemer de opplever (på engelsk ofte kalt ''pain points'').<ref name=":7">{{Kilde avis|url=https://www.forbes.com/sites/forbesagencycouncil/2018/04/02/take-these-steps-to-define-your-uiux-problem-and-avoid-haphazard-changes/#22f21cda7c6c|tittel=Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes|etternavn=Widen|fornavn=Steven|dato=2018-04-02|avis=Forbes|besøksdato=2018-04-10|språk=en}}</ref> Ettersom folk ofte sliter med å effektivt kommunisere sine utfordringer, særlig overfor noen som kommer fra utenfra prosessen, er det hjelpsomt å stille en rekke spørsmål om "hvorfor" inntil den underliggende årsaken er identifisert. "[[5-hvorfor|De fem hvorfor]]" er en slik metode (på engelsk kjent som ''five whys'', ikke til å forveksles med ''five Ws''), som kan være et verktøy for å komme til roten av det underliggende problemet siden mange erfarte frustrasjoner snarere kan være [[Symptom|symptomer]] på det faktiske problemet.<ref name="shaffer-pm" /> Ved å spørre disse tilleggsspørsmålene samt [[Parafrasering|parafrasere]] (omarbeide) hva interessenten har sagt demonstrerer man en grad av empati og forståelse av problemet.<ref name=":4" />

Informasjonen samlet fra disse inngående intervjuene er bare en del av problemanalysen. Ofte strekker problemet seg over flere områder eller funksjoner som interessentene, kundene eller brukerne ikke kjenner til. De kan også være kjent med hva som skjer på overflaten, men ikke nødvendigvis den underliggende årsaken. Derfor er det vel så essensielt å samle kunnskap, informasjon og innsikt fra prosjektmedlemmer og [[Fagekspert|fageksperter]] om problemet.<ref name=":7" /> Det kan også være nødvendig å se gjennom ytterligere forskningsmateriale, arbeidsinstruksjoner, brukermanualer, produktspesifikasjoner, arbeidsflytdiagrammer og tidligere prosjektplaner. Som for de fleste andre steg i [[Prosessforbedring|prosessforbedrings]]-prosjekter er det å definere problemet ofte interaktivt ettersom flere runder med diskusjon trengs for å få oversikt.

Når problemet har blitt forstått og omstendighetene som driver prosjekt-initieringen er tydelige er det tid for å skrive ned problembeskrivelsen.