prosjektblogg

Bestod eksamen med glans

av Harald Aas

Utdanningsdirektoratet (Udir) bruke prosedyren konkurransepreget dialog i anskaffelsen av et system for utvikling og gjennomføring av prøver og eksamen. Måten de gjorde det på kan gå rett inn i lærerboken, og i dette intervjuet med seniorrådgiver Øyvind Barkald Aas i avdeling for prøve- og eksamenstjenesten deler han sine erfaringer med oss.

Et innsatsteam fra programmet har bistått Udir i konkurranseforberedelsene med råd om prosedyre, IKT og markedskommunikasjonen i forkant av utlysningen. – Det som gjør at vi trekker frem denne anskaffelsen er måten Utdanningsdirektoratet har jobbet med å fange opp behov hos sluttbruker, måten behovene er beskrevet på i konkurransegrunnlaget, og ikke minst hvor gjennomgående disse behovene er brukt i gjennomføringen for å sikre et godt resultat, sier Harald Aas som sammen med Johan Englund og Mari Vestre fra Difi utgjorde innsatsteamet.

Hvorfor valgte dere å bruke prosedyren konkurransepreget dialog i anskaffelsen av en digital eksamensløsning?

– Da vi i Utdanningsdirektoratet skulle anskaffe nytt system for utvikling og gjennomføring av eksamen og prøver var det tidlig klart at vi ikke skulle utvikle det selv fra grunn av, slik vi tidligere har gjort. Det finnes en rekke IT-leverandører som allerede har slike løsninger som de selger til kunder som likner på oss, og som ivaretar de aller fleste behovene vi har.

Vi ønsket å kjøpe inn en standardløsning, men med tilpasninger etter våre behov.  I forprosjektfasen var vi innom Digitaliseringsrådet. Der fikk vi blant annet råd om å ta kontakt med Leverandørutviklingsprogrammet. Det gjorde vi, og Harald Aas i Leverandørutviklingsprogrammet satt oss på sporet av konkurransepreget dialog. Med denne anskaffelsesprosedyren falt mange brikker på plass. Vi kunne snakke med leverandører og se nærmere på hva som finnes i markedet.

I forkant av vårt prosjekt hadde vi flere ganger forsøkt å skrive gode og relevante krav, men det ble aldri gode krav som leverandørene kan levere på. Det ble en blanding av for detaljerte eller urealistiske krav og en beskrivelse av dagens systemer. Nå kunne vi ta utgangspunktet i behovene våre og skrive kravspesifikasjonen sammen med leverandørene.

Øyvind Barkald Aas er seniorrådgiver i Utdanningsdirektoratet i avdeling for prøve- og eksamenstjenesten

Hvilket råd vil du gi til offentlige innkjøpere som bruker denne prosedyren for første gang?

– Hvis du skal kjøpe noe som er stort eller komplekst og der du ikke klarer å skrive en god kravspesifikasjon, så er konkurransepreget dialog en god prosedyre. Riktignok hvis du gjør det på en god måte. Her har vi noen erfaringer som kan være til nytte for andre. Beregn nok tid til å få jobbet gjennom dialogfasen, vær åpen og betal tilbyderne for deltakelse i dialogen.

1. Å beregne god nok tid til å gjennomføre dialogen er viktig. Vi la opp til flere uker mellom hver runde med dialogmøter. Dette ga oss tid til å være skikkelig forberedt til møtene, noe som gjorde at vi fikk mye utbytte av dem. Mellom møtene fikk vi også jobbet godt med kravspesifikasjonen. Da dialogfasen var over, var kravspesifikasjonen nesten helt ferdig.

2. I hele vår dialogfase spilte vi med åpne kort. Alt arbeidet med behov og krav foregikk i en nettområde der leverandørene hadde tilgang. Til enhver tid kunne de gå inn og se hva vi hadde gjort og hvordan krav m.m. var formulert, og gi oss tilbakemeldinger som løftet kravene våre videre. Leverandørene ga oss tilbakemelding på at det var med å på å skape en veldig åpen og god dialog.

3. Belønne leverandørenes deltakelse. Å delta i en konkurransepreget dialog er tid- og arbeidskrevende for leverandørene. De gjør en jobb ved å delta i dialogfasen og bidrar med erfaring og kompetanse inn i utforming av kravspesifikasjon.

Hvordan fanget dere opp sluttbrukernes ønsker og krav, og hvordan gikk dere frem for å sammenstille det til konkurransegrunnlaget?

–  «Den vet hvor skoen trykker som har den på» er en sigelse som i denne sammenheng er veldig sant. Det er sluttbrukerne som kjenner til sine oppgaver og hva de skal gjøre i systemet. Det må man ikke ta lett på. Man må bruke mye tid på å spørre dem om hvilke oppgaver de skal løse og hva de skal oppnå. Vi lot ikke sluttbrukerne definere hvordan systemet burde være eller å beskrive løsningen. Det er veldig lett å la dem gjøre det. I slike prosesser er det viktig å ha med noen som har kompetanse på tjenestedesign, der man er ekspert i å finne ut hva brukeren skal gjøre og så designe prosesser rundt dette. Vi endte opp med 30 overordnede behov til systemet. Siden de var overordnede kunne vi betrygge brukerne med at de også favnet det meste av detaljer. Dette kunne vi bruke i det arbeidet der vi presenterte vårt forslag til behov for de interne brukerne våre i forkant av at vi lyste ut invitasjon til dialog. Ingen kunne være uenig i behovene, selv om de ikke spesifikt beskrev alle behov.

«Det er sluttbrukerne som kjenner til sine oppgaver og hva de skal gjøre i systemet.»

–  Senere, etter at dialogfasen var i gang, begynte vi arbeidet med å lage kravspesifikasjonen. Vi diskuterte hvordan vi skulle være overordnet og samtidig beholde brukerperspektivet. Etter flere ulike forsøk endte vi med å utforme kravene som brukerhistorier. På denne måten blir det klart hvem som skal gjøre hva og hva de skal oppnå med å gjøre det. Vi utformet alle brukerhistoriene etter stegene i vår arbeidsprosess. Som en detaljering av brukerhistoriene var å beskrive hvordan dette var relevant for behovene våre. En brukerhistorie kan da være som oppgaveutvikler skal jeg skrive oppgaver slik at jeg kan lage en eksamen elevene kan gjennomføre. Dette er relevant for behovet for universell utforming, brukervennlighet osv. 0.2, 0.5, 0.9.

Bildetekst: Før konkurranseutlysningen snakket Udir med ulike brukere som elever, lærere og sensorer om hvilke oppgaver de har. Dette ble samlet i 30 overordnede behov (F. eks B05). I dialogfasen skrev Udir brukerhistorier (f.eks. F13 – Student sit examination). På denne måten kunne tilbyderen enkelt sette seg inn i brukernes situasjon for å forstå hvorfor et behov er viktig, hvilken oppgaver behovet knytter seg til, og hvilke brukere behovet berører. Se hele dokumentet i dokumentsamlingen til venstre; System Requirements

 

Bildetekst: Brukerhistorie F13 – Student sit examination finner vi igjen i oversikt over krav i konkurransegrunnlaget i dokumentet Tender specification. Ut av dokumentet kan vi da lese at kravet ikke er obligatorisk, men at det er av høy viktighet (H), og at løsningen knyttet til denne spesifikke oppgaven skal klar for akseptansetest innen 15.auguts 2020. Legg også merke til at bare 4 av totalt 42 systemkrav er obligatoriske. Det gir et større innovasjonsrom for nye løsninger.

Er behovskartlegging noe man som innkjøper kan gjøre selv eller bør man få hjelp fra profesjonelle feltarbeidere? Hva må man passe på dersom man intervjuer brukere?

– Det er ikke en umulig oppgave å gjennomføre. Men det krever både erfaring, kompetanse og tid. Når man har samlet inn brukerinnsikt og kategorisert det noen ganger, vet man litt om hvordan man kan gå fram. Man blir god på å stille spørsmålene på en slik måte at man får vite hva brukerne egentlig har behov for å gjøre. De første gangene blir det ofte alt åpne spørsmål og en diskusjon om hvordan systemet skal se ut. De første gangene man gjør dette, kan det være lurt å ha med noen som er gode. Det kan for eksempel være noen i organisasjonen eller å leie inn ekstern kompetanse. Men kanskje like viktig som kompetanse, er tid. Det tar mye tid, både å få snakket med mange nok sluttbrukere.

Vi takker Øyvind Barkald Aas for at han delte sin innsikt med oss, og du kan lese mer om anskaffelsen og se alle dokumentene i konkurransegrunnlaget her.