Statens reviderede it projektmodel

For tre måneder siden gennemførte Digitaliseringsstyrelsen en omfattende revidering af den statslige it-projektmodel. Nu er de første erfaringer med modellen tilgængelige.

Indholdsmæssigt er der sket en forenkling af flere dokumentskabeloner. Anskaffelses -og gennemførelsesfasen er slået sammen, hvilket bl.a. giver bedre mulighed for at gennemføre agile projekter. Det har betydet, at de statslige myndigheder nu har mere frihed til at tilrettelægge egne it-projekter.

Mange myndigheder har oplevet, at den mest omfattende ændring har været, at risikovurderingen af et projekt er blevet fremrykket, hvilket har betydet, at risikovurderingen allerede er tilstede i starten af analysefasen.

Der skal være styr på styregruppen

Der skal hurtigt indgås en styregruppeaftale, der detaljeret beskriver styregruppens arbejdsmetoder; en aftale der forpligter styregruppens medlemmer med navn og underskrift.

Den nye model medvirker til, at gevinster og risici bliver omdrejningspunktet for planlægning og gennemførelsen af projekter. Grundtanken er, at fremfor at fokusere på detaljespecificering, så skal der være styr på mål og midler førend projektet påbegyndes.

Projektets analysefase er central. Det er nu et krav, at risikovurderingen finder sted senest tre måneder inde i projektets analysefase. Grundlæggende har det den betydning, at det er en anderledes og ny disciplin for de statslige myndigheder at udarbejde de styringsdokumenter, der skal fremsendes til risikovurdering.

Styringsdokumenterne skal indeholde følgende:

1. Et projektgrundlag, der erstatter den tidligere PID og som overordnet beskriver formål, gevinster, risici, løsning, levering og planen for analysefasen.
2. En styregruppeaftale der begrunder sammensætningen af styregruppen og dokumenterer det individuelle kommittent hos styregruppemedlemmerne.

Forandringen indebærer, at fremfor at nørkle med projektet i halve og hele år, førend alt er afstemt og kontrolleret internt, så skal de statslige myndigheder nu væsentlig tidligere i projektforløbet dele deres tanker og ambitioner med it-projektrådet.

Tid er en faktor i statens reviderede it-projektmodel

Mulighederne for rådgivning fra it-rådet er et vigtigt udgangspunkt. På under tre måneder skal myndigheden beskrive formål, gevinster, risici, løsning, levering og en plan for analysefasen. Den plan skal blandt andet beskrive, hvordan der gennemføres en grundig og detaljeret analyse af eksempelvis projektets gevinster eller løsning. For at udforme den plan og levere en effektiv analyseindsats, er det nødvendigt, at projektet relativt tidligt i processen har kendskab til de ”ømme punkter”, så det i selve planen bliver præciseret, hvordan projektet vil håndtere de ”ømme punkter”.

I de fleste tilfælde er fremgangsmåden og metoderne velkendte, men det kan være svært at komme i gang, især hvis organisationen ikke er klar til det.

De overordnede erfaringer fra de første måneder med den reviderede statslige it-projektmodel:

1. De tre måneder før risikovurdering går hurtigt – planlæg processen og kom godt fra start.
2. Klæd styregruppen på, så medlemmerne forstår ”gamet” og deres ansvar i forbindelse med at gennemføre processen. Bring styregruppeaftalen tidligt på banen, da det kan tage længere tid end forventet at få den udfyldt og underskrevet.
3. Frygt ikke omgivelserne, men træk på rådgivning fra it-rådet og tag dialog med interessenter.
4. Håndter nulfejlskulturen og skab en åbenhed om, at et projekt kan ændre sig i analysefasen. Først beskrives projektet på et overordnet grundlag til Statens it-råd, og derefter gennemføres en mere grundig og detaljeret analyse.
5. Brug velkendte og afprøvede projektmetoder, afhold gevinst-workshops, risiko-workshops, produktnedbrydninger, anvend estimeringsmetoder og træk på erfaringer.
6. Engager interne eller eksterne fagkompetencer tidligt. Gode forretningsanalytikere, it-arkitekter m.v. kan hurtigt bidrage til at forstå opgaven, bidrage med estimater og planlægge analysefasen.
7. Kill your darlings: Vær’ åben overfor forskellige løsningsmuligheder og kritisk overfor ”faste antagelser”. Overoptimistiske forventninger til løsninger der ikke er gangbare eller til priser, der ikke er realistiske, vender altid tilbage og bliver et problem for projektet.