Mange prosjekter som kjører behovsanalyse ender opp med en liste av problemområder og ønsker om forbedringer formulert som en antatt løsning.  Forretningsmålene som skal oppnås er ofte ikke synlige, og hvis de er synliggjort er de sjelden formulert slik at de er målbare, eller innbyrdes prioritert.  Mål (hva som skal oppnås) blir blandet sammen med virkemidler (hva som kan gjøres for å oppnå et mål).   Et prosjekt har begrenset med tid og ressurser, og må prioritere. En slik behovskartlegging fungerer dårlig som rettesnor for prioritering av videre kravspesifisering og løsningsdesign.  Min påstand er at prosjekter uten kvantifiserte og prioriterte mål og et klart skille mellom mål og virkemidler står i fare for å adressere feil problem og utvikle uhensiktsmessige og dyre løsninger, i verste fall feile fullstendig.

Hva er et forretningsbehov?

Forretningens behov er noe man trenger for å kunne iverksette tiltak/utføre oppgaver med sikte på å oppfylle forretningens mål eller redusere en risiko.  Behovene er der uansett, men de kan være mer eller mindre tilfredsstilt med dagens prosesser og systemer.   Der hvor man ser at behovene er for dårlig tilfredsstilt (dvs. dagens løsninger hindrer forretningens mulighet til å oppfylle sine mål, eller utgjør en risiko), setter man seg forbedringsmål. Et forbedringsmål skal være på forretningsnivå, ikke en løsning, det skal være målbart langs en definert skala og det er ikke gitt at det må løses ved å innføre datastøtte.  Når målet er nådd har forretningen oppnådd en ønsket verdi.  Dermed er en behovsanalyse på forretningsnivå en prosess som først går ut på å identifisere hvilke virkemidler man kan benytte for å nå forbedringsmålene.  Virkemidler på forretnings/organisasjonsnivå kan være å endre en prosess ved å fjerne unødvendige trinn, legge om flyten mellom aktører eller rekkefølgen på trinnene, eller å effektivisere enkelttrinn. Det kan også være å fjerne hele prosesser eller innføre helt nye prosesser.

Det er ikke mulig å prioritere virkemidlene på forretningsnivå uten først å ha prioritert og kvantifisert forbedringsmålene.  Hva er det vi skal oppnå og i hvilken grad?  Har prosjektet en liste av de prioriterte, kvantifiserte forbedringsmålene?  Hvis ikke er det disse vi må skaffe til veie først, før vi går i gang med å prioritere virkemidler (e.g. hvilke trinn som skal effektiviseres i hvilke forretningsprosesser, om noen). Dette burde være prosjekteiers/oppdragsgivers fremste anliggende. Hvis du som funksjonell arkitekt kommer inn i et prosjekt der dette mangler eller er utilfredsstillende utført er det din plikt å ansvarliggjøre prosjektets ledelse og eiere for å sørge for at målene er klare og at det er mulig å vite om vi har nådd dem.

Når de overliggende målene og virkemidlene er prioriterte, vil man som regel se at en del forbedringsønsker ikke faller inn under prosjektets definerte ansvarsområde og raskt kan legges til side.

La oss ta et eksempel

Et prosjekt har definert behovet «Elektronisk løsning for søknad om X» for å oppnå et mål formulert som  «Effektivisert saksbehandling ved søknadsmottak og enklere kommunikasjon med kunde»

For det første er «Elektronisk løsning for søknad om X»  ikke beskrivelsen av et behov, men en generell løsning.  Hva er behovet?  «Effektivisert saksbehandling ved søknadsmottak» og «Enklere kommunikasjon med kunde» høres ut som to greie forbedringsmål.  Men effektivisert og forbedret i forhold til hva?  Hva skal nivået på effektiviseringen og forenklingen være for at målet er nådd?  Vi trenger å kvantifisere målene.  Eksempelvis kunne vi sagt:

Mål: Saksbehandlingstiden for en søknad om X skal være maksimalt 24 timer regnet fra søknaden mottas i organisasjonen til saksbehandler har sendt ut et svar til søker.

For å kartlegge om det er behov for forbedring spør vi oss så: er dette tilfredsstillende oppfylt i dag eller er det noe som hindrer oss i å nå dette målet?  Hva hindrer oss? F.eks. saksbehandler oppfatter ikke at hun har mottatt saken, det tar for lang tid fra saken er mottatt i postmottaket til den er tilgjengelig for saksbehandler, etc.  Nå har vi avdekket et par reelle behov:

  1. Søknader om X må tilgjengeliggjøres for saksbehandler straks de er mottatt av organisasjonen
  2. Saksbehandler må kunne oppfatte at hun har mottatt en ny sak så snart den er tilgjengelig for saksbehandling

Merk  at vi ikke sier noe om hvordan, bare om hva og hvor godt.  Vi har avdekket funksjonelle behov og kvalitetsbehov.   Så snart vi har prioritert å løse dem, blir de til til krav.

Hvis vi løser disse behovene, er de hvert sitt bidrag på veien mot målet om en saksbehandlingstid på maks 24t.  Hvordan vi løser dem handler om å komme opp med kreative forslag til ulike løsningsdesign.  For å åpne mulighetsrommet er det viktig at formuleringen av behovet ikke peker mot en spesifikk løsning. Det er først i løsningsdesignet vi kommer inn på ting som elektronisk innleverte søknader, saksbehandlingsløsninger med arbeidslister, eller for den saks skyld bedre postsorteringsrutiner i postmottaket.  Også løsningsdesign må prioriteres mhp. grad av måloppnåelse (= nytte) og ikke minst: kostnad.  Ett og samme løsningsdesign kan gi ulike bidrag til oppnåelsen av flere mål, dette må analyseres på tvers.

Prioriter på alle nivå og adskill mål fra virkemidler

Mitt poeng er at prioritering må skje på alle nivå, begynne med mål, fortsette med virkemidler på forretningsnivå, og til slutt ende opp med en prioritering mellom ulike løsningsdesign. Man kan ikke utføre en kost/nytte analyse på et behov, et behov har ikke en kostnad, det er ulike løsningsdesign som har kostnad.  Hvis du kan kost/nytte analysere et behov har du sannsynligvis ikke beskrevet et behov, men en løsning.

I kravanalysemetodikken Volere, prioriterer vi på Forretningsbrukstilfellenivå (hvilke forretningsprosesser er det viktigst å forbedre, hvor mye, i hvilken dimensjon/retning), deretter kan man prioritere hvilke trinn i forretningsprosessene/forretningsbrukstilfellene det er mest hensiktsmessig å gjøre noe med, beskrive disse som systembrukstilfeller eller brukerhistorier med kvalitetskrav (i.e. ikke-funksjonelle krav) og komme opp med ulike løsningsdesign, og prioritere mellom disse ut fra estimert kostnad.

Ta et sjekk av ditt prosjekt:

  1. Har prosjektet kvantifiserte og prioriterte mål?
  2. Er målene ledsaget av prioriterte virkemidler (forretningsstrategi)?
  3. Er behovene/kravene slik de er beskrevet faktisk behov, og ikke antatte løsninger?  Vær kritisk til de formuleringene som brukes og bruk tid på å få dette riktig.

Det oppdragsgiver vil ha er høy verdi for forretningen til lavest mulig kostnad.  Kvantifiserte mål adskilt fra virkemidler, og behov adskilt fra løsninger gjør det mulig å levere dette.  Ikke start prosjektet uten!

2 thoughts on “Hvordan sikrer du at prosjektet leverer løsninger av verdi?

  1. Howdy! This article couldn’t be written any better! Looking at this article reminds
    me of my previous roommate! He always kept preaching about this.
    I most certainly will send this information to him. Pretty sure he’ll have
    a good read. Thanks for sharing! http://bing.net

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *