Kan du definere effektmål og resultatmål i ditt prosjekt? Eller vet du forskjellen på et epos og en brukerhistorie?

Opp gjennom årene er jeg ofte blitt spurt om hva en funksjonell arkitekt (også kalt «funkis») gjør og hvorfor rollen er viktig i IT-prosjekter.

I denne blogposten vil jeg derfor gi en innføring i de viktigste prinsippene og begrepene til en funkishverdag. Jeg har også tatt med et fiktivt eksempel for å tydeliggjøre begrepene bedre!

Eksempelet tar utgangspunktet i et scenario der en virksomhet skal utvikle en ny IT-løsning. Vi kan se for oss at virksomheten sitter på et saksbehandlingssystem som er kodet i et gammelt og utdøende utviklingsspråk og at forretningsprosessene er papirbaserte. Å gjennomføre endringer på saksbehandlingssystemet er tidkrevende og kostbare.

Funksjonell arkitektur i de tidlige fasene av et utviklingsprosjekt

I konsept- og planleggingsfasen av et utviklingsprosjekt, er det viktig å forstå det forretningsmessige utgangspunktet. Jeg begynner derfor alltid med å tilegne meg en forståelse av dagens situasjon.

Ut ifra forståelsen, som dokumenteres i prosa form, er det mulig å formulere behovene, som konsist beskriver hvilke behov det er som utløser planlegging av et utviklingsprosjekt til et bestemt tidspunkt.

Prosjektutløsende behov skal legitimere at virksomheter etablerer prosjekt. I scenarioet kan de prosjektutløsende behovene eksempelvis være;

• (1) behovet for å kunne oppfylle lovpålagte oppgaver, planlagte endringer eller politiske føringer eller,
• (2) behovet for å frigjøre tid eller effektivisere forretningsprosessene.

Det første eksempelet ville være særlig aktuelt dersom virksomheten i eksempelet er en offentlig etat som ble hindret i å oppfylle lovpålagte oppgaver og særlig iverksettingen av endringer i forskrifter og lovverk som følge av at saksbehandlingssystemet er utdatert og tungvint å endre.Det andre eksempelet er mer aktuelt for offentlige og private virksomheter som ønsker å effektivisere sine forretningsprosesser. Å gjennomføre endringer på saksbehandlingssystemet er tidkrevende og kostbare.

Avdekke faktiske behov og ønsker

Tidlig i utviklingsprosjekt gjennomføres det interessentanalyser, der særlig prosjektlederrollen er opptatt av å identifisere hvilke aktører som påvirker prosjektet og i hvilken grad ulike aktører blir påvirket av realiseringen av prosjektets produkter. Den funksjonelle arkitekten er i tillegg opptatt av å identifisere de faktiske behov og ønsker interessentene har.

Behovene som avdekkes i tidlige faser av et utviklingsprosjekt, er av overordnet karakter og blir gjerne dokumentert som prosjektets produkter i prosjektforslag, prosjektbeskrivelser og business case.

Funksjonelle arkitekter er også viktige sparringspartnere i planleggingen av tidspunktene for når de ulike produktene skal leveres under prosjektperioden. Samtidig med analyse av behov og interessenter gjennomfører funksjonelle arkitekter, i samarbeid med tekniske arkitekter, en analyse av omfanget (scope) til utviklingsprosjektet.

Dokumentasjon av omfanget belyser hva som blir direkte og indirekte berørt av prosjektet, og hva som blir avgrenset til å ligge utenfor omfanget av prosjektet.

I vårt eksempel vil saksbehandlingssystemet være direkte berørt, mens registre eller systemer som dette saksbehandlingssystemet samhandler med, kan bli indirekte berørt og virksomhetens administrative verktøy som for eksempel Office-pakke og HR-system blir avgrenset ut av prosjektets omfang.

Formulere målsettinger og kalkulere gevinster

Interessentene, behovene og omfang vil være i bevegelse gjennom hele prosjektet, men analysene og dokumentasjonen gir grunnlaget for de videre aktivitetene med å beskrive ønsket situasjon, formulere målsettinger og kalkulere gevinster.

En funksjonell beskrivelse av ønsket situasjon er, på lik linje med beskrivelsen av dagens situasjon, en prosaisk beskrivelse, som beskriver fremtidig tilstand og målbilder, som man med gjennomføringen av utviklingsprosjektet ønsker å realisere.

Målsettingene til et utviklingsprosjekt er ofte formulert som et målhierarki, som består av et overordnet mål eller samfunnsmål, effektmål og resultatmål. Det overordnede målet eller samfunnsmålet og effektmålene, bør bygge på prosjektutløsende behov for å sikre konsistens og gi føring for en bestemt retning for styringen av prosjektet.

Målene angir prosjektets tiltenkte virkning og er et uttrykk for ambisjonsnivå. Forankring av effektmålene, den direkte effekten en får av prosjektet, og resultatmålene, den konkrete leveransen som skal oppnås ved ferdigstillelse av prosjektet, gir prosjektet retningssans og er sentrale kriterier for prioriteringer av behov og krav når prosjektet går inn i gjennomføringsfasene.

Eksempler på effektmål; «En mer effektiv saksbehandlingsprosess» og eller «En mer brukerorientert virksomhet», mens eksempler på resultatmål kan være; «Ny applikasjon for saksbehandling» og «ny applikasjon for innlevering av søknad».

Som funksjonell arkitekt har jeg vært svært delaktig i formulering og forankring av målsettinger og ønsket situasjon. Dette er aktiviteter som er særlig verdifullt for å gi utviklingsprosjektet retningssans og kriterier for senere prioritering av behov og krav, og det er grunnlaget for å kalkulere gevinster.

Gevinstene kan være kvantifisert i økonomiske og tidsmessige størrelser eller være ikke-prisgitte. Forankring av gevinstene legger grunnlaget for at aktørene i virksomheten eller hos interessentene kan ta eierskap til gevinstene og realisere dem når prosjektet er ferdigstilt.

Prosjektets omfang, produkter, målsettinger og gevinster er sammen med blant annet grovestimater og prosjektorganisering sentrale leveranser i konsept- og planleggingsfasen og gir beslutningstakere grunnlag for å ta beslutning om å ta prosjektet videre til gjennomføringsfasene.

Spesifisering av behov og krav

I gjennomføringsfasene til utviklingsprosjekt handler funksjonell arkitektur i stor grad om å spesifisere behov og krav. Spesifisering betyr i denne forstand å detaljere og dokumentere behovene og kravene i en form som er tilgjengelig for analyse, kommunikasjon og til slutt implementasjon.

Den funksjonelle arkitekten tar utgangspunkt i de målbildene eller overordnede behovene som utgjør prosjektets produkter. Her jobber den funksjonelle arkitekten tett på de viktigste interessentene for å få opp en overordnet produktkø (backlog) på eposnivå.

Epos

Et epos er en beskrivelse av en større mengde funksjonalitet som er knyttet til et overordnet forretningsbehov.

Eksempler på epos kan være; «mottak av søknader i saksbehandlingsløsningen», «arbeidsflate for å behandle søknader» og «Innsending av søknader».

Eposet består altså av en avgrenset menge funksjonalitet som gir forretningsverdi og relateres til prosjektets målsettinger og planlagte gevinster. Samtidig blir det også knyttet grove estimater til eposene. Dette gir grunnlag for at man kan etablere en overordnet produktkø og gjennomføre kost-/nyttevurderinger og prioritere eposene som utgjør elementene i produktkøen.

Det neste steget i spesifiseringen av behovene, er å bryte eposene ned til brukerhistorier som plasseres inn i et utviklingsløp.

Brukerhistorier

En brukerhistorie er en kort beskrivelse av behovet til brukeren, der det etableres hvem som har behovet, hva behovet er og hvorfor behovet er tilstede.

Eksempelet tar utgangspunktet i et scenario der en virksomhet skal utvikle en ny IT-løsning. Eksempler på brukerhistorier; «Som bruker ønsker jeg levere inn min søknad digitalt slik at jeg kan få behandlet min søknad raskt» og «Som saksbehandler ønsker jeg å se alle relevante opplysninger i saken slik at jeg kan behandle søknaden korrekt».

Brukerhistoriene gir forretningsmessig verdi med knytning til gevinster og målsettinger, samt estimeres. Dette gir grunnlag for en produktkø som kan prioriteres og omprioriteres i løpet av prosjektets gjennomføringsfase.

I løpet av et utviklingsprosjekt vil behovene endre seg og nye behov vil dukke opp, ettersom prosjektet lærer og får tilbakemeldinger. Dette innebærer at produktkøen er ferskvare og må kontinuerlig prioriteres.

Håndtering av endringer og løpende gjennomføring av kost/nytteanalyser et sentralt ansvarsområde til funksjonelle arkitekter i gjennomføringsfasene til utviklingsprosjekt.

Akseptansekriterier

Brukerhistoriene detaljeres ytterligere ned i akseptansekriterier, som benyttes for å beskrive kriteriene for at en brukerhistorie skal godkjennes som levert. Alle kriteriene skal være innfridd for at brukerhistorien er ansett som å være levert.

Akseptansekriteriene beskriver eksempelvis funksjonalitet som forretningsregler og kvalitetskrav som er relevante. Videre anvendes akseptansekriterier som utgangspunkt for test og testkriterier.

Akseptansekriterier kan være; «Gitt at brukeren logger vellykket inn på søknadsportalen så skal den laste opp søknadssiden på 1 sekund (systemytelse)» og «Gitt at saksbehandler har logget inn på saksbehandlingsløsningen og skal starte behandlingen av søknad så skal løsningen vise korrekt navn, adresse og kontaktinfo til søkeren (funksjonelt krav)».

Funksjonelle og ikke-funksjonelle krav

Kravene beskriver enten noe IT-systemet må gjøre (funksjonelt krav) eller en kvalitet IT-system må ha (ikke-funksjonelt krav). Ikke-funksjonelle krav blir også benevnt som kvalitetskrav eller produktkvalitet.

Kvalitetskravene kan stille krav til om systemet dekker de funksjonelle behovene (funksjonell egnethet), om det utfører prosesser effektivt (systemytelse), om det kan samvirke med andre system, rammeverk eller løsninger (kompabilitet), i hvilken grad brukerne effektivt og med best mulig tilfredshet kan bruke systemet (brukskvalitet), om systemet anses som pålitelig (pålitelighet), om systemet beskytter seg selv og sine brukere mot uønskede hendelser (sikkerhet), om systemet er enkelt å forvalte, endre og ta inn ny funksjonalitet (forvaltbarhet) og om data produsert av systemet lar seg forvalte over tid (informasjonsforvaltning).

Bindeleddet mellom forretning og IT

Den funksjonelle arkitektens strukturering av behov og krav medfører at det er mulig å spore brukerhistorier og akseptansekriteriene til prosjektets målsettinger og gevinster. Dette er et viktig verktøy for å prioritere og sikre at prosjektet til enhver tid jobber med de oppgavene som gir mest verdi. Samtidig står funksjonelle roller med ett ben i både forretning og IT. Det er en unik posisjon for å gjøre avklaringer og forankringer som forener de to domene mot et felles mål.

Samlet sett bidrar dermed den funksjonelle arkitekturen til retningssans og fremdrift i prosjektene.

Høres dette ut som noe dere kunne trenge hjelp eller bistand med der du jobber? Eller ønsker du å utvikle deg innen funksjonell arkitektur! Bare ta kontakt med meg, så tar vi en prat.