ITB-arbejdsgruppe vedrørende statslige IT-nyudviklingsprojekter. Indhold

ITB-arbejdsgruppe vedrørende statslige IT-nyudviklingsprojekter. Indhold 1. Udgangspunktet for IT-Brancheforeningens nedsættelse af arbejdsgruppen...4 1.1 Aktuelle IT-projekter...4 1.2 Bonneruprapporten...4 2. Årsager til de fortsatte forsinkelser og budgetoverskridelser...7 2.1 Udbudsformen...7 2.2 Kontrakterne...8 2.3 Kontraktsadministrationsformen...9 2.4 Konsulenternes rolle...10 4.1 Eksempler på opsplitning af projekter...12 4.2 Fordele ved den trinvise fremgangsmåde...16 4.3 Mulige ulemper ved den trinvise fremgangsmåde...17 4.4. Udformning af kravspecifikationer...17 5. Hvordan imødekommes kravet om budgetsikkerhed?...18 6. Hvordan imødekommes kravet om konkurrenceudsættelse?...20 7. Andre anbefalinger...21 7.1 Tænk på leverandørens omkostninger...21 7.2 Gør ikke udbudssystemet mere byrdefuldt, end det i forvejen er....21 7.3 Undgå bredt formulerede krav....22

Forord. IT-Brancheforeningen besluttede i foråret 2009 at nedsætte en arbejdsgruppe med det formål at vurdere årsagerne til de problemer, som de store, statslige IT-udviklingsprojekter har oplevet, samt at komme med anbefalinger til imødegåelse af problemerne. Denne rapport er resultatet af gruppens arbejde. Arbejdsgruppen bestod af: Jep Loft, IBM (formand) Jette Aagaard Madsen, CSC Hans Henrik Glahn, SAP Anders Henneberg, KMD Michael Holk Wätjen, Sirius IT Flemming Bent Thomsen, Systematic IT-Brancheforeningen, september 2009 Kim Østrup 2

Formål Formålet med denne rapport er at komme med anbefalinger fra IT-Branchen til den ekspertgruppe, som Finansministeriet har nedsat medio 2009 med henblik på at reducere projektrisikoen i ITnyudviklingsprojekter og dermed undgå forsinkelser og tab for såvel de statslige kunder som ITleverandørerne. Metode Arbejdsgruppen har taget udgangspunkt i erfaringer fra en lang række aktuelle udviklingsprojekter. Rapporten henviser ikke til specifikke projekter, idet der er lagt vægt på at identificere generelle risikofaktorer, som er konstateret i et flertal af projekterne. Resumé Det konkluderes, at udbudssystemet ikke fungerer efter hensigten. Der kan naturligvis peges på, at der begås fejl hos såvel kunder som leverandører og externe konsulenter/rådgivere. Men det største problem er ikke disse fejl, men at udbudssystemet anvendes på en måde, der er uhensigtsmæssig. De opgaver, som udbydes, er for omfangsrige, idet de indeholder for mange og for detaljerede krav, der skal opfyldes ufravigeligt og ofte på én gang. Dette medfører ofte, at leverandørerne ikke er i stand til i tilfredsstillende omfang at honorere kontrakterne efter deres eksakte ordlyd, (hvilket dog ikke betyder, at de leverede systemer nødvendigvis bliver dårligere). Det er arbejdsgruppens frygt, at den deraf følgende store projektrisiko i stigende grad vil medføre, at leverandører er mere tilbageholdende med at byde på nye opgaver, hvilket igen indskrænker konkurrenceudsættelsen til skade både for kunder og leverandører. Det anbefales, at projekterne i højere grad tilpasses efter udbudssystemet, hvilket vil indebære en væsentlig ændring i udbudspraksis. 3

1. Udgangspunktet for IT-Brancheforeningens nedsættelse af arbejdsgruppen. 1.1 Aktuelle IT-projekter Arbejdsgruppen har diskuteret forløbet af en række aktuelle nyudviklingsprojekter med baggrund i Rigsrevisionens kritik af fem projekter fra december 2008 og Finansministeriets svar på spørgsmål nr. 96 af 26.3-2009 vedr. 15 projekter. Det synes at være hovedreglen snarere end undtagelsen, at nyudviklingsprojekter ender i forsinkelser og budgetoverskridelser. Finansministeriets svar angiver en gennemsnitlig forsinkelse på 18 måneder og en samlet budgetoverskridelse på 862 mio kr. Heri er ikke medregnet tabet som følge af forsinket igangsættelse af systemerne. Ud over statens meromkostninger kommer leverandørernes tab, som sandsynligvis langt overstiger statens. For leverandørerne er situationen uholdbar. Den af staten ønskede konkurrenceudsættelse kan blive en illusion, fordi leverandørernes mulige fortjeneste slet ikke står mål med risikoen i nyudviklingsprojekter. Kun ganske få leverandører kan tåle tab af den størrelsesorden, som projekterne kan indebære, og man har set, at udbud må gå om, fordi der er indkommet for få tilbud. 1.2 Bonneruprapporten Arbejdsgruppen har diskuteret Teknologirådets rapport om erfaringer fra statslige IT-projekter fra 2001 ( Bonneruprapporten ). Rapporten påpegede de problemer, som dels rammerne for statslige ITprojekter og dels den offentlige organisation afstedkommer. Rapportens observationer var præcise og er fortsat yderst relevante. Hvad angår rammerne for statslige IT-projekter anbefalede rapporten: 1. at dæmpe ambitionerne om specialudviklede systemer og i stedet anvende standardkomponenter eller om muligt standardløsninger 2. at modernisere kontrakterne (K18 og K33) 3. at staten bør optræde som én stor indkøber 4. at den politiske forståelse af projekternes dynamik styrkes. Ad 1. Det må konstateres, at anvendelse af standardsoftware (bortset fra Navision Stat og FESD samt visse SAP-projekter) ikke finder sted i nævneværdigt omfang. Ad 2. Siden 2001 er kontrakterne blevet revideret (K01 og K02). Ad 3. Både SKI og Finansministeriet (Økonomistyrelsen) varetager nu opgaven som central indkøber. 4

Ad 4. Nærværende rapport skal opfattes som et bidrag til at øge denne forståelse. Store ITnyudviklingsprojekter er komplicerede, og problemerne er ofte uforudsigelige, og derfor er de ikke uden videre forenelige med den anvendte udbudspraksis. Hvad angår den offentlige organisation anbefalede Bonneruprapporten: 1. Et tydeligere ledelsesansvar 2. Udarbejdelse af en redegørelse for de overordnede forhold omkring projektet 3. En opsplitning i delprojekter 4. Erfaringsopsamling. Ad 1 og 2. Siden 2001 er der sket fremskridt på de to førstnævnte områder. Ad 3. Arbejdsgruppen mener ikke, at denne opsplitning finder sted i tilstrækkelig grad. Ad 4. Denne rapport kan opfattes som et bidrag til erfaringsopsamlingen. Bonneruprapporten fremsatte følgende anbefalinger vedrørende samspillet med leverandører og konsulenter: 1. Opsamling af erfaringer vedrørende samarbejdet med leverandører og konsulenter 2. Mere flexible kontraktmodeller med positive incitamenter 3. Anvendelse af projektkonkurrencer 4. Udarbejdelse af en code of conduct for samarbejdet 5. Initiativer til at fastholde kvalificerede IT-medarbejdere i staten. Disse anbefalinger er alle væsentlige, men det er Arbejdsgruppens vurdering, at der ikke er sket væsentlige fremskridt på ovennævnte 5 områder. Selvom der således er gjort nogle fremskridt i forhold til Bonnerup-rapportens samlede anbefalinger, er det Arbejdsgruppens vurdering, at udviklingen siden 2001 har indhentet de fremskridt, der er gjort, idet forholdene omkring offentlige indkøb og de store offentlige IT-projekter er blevet yderligere komplekse i den mellemliggende periode, samtidig med at udbudspraksis er skærpet på flere områder. Som en medvirkende faktor kan bl.a. nævnes den flerleverandørpolitik, som mange offentlige myndigheder forfølger, og som er en naturlig konsekvens af ønsket om øget konkurrenceudsættelse. Denne politik stiller meget store og nye krav til kundernes leverandørhåndtering, idet det bliver kundernes ansvar at koordinere forskellige leverandørers aktiviteter i en ofte meget kompleks aftalemæssig sammenhæng. Ligeledes stiller den krav til leverandørerne om at kunne samarbejde. De fleste projekter er anden eller tredje generationsprojekter. Projekterne skal således både tage højde for, at den digitale produktion videreføres under implementeringen, og at eksisterende data bevares med omfattende migrerings- og konverteringsaktiviteter til følge. Hertil kommer, at der anvendes en strengere udbudspraksis end tidligere (hvilket leverandørerne selv bærer deres del af ansvaret for p.g.a. de førte klagesager). Det er Arbejdsgruppens vurdering, at der stilles langt flere ufravigelige krav, ligesom det bliver mere og mere almindeligt, at der ikke kan tages 5

forbehold til kontrakten. Når udbudsmaterialet således på forhånd specificerer selv de mindste detaljer ved løsningen reduceres leverandørens mulighed for at designe en løsning, der udnytter leverandørens erfaringer og opsamlet best practice noget der under alle omstændigheder ville kunne reducere risikoen i et stort IT-projekt. Denne arbejdsgruppes anbefaling retter sig primært mod en mere vidtgående opsplitning af de store projekter i selvstændige (del-)projekter. 6

2. Årsager til de fortsatte forsinkelser og budgetoverskridelser Med kravet om udarbejdelse af en business case, der redegør for de overordnede forhold omkring projektet, har Finansministeriet taget et vigtigt skridt til at forbedre udgangspunktet for projekterne. Det er imidlertid Arbejdsgruppens opfattelse, at årsagen til mange problemer primært skal søges i de rammer, som staten er underlagt: Udbudsreglerne, kontraktsvilkårene og administrationsformen. Disse rammer lader sig ikke ændre i væsentligt omfang. I stedet må opgaverne tilpasses rammerne. Den digitale administration i Danmark er førende i verden. Som kunde er staten fuldt på højde med private kunder, både hvad angår visioner, ledelsesforankring og kvalifikationer hos personalet. Visse opgaver (for eksempel videreudvikling af eksisterende systemer) påvirkes i mindre grad af de nævnte rammer, og de gennemføres normalt med succes. Problemerne opstår primært ved udvikling af større, nye systemer. Her sætter rammerne hindringer for leverandørernes arbejde i et omfang, der gør det så godt som umuligt at gennemføre projekterne til tiden og inden for budgettet. Projektstyring og modenhed hos både kunde og leverandør er af stor vigtighed, men det er ikke i sig selv nok til at afværge problemerne. 2.1 Udbudsformen Hvis et IT-nyudviklingsprojekt skal blive en succes, forudsætter det blandt andet: 1. Stor faglig forretningsviden hos både kunde og leverandør 2. Kendskab til det kommende system hos begge parter allerede når kravene (og svarene derpå) formuleres 3. Tæt kommunikation mellem kunde og leverandør 4. Overblik over det samlede projekt. Disse forudsætninger er som regel opfyldt i det løbende samarbejde, når eksisterende systemer videreudvikles. Men som udbudsreglerne administreres i Danmark, vil typisk et flertal af disse forudsætninger være uopnåelige, når nye systemer udbydes: Ad 1. Kunden har den faglige viden, men den er ofte ikke tilgængelig for leverandøren hverken i tilbuds- eller i udviklingsfasen, fordi den er spredt på alt for mange eller i nogle tilfælde alt for få personer. Ad 2. Kunden stiller sine krav uden at have kendskab til det kommende system, og leverandøren udarbejder sit tilbud, før han har erhvervet dybere faglig viden om systemet. Ad 3. Udbudsreglerne afskærer kommunikation. Dette er medvirkende årsag til, at der kan opstå et gab mellem kundens og leverandørens forventninger til systemet. Forventningsgabet er en gråzone, 7

hvor begge parter kan være i begrundet god tro i deres opfattelse af opgavens omfang. De skuffede forventninger kan føre kunden til at afvise leverancer, hvilket medfører forsinkelse og fordyrelse af projektet. Forventningsgabet kan ydermere være årsag til skuffelse hos kundens personale, hvilket vanskeliggør systemets udbredelse i kundens organisation. Ad 4. Udbuddet indeholder ofte et meget stort antal detaljerede (og ufravigelige) krav, som kræves opfyldt på éngang. Jo flere krav, jo større er projektrisikoen generelt, jo sværere er det for projektledelsen at bevare overblikket over projektet, og jo større er sandsynligheden for, at krav kan være i indbyrdes modstrid. Erfaringen viser desuden, at der opstår behov for at ændre kravene i takt med at arbejdet skrider frem, og indsigten gradvist øges. På de vilkår kan leverandøren dårligt estimere ressource- og tidsforbrug med den fornødne præcision. Udbudssystemet kræver en fast pris, men fastprismodellen hviler ofte på et meget usikkert grundlag. Der er på tilbudstidspunktet så mange ukendte faktorer, at estimaterne må baseres på en lang række forudsætninger, af hvilke en del i praksis viser sig ikke at holde, hvorfor der må vælges en dyrere løsning. En del af usikkerhedsfaktorerne ville forsvinde, hvis brug af standardsystemer var mulig. Men det store antal detaljerede krav og kundens manglende kendskab til de eksisterende standardløsninger vil ofte umuliggøre, at der bydes et standardsystem, selv om et sådant kunne have løst opgaven. Ved anskaffelse af et system, hvor kunden gerne vil inddrage leverandørernes erfaringer for på den måde at stille realistiske krav til et nyt system, kan konkurrencepræget dialog anvendes. Konkurrencepræget dialog stiller dog store krav til både kundens, konsulentens og leverandørernes tidsforbrug, hvorfor det kun skal bruges i situationer, hvor det reelt vil gavne, samtidig med at opgaven skal have et betydeligt økonomisk omfang for at retfærdiggøre det ekstraordinære tidsforbrug. Det kan eksempelvis være inden for områder, hvor der slet ikke findes sammenlignelige systemer i andre myndigheder, hvorfra kunden kunne trække erfaringer. Den konkurrenceprægede dialog er en omkostningstung proces for leverandørerne, og det er også en proces, hvor leverandørerne kan føle, at deres viden, erfaringer og gode idéer bliver stillet gratis til rådighed for konkurrenterne. Derfor skal myndigheden styre processen med fast hånd og have klare aftaler om åbenhed og genbrug af de oplysninger, der fremkommer under processen. Det er naturligvis ønskeligt, at det offentlige indfører en praksis, hvorefter ikke-valgte leverandører belønnes for deres indsats i dialogen. 2.2 Kontrakterne Udarbejdelsen af K02 har været et fremskridt. I denne rapport lægges til grund, at K02 ikke vil blive ændret i en overskuelig fremtid. Det gælder derfor om at anvende den mere hensigtsmæssigt, end det sker i dag. Man må konstatere, at 8

K02 kan ikke håndtere det uforudsete: der er ingen generelle forbehold eller force majeureklausuler, der beskytter leverandøren mod uforudsigelige problemer; og misligeholdelsesbeføjelserne er ubalancerede: kundens hæveadgang og til dels bods- og erstatningsbestemmelserne stiller leverandøren særdeles svagt. Hæveadgang og tilbagelevering af det modtagne er rimelig i et løsørekøb, men helt ødelæggende i et IT-udviklingsprojekt, hvor kundens tilbagelevering af den udviklede kode er værdiløs for leverandøren. Kun få leverandører vil kunne tåle, at en kontrakt hæves (fx. pga. forsinkelse) efter at der er anvendt tusindvis af mandtimer på projektet. Det er nødvendigt, at kunden har adgang til at hæve, men i nyudviklingsprojekter flyttes en overordentlig stor risiko over på leverandøren, idet risikoen i form af spildt arbejde plus bod og erstatning i nogle tilfælde kan overstige det dobbelte af projektets værdi, et beløb der som ofte vil være ude af proportion med leverandørens forventede overskud. Denne risiko må splittes op i mindre dele. Endvidere bør projekterne lægge op til, at ikke-funktionalle krav (f.x. performanceproblemer) afdækkes på et tidligt tidspunkt, dvs. før leverandøren har anvendt tusindvis af timer på at udarbejde specialfunktionalitet. Den statslige kunde (og de involverede konsulenter) bør endvidere være mere opmærksomme på, at en uflexibel kontrakt kan føre til projektets forlis. Dette hænger sammen med den kontraktsadministrationsform, som kunden er tvunget til at følge, jfr. nedenfor. 2.3 Kontraktsadministrationsformen Hvis et større IT-nyudviklingsprojekt skal blive en succes, forudsætter det: 1. Beslutningskraft i projekt- og styregruppe. 2. Flexibilitet i kontraktsadministrationen. 3. Et fælles incitament til at nå målet. Disse forudsætninger vil staten typisk ikke kunne leve op til på én gang. Dette skyldes bl.a. at: Ad 1. Statens repræsentanter i projekt- og styregruppe skal tage hensyn til myndighedens kunder (som i praksis kan være de egentlige beslutningstagere, men som endnu ikke er fortrolige med det kommende system). Ad 2. Man administrerer efter kontraktens ordlyd (andet kan man ikke gøre); det skrevne ord er lov. Man udsætter sig for kritik ved at acceptere en leverance, der ikke præcist lever op til kravene, hvorimod det er mindre risikablet at afvise den. Ad 3. Det er vanskeligt at give afkald på statens rettigheder. Man udsætter sig for extern kritik (f.x. fra Rigsrevisionen), hvis man gør det. Derfor må man ofte afstå fra at søge pragmatiske løsninger. Som følge heraf kan den situation opstå, at kunden træffer en afgørelse (f.x. om at afvise en leverance 9

eller at nægte at indgå et kompromis), som ganske åbenbart vil føre til en forsinkelse og fordyrelse af projektet. Kunden vel må være nærmere end leverandøren til at bære risikoen for det, som ikke med rimelighed kunne forudses ved kontraktens indgåelse; men uanset om der er en erkendelse af, at uforudsete situationer kræver flexibilitet, og at de i kontrakten stillede krav bør modificeres, kan kunden ofte ikke gøre noget ved det. Han må stå fast på sin ret. I sin yderste konsekvens fører dette til, at kunden må påberåbe sig sine misligholdelsesbeføjelser og se projektet forlise. Nødvendigheden af at at undgå kritik kan komme i konflikt med incitamentet til at se projektet lykkes. Leverandøren burde utvivlsomt i mange tilfælde have indtaget en stejlere holdning og påpeget konsekvenserne af kundens administrationsform, men dette kan i praksis ofte ikke lade sig gøre i et kunde/leverandør-forhold. Arbejdsgruppen har ikke set det som sin opgave at foreslå ændringer i de ovenfor omtalte rammer. I stedet anbefales det afpasse opgaveformuleringerne, så de passer til rammerne. Kunden har ikke mulighed for at agere ret meget anderledes, end han gør. En incitamentsstruktur hos kunden kan næppe øge mulighederne for at indgå nødvendige kompromis er; derimod kunne en incitamentsstruktur muligvis påvirke kundens externe konsulenter og rådgivere til at arbejde mere målrettet for projektets gennemførelse. 2.4 Konsulenternes rolle Ved udformningen af krav til de nye systemer har externe konsulenter og rådgivere en central rolle. Det må konstateres, at udbudene almindeligvis har et indhold (f.x. det meget store antal ufravigelige krav), som fører til problemer, og at konsulenterne ikke er blevet anvendt til at ændre herpå. Konsulenter og juridiske rådgivere bør heller ikke anvendes til at gøre udbudsbetingelserne og kontrakterne endnu mere uflexible end nødvendigt, idet konsekvensen meget vel kan være, at man øger risikoen i projektet. Konsulenterne bør tildeles en mere balanceret kritisk rolle, hvori de kan udfordre kundens krav og ønsker og i højere grad have et incitament til at medvirke aktivt til at bære projektet igennem til en succesfuld implementering og dermed sikre realisering af projektets overordnede mål inden for budgetog tidsramme, snarere end at sikre, at kunden får præcis dét, som han har bestilt. Dette kan betyde, at konsulenterne må fastholde tilknytningen til projektet gennem hele forløbet, hvilket kan være ønskværdigt - også fordi det giver større kontinuitet i kundens projektorganisation. Konsulenterne kan derved i højere grad medvirke til at kompensere for eventuel manglende modenhed og beslutningskraft i kundens organisation. 10

3. Hvilke projekter lykkes? Når det er lykkedes for staten at bringe sig i en international førerposition inden for digital forvaltning, skyldes det naturligvis, at mange projekter er vellykkede. Dette gælder f.x. videreudviklingen af de mange eksisterende systemer (hvilket ofte sker under rammeaftaler og ikke kræver nye udbud). Dette arbejde kan nemlig tilrettelægges på en mere hensigtsmæssig måde, som bedre sætter leverandørerne i stand til at opfylde kontrakterne. Projekterne er bl.a. karakteriseret ved: o o o o o o o o Tæt dialog mellem kunde og leverandør uden mellemled Kendskab til systemet hos begge parter Villighed til at se helheder frem for detaljer (og undgå at blive fastlåst i mange detaljerede og ufravigelige krav) Erfaring med anvendelsen Erfaring med performance og andre ikke-funktionelle krav Beslutningskraft i projekt- og styregruppe Mindre enkeltopgaver fremfor én meget stor leverance Flexible kontraktsforhold Implementering af standardløsninger har ligeledes en langt mindre risiko end specialudvikling. Dette forudsætter dog, at man undgår kundespecifikke tilretninger i videst muligt omfang. Krav til systemet må afpasses efter den funktionalitet, som i forvejen ligger i standardløsningen og derfor ikke formuleres på et tidspunkt, hvor kunden er uden kendskab til det standardsystem, der vælges. Det er således absolut muligt at gennemføre it-projekter hvor både funktionalitet, tidsplan og økonomi går op i en højere enhed. I næste kapitel følger arbejdsgruppens anbefalinger til hvilke tiltag der skal til, for at flere projekter lykkes. 11

4. Arbejdsgruppens anbefaling. Arbejdsgruppen anbefaler at undgå de store nyudviklingsprojekter med hundredvis af detaljerede og ufravigelige krav, der skal opfyldes på én gang. Disse projekter egner sig ikke til EU s udbudsregler og krav om en fast pris. Leverandørerne bærer deres del af ansvaret for, at projekterne løber over i tid og budget, men der kan ikke éntydigt peges på nogen metode hos kunde eller leverandør, der fjerner problemerne. I stedet må projekterne splittes op i selvstændige faser eller i flere egentlige delprojekter. En del af disse projekter kan køre under rammeaftaler eller SKI-aftaler, og der kan være flere leverandører involveret. Hver enkelt fase bør naturligvis have værdi for kunden, men man bør indstille sig på at modtage og uigenkaldeligt acceptere delleverancer, som ikke nødvendigvis kan gå i produktion. Den må ses som et trin i en proces, som forbedrer muligheden for at fastlægge de senere trin på en mere hensigtsmæssig måde. Faseopdelingen bør være uden cross default -klausuler, d.v.s. at når en fase er afsluttet, bør den ikke kunne påvirkes af problemer i senere faser. Dette er ønskeligt af flere grunde: cross default er til hinder for, at de senere faser kan udføres af en anden leverandør; cross default er uhensigtsmæssigt i og med at de efterfølgende trin endnu ikke nødvendigvis er beskrevet i detaljer; og cross default opleves af leverandørerne som uforholdsmæssigt byrdefuldt. Det vil være at foretrække, at den første fase adresserer de ikke-funktionelle krav, således at f.x. performanceproblemer kan afklares på et tidligt tidspunkt, inden kodning af specialfunktionalitet påbegyndes. Arbejdsgruppen anbefaler endvidere, at kunderne kun stiller ufravigelige krav, hvor det er absolut nødvendigt. I stedet bør overordnede mål og funktionalitet fastlægges, således at de kan anvendes som styringsparametre. På samme måde bør det være muligt at styre efter en beskrivelse af formålet med arbejdsprocesser snarere end en detaljeret beskrivelse af selve arbejdsprocesserne. Det anbefales at bruge use cases, hvor det er muligt. 4.1 Eksempler på opsplitning af projekter. Der kan næppe gives nogen generel opskrift på, hvordan et udbud tilrettelægges mest hensigtsmæssigt. Her gives nogle eksempler, som efter arbejdsgruppens mening vil øge sandsynligheden for succes: 4.1.1 I et antal tilfælde er der mulighed for at anvende et standardsystem. Dette kan f.x. være tilfældet for klientrelations- og ledelsesinformationssystemer, ERP-systemer, ESDH- 12

systemer eller lignende. Under alle omstændigheder bør kunde og konsulent senest i business case fasen undersøge mulighederne for at indkøbe et standardsystem. Det første delprojekt kan være leverance og implementation af standardsystemet uden nogen specialfunktionalitet overhovedet. Det tomme system kan leveres hurtigt, og det kan så være fundament for en dialogbaseret formulering af de mere detaljerede krav. Det kan endvidere bruges til undervisning af personalet og det kan bruges til at vurdere, om forretnings- og arbejdsgange skal tilpasses systemet snarere end det modsatte. Det vil være en fejl at formulere hundredvis af detaljerede og ufravigelige krav, endnu inden standardsystemet er valgt og afprøvet, fordi kravene kan nødvendiggøre uønsket specialudvikling, og fordi man typisk vil formulere kravene anderledes, når man har lært systemet at kende. Muligvis har systemet standardfunktioner, som overflødiggør et antal krav. 4.1.2 I takt med modningen af digital forvaltning vil flere og flere projekter have som (del)formål at erstatte eksisterende it-løsninger, hvilken kan give særlige udfordringer i forhold til en faseopsplitning af projekterne. Den projektmæssige udfordring vil typisk være, at allerede første fase af den nye løsning som minimum skal have den samme (måske ganske omfattende) funktionalitet som den eksisterende løsning, og at denne første fase således bliver mere omfattende end det er hensigtsmæssigt. Svaret på denne udfordring kan være, at den eksisterende løsning opdeles i et antal, funktionelt meningsfyldte elementer eksempelvis ud fra principperne i serviceorienteret arkitektur. Denne opdeling skal ske før den nye løsning sendes i udbud, således at det ikke er nødvendigt at udskifte hele den eksisterende løsning på én gang. En sådan faseopdelt systemudskiftning vil være langt mere overskuelig og reducere projektrisikoen betydeligt. 4.1.3 I andre tilfælde kan der udvikles et rammesystem, som opfylder de ikke-funktionelle krav (sikkerhed, tilgængelighed, performance m.m.) og indeholder de overordnede sagsbehandlingsforløb. Dette kunne f.x. være tilfældet for systemer til myndighedskontroller. Hver enkelt kontrolordning kan så udvikles efterfølgende og bringes til at køre under rammesystemet. Det første delprojekt kan f.x. være leverance og implementation af rammesystemet og én enkelt kontrolordning. Først når erfaringerne herfra foreligger, udbydes andre kontrolordninger. 13

4.1.4 Udbudsbetingelserne bør ikke hindre såkaldt iterativ udvikling. For at kunne håndtere flere, mindre leverancer i et projekt, anvendes ofte iterative udviklingsmetoder. Ved de iterative modeller opdeles projekter i en lang række mindre forløb med hver sin delleverance. De detaljerede analyser af behov og muligheder udføres i selve projektet, og de mulige løsninger udvikles gradvist i små skridt betegnet»iterationer«. Indledningsvis fastlægges i kravspecifikationen de overordnede mål for det samlede projekt, idet det endelige system løbende fastlægges gennem de udførte iterationer. I hver iteration opnås erfaring og ny viden om det it-system, der skal etableres, idet kunden løbende inddrages for at sikre et samarbejde omkring definering af løsningen. For den enkelte iteration aftales fra gang til gang enten varigheden (»timebox«), prisen (»moneybox«) eller den funktionalitet, der skal etableres i den pågældende iteration. 1 SKI har lavet en specialvejledning til brug for indgåelse af aftaler om iterative projekter under 02.18 rammekontrakten. Vejledningen indeholder en lang række konkrete forslag og anbefalinger til udfyldelse af rammekontraktens bilag, herunder at Den endelige overtagelsesprøve og driftsprøve får karakter af en integrationsprøve af den samlede funktionalitet, da de enkelte iterationers funktionalitet er afprøvet og godkendt tidligere. 2 Ved at benytte iterative udviklingsmodeller sikres således også en hurtigere ibrugtagning og dermed tidligere opnåelse af kundens business case. En variant af iterativ udvikling er den i entreprenørbranchen kendte model med successiv projektering og kalkulation, evnetuelt i form af flere på hinanden følgende runder af successiv projektering og kalkulation. Modellen beskriver, hvordan det er muligt under respekt af udbudsreglerne at gennemføre et udviklingsprojekt, hvori der efter det indledende valg af leverandør gennemføres en fælles projekterings-, planlægnings- og prissætningsfase for det endelige projekt, og at kravspecifikation, tidsplan og pris først fastfryses efter denne fase. Dette kombineres med en walk-away klausul, der gør det muligt for kunden at skifte leverandør efter projekteringsfasen, og samtidig sikrer leverandøren time-betaling for den indsats, der er leveret i denne fase. Eventuelt kan der gennemføres flere runder successiv projektering og kalkulation, en for hvert delprojekt, der indgår i den samlede leverance. 4.1.5 Ved anskaffelse af portal-/selvbetjeningssystemer, kan projektet med fordel opdeles i flere delleverancer både til samme og til flere leverandører. Typiske delleverancer vil være: Infrastruktur (hardware og drift), standard software rammesystem til portalen, 1 Citat fra SKI s specialvejledning om iterative projekter, side 6-7. Vejledningen kan findes her: http://www.ski.dk/aftaler/itogtele/systemloesninger_mv/sider/default.aspx 2 Citat fra SKI s specialvejledning om iterative projekter, side 21. Vejledningen kan findes her: http://www.ski.dk/aftaler/itogtele/systemloesninger_mv/sider/default.aspx 14

indhold og funktionalitet i portalen (dette kan evt. også deles i flere leverancer), ledelsesinformation, design og usability, uddannelse, support, m.v. Ved at dele det samlede projekt i flere leverancer, vil hver enkelt leverance kunne leveres og vurderes hver for sig. Det giver færre risici og hurtigere bevis for succesfuld leverance. Samtidig giver det mulighed for bedre at konkurrenceudsætte de enkelte delleverancer og vælge den bedste leverandør til hver opgave. 15

4.2 Fordele ved den trinvise fremgangsmåde. I SKI s vejledning til iterative projekter under SKI 02.18 rammekontrakten, står bl.a. Modellen (vandfaldsmodellen) egner sig bedst til kortvarige forløb med velkendt teknologi og velkendte forretningsprocesser. Jo mere komplekst eller langvarigt projektet bliver, samt jo mere ukendt og nyskabende den anvendte teknologi eller berørte forretningsprocesser et, desto større risiko vil der være ved anvendelse af Vandfaldsmodellen. 3 Det er tilsvarende arbejdsgruppens erfaring, at den her anbefalede opsplitning af projekterne i mindre, selvstændige dele vil give en lang række fordele: Bedre mulighed for evt. at anvende et standardsystem Hurtigere og sikrere levering af første fase af systemet. Hurtigere adgang til at bedømme systemet overordnet. Hurtigere adgang til at verificere opfyldelse af sikkerhed, tilgængelighed, performance og andre ikke-funktionelle krav. I tilfælde af, at systemet ikke vil kunne opfylde kravene, kan kontrakten hæves, uden at et stort arbejde med specialudvikling (og en masse tid) er spildt. Bedre grundlag for at formulere detaljerede krav, fordi systemet nu er kendt. Mulighed for i dialog med leverandøren at tilpasse kravene til standardsystemets arkitektur. Bedre mulighed for at sikre brugervenlighed via en tæt dialog om videreudviklingen. Mindre risiko for at stille krav, som man senere fortryder og får behov for at ændre. Mindre behov for externe konsulenter til at formulere detailkrav dette kan nu ske direkte mellem kunden og leverandøren. Minimering af gråzonen: dialogen om videreudviklingen gør, at forventningerne til systemet afstemmes. Færre gener som følge af fejl og nedbrud i acceptfasen for kundens personale. Bedre accept af systemet blandt brugerne, som har fået et større medansvar for udviklingen af funktionalitet i videreudviklingsfasen. Gradvis ibrugtagning i kundens organisation med mulighed for bedre brugerinvolvering og deraf bedre brugeraccept. Hurtigere udbredelse af systemet i kundens organisation. Mulighed for at tildele videreudviklingsopgaver til flere leverandører, så én enkelt leverandøren ikke segner under en for stor arbejdsbyrde og dermed forsinker projektet 3 Citat fra SKI s specialvejledning om iterative projekter, side 5. Vejledningen kan findes her: http://www.ski.dk/aftaler/itogtele/systemloesninger_mv/sider/default.aspx 16

4.3 Mulige ulemper ved den trinvise fremgangsmåde. Én stor samlet kontrakt til en fast pris er lettere at håndtere bevillingsmæssigt end flere på hinanden følgende delprojekter, hvor myndigheden må betale for delprojekter uden at have fået et funktionsdygtigt system. Én kontrakt med én samlet leveringsplan giver (i teorien) bedre overblik over tidsrammen og økonomien end flere på hinanden følgende projekter. Leverandørafhængighed: hvis en leverandør har leveret den første fase (f.x. et standard- eller et rammesystem), vil han står stærkere end sine konkurrenter i forhold til de senere projekter At inddele et projekt i en række delleverancer kan påføre det samlede projekt en række ekstraomkostninger bl.a. p.g.a. forlænget projektperiode og gentagne testaktiviteter. Nogle opgaver lader sig af forskellige årsager vanskeligt faseopdele, fordi det er svært at definere enkelte delleverancer med selvstændig værdi. Disse forhold diskuteres i kapitel 5 og 6. 4.4. Udformning af kravspecifikationer. Gældende praksis for udformning af kravspecifikationer er, at der opstilles en meget lang række detaljerede og ofte for både kunde og leverandør uhensigtsmæssigt udformede krav. Som nævnt finder arbejdsgruppen, at der bør ændre på denne praksis i retning af færre, mindre detaljerede krav, som i mindst muligt omfang er ufravigelige. Dette synspunkt gøres også gældende af professor Søren Lauesen, IT Universitet, som har udført et omfattende forskningsarbejde for at kortlægge gældende praksis og på basis heraf udforme fremadrettede anbefalinger om hensigtsmæssig udformning af kravspecifikationer. Søren Lauesens anbefaling er at kunden mht. behovsbeskrivelsen bør sigte på at beskrive, hvilke arbejdsopgaver it-løsningen skal understøtte, i form af en beskrivelse af hvilke arbejdsopgaver bruger og system tilsammen skal udføre. Samtidig bør det klart formuleres, hvad der er det eller de forretningsmæssige formål med den arbejdsproces, der skal it-understøttes, og hvilke forbedringer man ønsker at opnå set i forretnings-perspektiv. Evt. kan sådanne behovsbeskrivelser understøttes af usecases eller arbejdsgangs-beskrivelser af eksisterende opgaveløsning. Søren Lauesens analyser og anbefalinger findes på www.itu.dk/people/slausen. 17

5. Hvordan imødekommes kravet om budgetsikkerhed? Bonneruprapporten nævner at Bevillingssystemet er i dag så fleksibelt, at det generelt set ikke forhindrer (eller sikrer), at offentlige systemer kan gennemføres fornuftigt (kapitel 2.1). Statslige ITprojekter finansieres normalt af institutionens almindelige rammebevilling til driftsudgifter, selv når der er tale om flerårige projekter. Det er kun de helt store projekter, der forelægges særskilt for Finansudvalget (kapitel 2.3). Det er arbejdsgruppens opfattelse, at denne fleksibilitet er blevet mindre siden 2001 i takt med at indkøbskulturen i det offentlige bliver stadig mere formel, og i takt med den stadig stigende offentlige opmærksomhed omkring offentlige IT-systemer, der ikke længere udelukkende skal benyttes af offentligt ansatte som back office systemer, men i stigende grad indgår i et komplekst samspil med forskellige interessenter (borgere, firmaer eller andre myndigheder). En mulig konsekvens af de mange forsinkelser og budgetoverskridelser kunne blive, at der stilles krav om endnu strammere central kontrol med projekterne. Arbejdsgruppen er af den opfattelse, at det ville være et skridt i den forkerte retning. Der foregår allerede nu en detaljeret rapportering fra ministerier til Finansudvalget om funktionalitet, pris og leverancetidspunkt for de større projekter, og det er ikke strammere bånd på kundens projektledelse, der er brug for. Tværtimod kan snævre rammer lægge hindringer i vejen for projekternes gennemførelse. Jo længere man fjerner beslutningskraften fra projektet, jo færre frihedsgrader har den statslige kunde i sin styring af projektet og i sin mulighed for at finde pragmatiske løsninger, og jo større bliver dermed risikoen for forsinkelser. Den her anbefalede trinvise fremgangsmåde lægger op til, at kunden køber et system uden detaljeret viden om, hvordan alle detajlkrav (senere) kan opfyldes inden for en given budgetramme. Alligevel er arbejdsgruppen overbevist om, at sandsynligheden for at nå projektets overordnede mål inden for tidsog budgetrammen bliver større, end den er nu. Der er tre grunde hertil: Omkostningerne er tæt forbundne med projektrisikoen, og initiativer, der reducerer denne risiko, vil føre til større budgetsikkerhed. Den tilsyneladende budgetsikkerhed, der følger af en meget detaljeret kravsspecifikation, afspejles ikke i erfaringerne. Der fokuseres i dag i meget høj grad på omkostningssiden og i mindre grad på indtægtssiden, sådan som den er beskrevet i businesscasen. De her fremsatte forslag vil i højere grad sigte mod at realisere de budgetterede indtægter og besparelser. Den større fleksibilitet i projektforløbet vil i højere grad end tidligere gøre det muligt at inddrage leverandøren i arbejdet med at realisere målene i businesscasen. I en publikation udgivet af IT- og Telestyrelsen i april 2009 med titlen Overordnede principper og best practice 4 står på side 27: 4 Publikationen kan findes her: http://www.itst.dk/arkitektur-og-standarder/arkitektur/arkitekturkrav/oio_principper_best %20practice_v1-0.pdf 18

Anbefaling 4. Anvend iterative udviklingsprocesser. Tænk stort og implementér småt. Brug iterative / fleksible / agile udviklingsprocesser og spis elefanten i små bidder. Nedbryd opgaver i mindre komponenter og test løbende løsningerne i praktisk brug. Det giver bedre løsninger og mindre risiko for at overskride budget og tidsplan. 19

6. Hvordan imødekommes kravet om konkurrenceudsættelse? Det kan anføres, at kunden skulle blive bundet til den leverandør, der vinder den første fase af et projekt, f.x. implementeringen af et standardsystem eller et rammesystem. Til dette er at bemærke: Alternativet til opsplitningen i delprojekter er ét samlet projekt, som leveres af én enkelt leverandør. En opsplitning giver andre leverandører mulighed for at komme i betragtning til de senere faser, selv om han tabte den første fase, og den kan derfor kun øge konkurrencen, aldrig mindske den. Når eksisterende systemer konkurrenceudsættes, har den oprindelige leverandør et klart forspring fremfor andre. Anderledes kan det ikke være. Alligevel ses det relativt ofte, at nye leverandører overtager opgaverne. Kunderne har i større omfang end tidligere indført en flerleverandørpolitik, og de er således bedre i stand til håndtere, at nye leverandører vinder de senere faser. Kunderne har opnået en højere grad af modenhed og dermed en større grad af ejerskab til egne systemer og data. 20