InfoBro Consults 
Empowerment of PublicManagement by Information Technology Solutions

Specifikation, koordination, kvalitetssikring

Succes er ikke tilfældig Det er sjældent tilfældigt når et it-projekt har succes. En række forhold har afgørende indflydelse på et projekts skæbne. Vi er specialiceret i specifikation, koordination og kvalitetssikring. Tre væsentlige faktorer i ethvert it-projekt med success.
Udgangspunkt i det forretningsmæssige Ethvert projekt må tage udgangspunkt i forretningsmæssige ønsker om at løse nye opgaver eller løse eksisterende opgaver bedre. Dernæst skal der være synlig ledelsesmæssig vilje til at realisere projektet.
Ledelsesmæssig opbakning

Det ledelsesmæssige fokus skal sikre at medarbejdere og andre aktører motiveres for at deltage aktivt - alternativt søger andre opgaver. Det skal også sikre beslutningskraft og tilstrækkelige ressourcer til projektet. Uden sand ledelsesmæssig prioritering er det i bedste fald spild af kræfter at iværksætte et projekt. Og projekter er altid større end blot it-projektet. Der er altid en større eller mindre organisationsændring som følge - eller som omdrejningspunkt. Det er indlysende, at en velfungerende database er uinteressant hvis den ikke anvendes.

En god projektleder

Projekter omfatter nemt en række aktører og det er væsentligt at deres roller er aftalt. Projektorganisationen skal sikre dette. Den beskriver hvem der har hvilke roller og hvem der har kompetence til at træffe hvilke beslutninger. En af de vigtigste roller er projektlederrollen. Der kan være flere projetledere med hvert deres område, men den person der er projektleder for brugerorganisationen er den vigtigste for projektets success.

Styring af krav, forventninger og leverandører

De væsentligste opgaver for brugerorganisationens projektleder er at styre krav og forventninger til systemet, at sikre at aftalte krav afspejles i systemet, og at budget og tidsplaner holdes. Der skal også styres aftaler med leverandører og andre parter, der hver især påtager sig sin del af opgaverne. En  god beskrivelse af hvad der skal leveres, hvordan det ønskes leveret, hvor og hvornår det skal leveres og hvordan det leverede skal kvalitetssikres, er forudsætningen for at kunne indgå fornuftige aftaler. En aftale er typisk knyttet til en række bilag der beskriver de forventede ydelser.

Kravspecifikation - brugsscenarier Et af de væsentligste bilag er kravspecifikationen - gerne med scenarier der beskriver hvordan en bruger af systemet vil opleve det. I situationer med stor usikkerhed omkring krav og teknologi må ønsket om komplet kravspecifikation afviges til fordel for hel eller delvis prototypning af løsningen - ofte baseret på parvis udvikling (extreme programming) og time-boxing. Udover de rent funktionelle krav skal der også specificeres implementeringsmæssige og operationelle krav.

SL-07 kravskabelon, udviklet af Søren Lauesen fra IT-universitetet, er et godt redskab til at komme godt rundt om kravene med fokus på det væsentlige.

Leveranceplan og produkter Et andet væsentligt bilag til en leverandøraftale er en leveranceplan. Leveranceplanen beskriver hvilke leverancedele (produkter) der skal leveres hvornår. God projektledelse tager udgangspunkt i produktion, leverance og kvalitetssikring af enkeltprodukter. Et antal produkter tilsammen danner typisk en fase i projektet, en milepæl for betaling og beslutninger.
Faser og time-boxing Faser må ikke være for lange, almindeligvis omkring 2-4 måneder. Det er vigtigt, at der med jævne mellemrum kan gøres status i forhold til projekt- og leveranceplan. Korte faser kan opnås ved at definere store leveranceprodukter i flere versioner, hver med en klar produktbeskrivelse og kvalitetskrav, så reel status er mulig undervejs. I situationer med stor usikkerhed om krav, teknologi og implementering kan time-boxing af leveranceprodukter være en brugbar styringsmetode.
Kvalitetsplan og kvalitetssikring

Et leveranceprodukt skal beskrives så det kan afgøres om det er leveret og om det er godt nok. For at afgøre om det er godt nok må der som del af beskrivelsen være opstillet kvalitetskrav. Under produktets tilblivelse og/eller ved dets levering sikres kvaliteten mod de opstillede mål. I formelle projekter indgår dokumentation af gennemført kvalitetssikring som en del af det leverede produkts generelle dokumentation, ligesom der anvendes en kvalitetsplan sammen med leverance- og projektplanen

Ændringsønsker Ændringsønsker dokumenteres undervejs og prioriteres stramt for ikke at kvæle udviklingsprojektet. Langt de fleste systemer bliver videreudviklet efter den første version er færdiggjort. I en udviklingssituation skal man have dette for øje og satse på at få lagt "hovedsporet" i første version. Det kan så altid forbedres når der er reelle driftserfaringer. Alternativet er forsinkelse, fordyrelse og risiko for forplumring af de oprindelige ønsker til systemet.
Afleveringsprøve Afleveringsprøven er den ultimative kvalitetssikring af systemet. Her afprøves systemet eller en version af dette i sin helhed. Der tages udgangspunkt i kravspecifikationen og de ændringer der er aftalt undervejs. Fejl og problemer logges, og akcept kan være betinget af efterfølgende udbedring af mindre alvorlige problemer.
Implementering og test Afleveringsprøven er også en væsentlig uddannelsesaktivitet for medarbejdere der siden skal anvende systemet. Der er ingen bedre måde at lære et system at kende på end ved at teste det.
Projektafslutning De sidste leveranceprodukter er typisk dokumentation af systemet. Bruger- og driftsvejledning, i det omfang det er nødvendigt, skal foreligge i en anvendelig version til brug ved afleveringsprøven. Efter testen ajourføres disse og den mere tekniske dokumentation færdiggøres
Drift og vedligeholdelse Inden systemet tages i brug skal der laves aftaler om drift og vedligeholdelse, hvis dette ikke er medtaget i udviklingsaftalen. En garantiperiode med fri udbedring af fejl kan være aftalt.
Risiko, teknologi og leverandører Risikoanalysen anvendes tidligt i projektforløbet til at afdække svagheder og fokusere indsatsen på at minimere erkendte risici. Analysen kan også bidrage til valg af teknologisk platform, potentielle leverandører, og dokumentations-, udviklings- og kontraktform. Analysemæssigt kan man opdele i specifikationsrisici, organisationsrisici og tekniske risici.
InfoBro Consults

- når der er brug for et hoved mere til specifikation, koordination eller kvalitetssikring.