Når man anskaffer et it-system der skal udvikles eller tilpasses, skriver man som regel en kravspecifikation og en kontrakt. Kravspecifikationen fastlægger hvad der skal leveres, og kontrakten fastlægger hvad der skal ske når det hele ikke går som forventet. Hvad skal der fx ske hvis leverandøren ikke leverer til den aftalte tid eller hvis der er fejl i det der er leveret? Og hvad hvis kunden har glemt et vigtigt krav?
I praksis er kravspecifikationen et bilag til kontrakten. Kravene kan også være delt op i flere bilag.
IT-specialisterne tager sig traditionelt af kravspecifikationen, mens juristerne tager sig af kontrakten. Mærkværdigvis ved de to faggrupper meget lidt om hinandens område, til trods for at der ikke er nogen klar grænse mellem krav og kontrakt. Mange jurister der arbejder med it-kontrakter har aldrig set en kravspecifikation. Og mange it-folk har forgæves forsøgt at forstå en kontrakt.
I dette lille skrift har jeg som it-ekspert prøvet at forklare andre it-eksperter hvad kontrakter er:
IT-kontrakter for IT-folk (pdf)
Der er flere kontrakter i brug til anskaffelse af IT-systemer. Hvilken passer bedst til problem-orienterede krav (SL-07)? Nogle emner behandles både i kontrakt og krav, fx servicemål (svartider, mv.). Hvad er bedst?
I nyere kontrakter, fx K02 og K03, er der en tendens til at beskrive udviklingsprocessen i kontrakten. K03 kræver fx at der bruges en agil metode, at man hierarkisk nedbryder krav og mål, og at man skelner mellem absolutte krav og øvrige krav. Her gentager man den svaghed traditionelle krav har: De stiller krav om hvad systemet skal gøre. Det gør det svært for leverandøren at bruge det han har. I stedet burde de beskrive hvad systemet skal bruges til.
Tilsvarende skal man ikke stille krav om en bestemt udviklingsmetode, men lade leverandøren foreslå hvad han ved virker. Kunden skal så sikre sig at den metode giver ham de styringsmuligheder han har behov for. Se mere om problem-orienterede krav: Dansk og Engelsk
Jeg har udviklet en problem-orienteret kontrakt der dækker hvad de traditionelle gør, men er meget kortere. Samtidig dækker den langt bedre hvad der sker i virkelige projekter med blanding af agil og andet. Jeg tog PLS kontrakten, K02, K03 og SL-07 kravspecifikationen, og nedbrød dem til i alt 75 emner. Nogle emner behandles flere steder, fx funktionelle krav og overtagelsesprøve, andre kun et enkelt sted, fx risikovurdering og brugervenlighed.
Vil du prøve en problem-orienteret kontrakt med problem-orienterede krav? Så send en mail til: slauesen@os.dk
Jeg har så flyttet så meget som muligt over i kravene. Resultatet er overraskende:
I SL-07 kravene sker der det, at kapitel K bliver krav til anskaffelsesprocessen. Der står en tidsplan, krav til støtte af kundens projektledelse (en slags "task") og krav til støtte af problemstyringsprocessen (et andet task). Kunden har angivet sit behov og leverandøren beskriver hvordan han støtter det.
Vejledningen til SL-07 har fået et kapitel 6 om kontrakten. Den viser kontrakten på højre side og kommenterer den på venstre. Der kom en overraskelse til: Hvis parterne bruger kontrakten og følger de nye krav omhyggeligt, burde man forebygge 24 af de 37 skadesårsager som Lauesen har fundet i store offentlige IT-anskaffelser (skadesårsagerne). Det er beskrevet i vejledningen, version 8 og 9, side 114. Se Problemorienterede krav SL-07 (pdf) og Engelsk udgave.
Du kan se seneste udgave af SL-07 kontrakten her: Kontrakt til SL-07 (docx) og den engelske version: Contract for SL-07 (docx).
Her er den eksemplariske kravspecifikation med krav til udviklingsprocessen i kapitel K: EPJ-krav (docx) og den engelske version: EHR-requirements (docx).
Du kan se listen med de 75 emner og hvilke kontrakter der behandler dem her: KontraktEmner, samlet liste (docx)
Og den samme liste med hvordan SL-07 kravene og SL-07 kontrakten behandler emnerne:
Kontraktemner med SL-07 (docx)