Hopp til hovedinnhold

Rammer, arkitektur og anskaffelser

Prosjekter må styres innenfor gjeldende rammer, føringer og behov for helhet. Arkitektur og anskaffelser bør vurderes tidlig, slik at prosjektet velger løsninger som passer inn i virksomheten, følger relevante krav og kan forvaltes over tid.

Opprettet: 22. juni 2026 Sist endret: 25. juni 2026

Rammebetingelser

Prosjekter i offentlig sektor må forholde seg til lover, regelverk, nasjonale føringer og krav til samordning. Dette påvirker både hvordan prosjektene planlegges og hvordan de gjennomføres. 

Lover og regelverk kan stille krav til personvern, informasjonssikkerhet, arkivering, universell utforming, offentlige anskaffelser, forvaltningsrett og sikkerhet. Slike krav bør vurderes tidlig, slik at de blir en del av prosjektets planlegging, styringsdokumentasjon og beslutningsgrunnlag. Involver det juridiske fagmiljøet tidlig, slik at de får en helhetlig forståelse av prosjektet og kan bidra med å se potensielle juridiske utfordringer fra start.  

Nasjonale føringer og strategier er særlig viktige i digitaliseringsprosjekter. Prosjekter bør støtte felles mål for offentlig sektor og bruke relevante standarder, fellesløsninger og retningslinjer der det er aktuelt. Dette gir bedre samordning og legger til rette for gjenbruk, deling og helhetlige tjenester.

Virksomhetsarkitektur 

Virksomhetsarkitektur bidrar til at prosjektets løsninger henger sammen med virksomhetens mål, prosesser, informasjon, systemer og teknologiske føringer. Arkitekturarbeidet bør starte tidlig, slik at prosjektet ikke utvikler løsninger som skaper unødvendig kompleksitet eller bryter med helheten. 

Virksomhetsarkitektur kan også være en kilde til nye prosjektforslag. Målbilder og handlingsplaner kan vise gap mellom dagens situasjon og ønsket fremtidig situasjon. Prosjekter og produktutvikling kan være virkemidler for å lukke slike gap.

Prosjektet bør avklare og identifisere hvilke arkitekturprinsipper, målbilder, fellesløsninger, datakilder og integrasjoner som påvirker prosjektet. Når prosjektet gjør teknologiske eller organisatoriske valg, bør konsekvensene for helhetlig arkitektur og videre forvaltning vurderes. Virksomhetsarkitekt og løsningsarkitekt bør involveres tidlig der prosjektet berører prosesser, informasjon, systemer eller teknologiske valg. Det gir bedre beslutningsgrunnlag og reduserer risikoen for fragmenterte løsninger.

Løsningsarkitekturen må ses i sammenheng med virksomhetsarkitekturen, men kan også avdekke behov for å justere virksomhetsarkitekturen. Når nye arbeidsprosesser eller løsninger settes i produksjon, bør relevant arkitekturdokumentasjon oppdateres.

Anskaffelser

Mange prosjekter er avhengige av leverandører. Når prosjektet skal anskaffe varer eller tjenester, må anskaffelsen planlegges tidlig og ses i sammenheng med prosjektets mål, risiko, styringsmodell og leveranseform. Ved behov for anskaffelser bør prosjektet beskrive behov før de beskriver løsning. Gode behovsbeskrivelser gir bedre konkurransegrunnlag og større handlingsrom for leverandørene. Valg av anskaffelsesstrategi, prosedyre og kontraktsform bør støtte prosjektets behov for styring, samarbeid, fleksibilitet og kontroll.

Dersom prosjektet kan innebære en anskaffelse, bør dette vurderes allerede i konseptfasen. Prosjektet bør undersøke markedet, hente erfaringer fra andre virksomheter og involvere fremtidige brukere og dem som skal ta ansvar for nytte og forvaltning etter prosjektet.

Behovet bør beskrives før løsningen i en kravspesifikasjon. For detaljert kravspesifikasjon kan låse løsningen for tidlig og redusere handlingsrommet for leverandørene. Valg av anskaffelsesprosedyre og kontraktsform bør derfor støtte behovet for dialog, læring, samarbeid og kontroll.

I prosjekter med leverandører er kontrakten også et styringsverktøy. Kontrakten bør støtte prosjektets mål, leveranseform og behov for samarbeid, kvalitet, fremdrift, risikooppfølging og endringshåndtering. Den bør brukes aktivt gjennom prosjektet.

Prosjektet bør planlegge hvordan leveransen skal testes, aksepteres, settes i drift, vedlikeholdes og følges opp etter overlevering. Den første perioden etter innføring kan kreve ekstra støtte til brukerne og tett oppfølging av feil, endringer og videreutvikling.