Et digitalt prosjekt i offentlig sektor ligner på et privat prosjekt helt til du kommer til kravene. Så viser det seg at flere av dem ikke er noe man kan prioritere ned, og at de påvirker både arkitektur og tidsplan fra første dag.
Det er ikke nødvendigvis vanskeligere. Men rekkefølgen på beslutningene er en annen, og de som oppdager kravene sent, betaler mest.
Kravene som ikke er valgfrie
Universell utforming er det mest absolutte. Forskrift om universell utforming av IKT krever WCAG 2.1 på nivå AA, Digitaliseringsdirektoratet fører tilsyn, og offentlige virksomheter må i tillegg publisere en tilgjengelighetserklæring som redegjør for hvor løsningen oppfyller kravene og hvor den ikke gjør det.
Det avgjørende her er tidspunktet. Kontrastkrav, tastaturnavigasjon og skikkelig semantikk er nesten gratis å ta hensyn til når designet lages, og dyrt å rette i en ferdig løsning. Vi har skrevet mer om hva kravene betyr konkret i skap en inkluderende nettside.
Personvern er det andre. Offentlige virksomheter behandler ofte sensitive opplysninger, og da kreves en vurdering av personvernkonsekvenser før behandlingen starter. Det betyr at spørsmålene om hvilke data som samles inn, hvor de lagres og hvem som har tilgang, må besvares i planleggingen framfor ved lansering.
Arkivplikten er den som oftest overrasker. Offentlige organer har dokumentasjonsplikt, og hvis løsningen produserer noe som er saksdokumenter, må det kunne bevares og gjenfinnes. Dette er ikke noe man bygger på i ettertid uten videre, og det er verdt å avklare tidlig om løsningen faller innenfor.
Anskaffelsen styrer mer enn folk tror
Over terskelverdiene må oppdraget ut på anbud, og måten konkurransen utformes på får stor betydning for resultatet.
Den vanligste fellen er å spesifisere løsningen framfor behovet. En kravspesifikasjon med tre hundre punkter låser leverandøren til noe som ble tenkt ut før noen hadde snakket med brukerne. Da får dere akkurat det dere ba om, også når det viser seg å være feil.
Det som fungerer bedre er å beskrive hva som skal oppnås og for hvem, og la leverandørene foreslå hvordan. Det gir dere også mulighet til å vurdere hvem som faktisk har forstått problemet.
Tenk også gjennom hvordan kontrakten håndterer endring. Et prosjekt der alt er låst i forkant, har ingen mekanisme for å ta inn det dere lærer underveis, og dere kommer til å lære noe underveis.
Integrasjoner mot fellesløsninger
Skal tjenesten identifisere brukere, er ID-porten som regel svaret. Skal den utveksle data med andre offentlige virksomheter, finnes det etablerte fellesløsninger for det.
Disse er gode når de er på plass, men tilgang tar tid. Det skal søkes, avtales og testes i egne miljøer før produksjonssetting. Ledetiden er ikke noe leverandøren kontrollerer, og den har veltet flere tidsplaner enn teknisk kompleksitet har.
Rådet er enkelt: start søknadsprosessene i måned én. De går ikke raskere av at koden er ferdig.
Fallgruvene vi ser oftest
Den største er at det bygges på antakelser om hvordan folk jobber. Beslutningen tas på nivået over dem som skal bruke løsningen, basert på hvordan prosessen er ment å fungere. Så viser det seg at saksbehandlerne har utviklet en annen praksis fordi den offisielle ikke henger sammen i virkeligheten.
Den nest største er omfang. Offentlige prosjekter har en tendens til å vokse, fordi mange parter har legitime behov og det er vanskelig å si nei. Resultatet er lange løp der ingenting kommer i drift før alt er ferdig, og der forutsetningene har rukket å endre seg underveis.
Den tredje er manglende forankring. En løsning som innføres uten at de som skal bruke den har vært involvert, møter motstand uansett hvor god den er. Involvering tidlig er billigere enn opplæring sent.
Og den fjerde er at ingen eier løsningen etter lansering. Prosjektorganisasjonen oppløses, budsjettet er brukt, og så er det ingen som har ansvar for videreutvikling. Da forfaller løsningen gradvis til noen foreslår å erstatte den.
Det som kjennetegner prosjektene som går bra
De begynner smått. Én tjeneste, én brukergruppe, i drift tidlig. Det gir noe konkret å vurdere før mer penger bindes opp, og det gir organisasjonen en erfaring å bygge videre på.
De har med seg noen som faktisk skal bruke løsningen, hele veien. Ikke som referansegruppe som møtes kvartalsvis, men som folk som tester og sier fra.
De har avklart kravene til universell utforming, personvern og arkiv før utviklingen starter, slik at de blir en del av løsningen framfor et etterarbeid.
Og de har satt av midler til forvaltning, ikke bare til utvikling. En digital tjeneste er en løpende forpliktelse på samme måte som et bygg.
Før dere går ut i markedet
Beskriv hvilken oppgave som skal løses og for hvem, og hva den koster i tid eller kvalitet i dag. Avklar hvilke fellesløsninger dere trenger tilgang til, og sett søknadene i gang. Ta stilling til arkivplikten. Og utpek noen som kan ta beslutninger underveis.
Har dere det på plass, blir både anskaffelsen og prosjektet vesentlig enklere.
Vil du diskutere et prosjekt eller få en vurdering av kravene? Se hvordan vi jobber med apputvikling og webapplikasjoner, eller ta kontakt.