Sådan opbygger du en tidsplan for et softwareudbud med milepæle

Formål og rammer for tidsplanen i et softwareudbud

En tidsplan for et softwareudbud er ikke en liste over datoer, men et billede af projektets logik og afhængigheder. Den hænger tæt sammen med scope, ressourcer og milepæle og skal vise, hvornår der skal træffes beslutninger, og hvornår leverancer skal være klar. Den kobling gør tidsplanen til et styringsværktøj frem for et dokument, der kun ser godt ud på papiret.

I et udbud har tidsplanen en dobbelt rolle: udadtil over for markedet, hvor frister for spørgsmål, tilbudsfrist og evaluering skal være entydige; indadtil over for projektorganisationen, hvor beslutningspunkter, godkendelser og overleveringer skal ligge fast.

Rammesætningen bør slås fast først: Skal tidsplanen styre udbudsprocessen frem mod kontraktunderskrift, implementeringen eller begge dele? En plan fra behovsafklaring til idriftsættelse har andre milepæle og en anden detaljeringsgrad end en plan, der kun dækker udbudsforløbet. Uden den afklaring bliver planen upræcis i begge ender.

En konkret tidsplan for et softwareudbud skal dække både udbuds- og implementeringsforløbet, hvis den skal følge projektet fra behov til idriftsættelse. Det betyder milepæle for udbudsprocessen og for den efterfølgende implementering, herunder underskrivelse af kontrakt. Fristerne skal fremgå som datoer eller faser, så planen kan styre både spørgsmål, tilbud og godkendelser.

Afklar mål, scope og interessenter, før milepæle fastlægges

En tidsplan kan ikke kompensere for uklare projektmål eller uafklaret scope. Er leverancerne ikke præcist defineret, skal planen konstant justeres. Derfor bør man ikke begynde i planlægningsværktøjet; fundamentet skal være på plads, før milepælene sættes.

Fire ting bør ligge fast, før planen bygges: tydelige projektmål, afgrænset scope, identificerede milepæle og overblik over interessenter. I et softwareudbud betyder det, at man har taget stilling til, hvilke forretningsbehov løsningen skal dække, hvad der ikke er en del af opgaven, og hvilke krav der er bindende i udbudsmaterialet.

Interessentoverblikket afgør, hvor mange godkendelsesled tidsplanen skal rumme. Typisk skal styregruppe, fagbrugere, arkitektur, jura og indkøb ind over forskellige beslutninger, og hver af dem lægger tid til kalenderen. Kortlægges de først, undgår man at opdage midt i udbudsforløbet, at en nødvendig godkendelse aldrig blev indregnet som milepæl.

Opdel softwareudbuddet i hovedleverancer og aktiviteter

Tænk i leverancer frem for aktiviteter: Hvad skal være færdigt, før projektet kan gå videre? Det skaber fokus på værdi frem for travlhed og giver naturlige knækpunkter i planen. For et softwareudbud er hovedleverancerne typisk behovsafklaring, kravspecifikation og udbudsmateriale, evaluering af tilbud, kontraktindgåelse og den efterfølgende implementering.

Når hovedleverancerne er defineret, nedbrydes hver af dem i konkrete aktiviteter, der kan planlægges og estimeres. Brug en simpel Work Breakdown Structure-tankegang. For udbudsmaterialet betyder det fx, at kravspecifikation, tildelingskriterier, kontraktudkast, bilag og høringsrunde bliver selvstændige aktiviteter med hver deres varighed og ejer.

Planen bliver brugbar, når hver aktivitet har en ansvarlig, et tydeligt færdigkriterium og en placering i rækkefølgen. Uden det er den en liste, man ikke kan bruge til at se, om man er bagud, før det er for sent.

Planen bør skelne mellem udbudsleverancer og implementeringsleverancer. I udbudsforløbet er behovsafklaring, kravspecifikation, udbudsmateriale, evaluering og kontraktindgåelse milepæle; i implementeringsforløbet er overlevering og godkendelse af leverancer de naturlige knækpunkter.

Placér milepæle som beslutnings- og godkendelsespunkter

En milepæl markerer et vigtigt delresultat i projektets livscyklus. Den skaber naturlige stop til statusrapportering og kursjustering. Milepæle nedbryder projektplanen i faser og identificerer vigtige overleveringer, datoer og større leverancer. Som regel markerer de overgangen fra en projektfase til den næste.

Typiske milepæle i et softwareudbud er færdiggørelse af vigtige leverancer, slutningen af en projektfase eller starten på en ny, underskrivelse af kontrakter, vigtige overleveringer til kunden eller internt i projektgruppen, kundens eller interessenternes godkendelse af leverancer, beslutningsdatoer og opnåelse af succeskriterier. Flere af dem er formelle beslutningspunkter, hvor et go/no-go skal træffes, før planen rykker videre.

Det er projektets scope, der afgør antallet af milepæle: brug så mange, som der er behov for for at fastholde overblikket over fremdriften. Større projekter har både over- og underordnede milepæle; mindre projekter kan klare sig med et fåtal overordnede. Milepæle bruges primært i vandfaldsmodellen, hvor de viser sig som markører i den overordnede projektplan.

I et softwareudbud kan milepæle konkret være færdiggørelse af kravspecifikation og udbudsmateriale, beslutningsdato for anskaffelsesstrategi, underskrivelse af kontrakt samt godkendelse af leverancer i implementeringen. Hver milepæl skal have en ejer og et færdigkriterium, så den kan bruges som go/no-go.

Hovedmilepæle i et softwareudbud – fra behov til idriftsættelse

Fastlæg realistiske frister, afhængigheder og buffere

Når aktiviteterne er brudt ned, skal varigheden vurderes realistisk for hver enkelt, og det skal kortlægges, hvilke opgaver der kan køre parallelt, og hvilke der er afhængige af hinanden. Undervurdering er en klassisk faldgrube, især ved aktiviteter, hvor man venter på andre — leverandørers svartid, interne høringsrunder og juridiske gennemgange.

En holdbar plan bygges ved at afklare scope, kortlægge afhængigheder, estimere ærligt, planlægge kapacitet og buffere og følge op fast. Kapacitetsplanlægningen overses ofte: Selv en korrekt estimeret aktivitet holder ikke, hvis de personer, der skal løse den, samtidig er bundet op på drift, ferie eller andre projekter.

Buffere bør placeres, hvor usikkerheden faktisk ligger, frem for jævnt fordelt som skjult slæk i alle aktiviteter. I et udbud er der typisk usikkerhed om myndighedsgodkendelser, klagefrister og leverandørens leveranceevne, mens selve dokumentproduktionen er mere forudsigelig. En synlig buffer ved de usikre punkter gør det muligt for styregruppen at se, hvad der bliver brugt, og hvorfor.

Udbudsloven § 134, stk. 1, fastsætter en konkret frist: Supplerende oplysninger om udbudsmaterialet og supplerende dokumenter skal meddeles senest 6 dage før udløbet af fristen for at afgive ansøgning eller tilbud. Ansøgere og tilbudsgivere skal have 6 fulde dage til at forholde sig til oplysningerne.

Eksempel: Er tilbudsfristen den 28. oktober kl. 12.00, er den 27. oktober fristens første dag. Skal der være 6 fulde dage, skal de supplerende oplysninger være meddelt senest den 21. oktober med udgangen af dagen (kl. 23.59).

Frister beregnes efter fristforordningen, Rådets forordning nr. 1182/71 af 3. juni 1971. Falder fristens sidste dag på en lørdag, søndag eller helligdag, forlænges den til næste arbejdsdag; det gælder dog ikke, når der regnes tilbage fra en bestemt dato som ved supplerende oplysninger.

Indtænk anskaffelsesstrategi og open source i tidsplanen

Den fællesoffentlige vejledning om brug af open source i den offentlige sektor henvender sig blandt andet til it-projektledere, it-jurister, it-arkitekter, indkøbere, contract managers og it-chefer. Den er rettet mod dem, der skal tage stilling til anskaffelse af software. Vejledningen definerer open source-software som software udgivet under en licens. Licensen giver enhver ret til at bruge, undersøge, ændre og dele softwaren og dens kildekode frit og til ethvert formål.

Vejledningen peger på, at open source ikke handler om it-afdelingens teknologiske præferencer, men er en strategisk forretningsmodel og nogle udviklingsmetoder, der fremmer offentlige myndigheders medejerskab til deres løsninger og skaber bedre muligheder for at dele, videreudvikle og genbruge digitale løsninger. Myndigheder undgår så vidt muligt løsninger, der skaber afhængighed af specifikke leverandører og teknologier, og kan hvor relevant anvende bæredygtige open source-komponenter.

Valget er ikke enten-eller mellem open source og proprietære løsninger, men handler om at vælge den løsning, der skaber værdi ud fra myndighedens egne udfordringer og behov. Det får betydning for milepælene: Vælger man at genbruge en open source-komponent eller et fællesoffentligt produkt, skal der indlægges aktiviteter til licensvurdering, teknisk vurdering af komponenten og beslutning om, hvem der vedligeholder den efterfølgende.

Anskaffelsesstrategien bør derfor fastlægges som en milepæl i sig selv, inden udbudsmaterialet skrives færdigt. Skal løsningen bygges på åbne standarder for at sikre udveksling af informationer på tværs af systemer, eller skal der stilles krav om adgang til kildekode og exit-plan? Svarene ændrer kravspecifikationen, evalueringskriterierne og dermed tidsplanen. Genbrug er udbredt: Danske offentlige myndigheder bruger eksempelvis LibreOffice til tekstbehandling og QGIS til geodatabehandling, og 82 kommuner bruger OS2kitos.

Den milepæl skal have en dato og en ejer, inden udbudsmaterialet færdiggøres. Vælges genbrug af open source, skal licensvurdering, teknisk vurdering og beslutning om vedligeholdelse indgå i tidsplanen som aktiviteter med færdigkriterier.

Open source vs. proprietær software – betydning for tidsplanen

Fordele og ulemper ved at genbruge open source i offentlige softwareudbud

Visualisér tidsplanen, så den bliver brugt aktivt

Et Gantt-diagram giver overblik over sammenhængen mellem aktiviteter og tid. Det behøver ikke være avanceret; vigtigst er, at det er forståeligt og bruges aktivt.

Til et softwareudbud kan det betale sig at lave to niveauer: et overordnet diagram med hovedleverancer og milepæle til styregruppen og leverandører og en mere detaljeret plan til den interne projektgruppe og til dem, der skal levere de enkelte dokumenter. Detaljeringsgraden skal følge modtageren, ellers drukner beslutningstagerne i aktiviteter, de ikke skal forholde sig til.

Visualiseringen skal vise beslutningspunkterne tydeligt, ikke kun arbejdsopgaverne. Markeres go/no-go-punkter, tilbudsfrist og godkendelser som selvstændige milepæle i diagrammet, bliver det øjeblikkeligt synligt, hvor planen er sårbar, hvis en godkendelse glider.

Visualiseringen bør vise konkrete frister, fx tilbudsfrist og fristen for supplerende oplysninger, som selvstændige markører. Så bliver det synligt, om 6-dages fristen i udbudsloven § 134, stk. 1, kan overholdes.

Kommunikér og følg op med interessenter og styregruppe

Milepæle er effektive, når der skal kommunikeres med alle involverede interessenter, og en projektplan med milepæle holder fokus på projektets vigtigste leverancer og deadlines. Milepælen er derfor det naturlige omdrejningspunkt for status til styregruppen frem for en opremsning af alle igangværende aktiviteter.

Opfølgningen bør bindes til milepælene: Ved hvert stop vurderes det, om leverancen er godkendt, om næste fase kan starte, og om den efterfølgende del af planen skal justeres. Det er i de stop, kursjusteringen kan ske, før en forsinkelse forplanter sig gennem hele udbudsforløbet.

Forventningsafstemningen med interessenterne handler om at være tydelig om, hvornår der forventes beslutninger fra deres side. Ligger godkendelser og beslutningsdatoer som milepæle med ejere og datoer, kan en forsinkelse henføres til det rigtige sted i planen i stedet for at blive et generelt problem til sidst.

Ved hver milepæl bør styregruppen få status på dato, leverance og næste beslutning. En forsinket godkendelse eller et udskudt go/no-go skal fremgå som ændring i planen, ikke skjules i aktivitetslister.

Undgå typiske faldgruber i tidsplanen

Mange projektledere oplever, at tidsplanen enten bliver for overordnet eller alt for detaljeret. Enten mister den retning, eller også drukner den i detaljer. Resultatet er det samme: manglende overblik, uklare forventninger og gentagne forsinkelser.

Undervurdering er en anden klassisk fejl, især når varigheder sættes uden at kortlægge afhængigheder og uden at tage højde for, hvem der reelt er ledige til at løse opgaverne. En plan, hvor alle aktiviteter antages at kunne køre parallelt, holder sjældent.

Antallet af milepæle bør matche scope: For få giver ingen styring undervejs, for mange gør planen uoverskuelig og milepælen til en tom formalitet. Justerer man planen undervejs, bør ændringen ske ved milepælene, så styregruppen kan se, hvad der er ændret, og hvorfor.

En klassisk faldgrube er at glemme de udbudsretlige frister, fx 6-dages fristen for supplerende oplysninger. Den skal ligge fast i planen, fordi den styrer, hvornår udbudsmaterialet senest kan ændres.