Kravspecifikationen: aftalen om hvad I skal levere
Et projekt begynder med et løfte om et resultat, men et løfte er upræcist, indtil nogen skriver ned, hvad resultatet konkret skal indeholde. Det er kravspecifikationens opgave. Den oversætter projektets formål til en liste af krav: hvad leverancen skal kunne, hvilke egenskaber den skal have, og hvornår den er god nok. Kravspecifikationen hænger tæt sammen med projektets scope, altså afgrænsningen af hvad der er med, og hvad der ligger udenfor. Scope tegner stregen rundt om projektet; kravspecifikationen beskriver, hvad der står inde bag stregen.
Forestil dig et lille softwarehold, der skal bygge en bookingløsning til en frisørkæde. En brugbar kravspecifikation siger ikke bare en bookingløsning, men fastlægger, at kunden skal kunne vælge medarbejder, at systemet skal sende en påmindelse dagen før, og at en booking skal kunne aflyses indtil to timer før tid. Jo tydeligere kravene er formuleret, jo lettere er det senere at afgøre, om leverancen faktisk lever op til aftalen, og jo mindre er der at diskutere ved afleveringen. Gode krav er derfor konkrete, testbare og prioriterede, så alle ved, hvad der er nødvendigt, og hvad der blot er ønskeligt.
Men krav ændrer sig
Uanset hvor omhyggeligt kravene er skrevet, forbliver de sjældent uændrede gennem hele projektet. Kunden bliver klogere undervejs, markedet flytter sig, en teknisk løsning viser sig umulig, eller en interessent dukker op med et behov, ingen havde tænkt på. Ændringer er altså ikke et tegn på dårligt arbejde; de er en naturlig følge af, at man lærer, mens man bygger. Problemet opstår ikke, når krav ændrer sig, men når de ændrer sig ukontrolleret.
Ukontrollerede ændringer er en af de hyppigste årsager til, at projekter skrider. Fænomenet har et navn: scope creep. Det sker, når leverancen gradvist vokser gennem en stribe små tilføjelser, som hver især virker harmløse. En ekstra knap her, et lille ekstra felt der, og kan I ikke lige også et par gange for meget. Ingen af tilføjelserne ser ud af noget alene, men tilsammen sprænger de både tidsplanen og budgettet, uden at nogen traf en bevidst beslutning om det. Det snigende ved scope creep er netop, at ingen sagde ja til helheden; man sagde bare ja mange gange i træk.
Ændringshåndtering: en aftalt proces
Ændringshåndtering er svaret på det problem. Det er ikke en mur, der afviser alle ændringer, men en aftalt proces, der sørger for, at hver ændring bliver set, forstået og besluttet, før den lægges ind i projektet. Pointen er at gøre ændringer synlige og bevidste i stedet for tilfældige. En brugbar proces har fire trin, som gentager sig, hver gang nogen vil ændre noget.
Først bliver ændringen beskrevet i en ændringsanmodning: hvem ønsker hvad, og hvorfor. Dernæst laves en konsekvensvurdering, hvor projektlederen og de rette fagfolk vurderer, hvad ændringen betyder for de tre klassiske hensyn i projekttrekanten: tid, økonomi og kvalitet. Koster den fjorten dages ekstra arbejde? Kræver den flere penge? Går den ud over noget andet, holdet allerede har lovet? Herefter træffes en beslutning af nogen med mandat til det, typisk en ændringsgruppe (et change board) eller styregruppen, der siger ja, nej eller ja-men-senere. Til sidst bliver den godkendte ændring lagt ind: kravspecifikationen, tidsplanen og budgettet opdateres, så planen igen afspejler virkeligheden. En ændring, der besluttes, men aldrig skrives ind i planen, er lige så farlig som en, der aldrig blev vurderet.
Versionsstyring af krav
Når krav kan ændre sig, skal man kunne se, hvornår de ændrede sig, og hvad de var før. Derfor hører versionsstyring med til ændringshåndtering. Kravspecifikationen får et versionsnummer, og hver gang en ændring godkendes, tæller nummeret op, mens den gamle version gemmes. Så kan holdet altid svare på, hvilken udgave af kravene der var gældende, da en bestemt beslutning blev truffet. Det lyder som bogholderi, men det er det, der gør det muligt at holde alle enige om, hvad aftalen egentlig er lige nu.
Til den løbende styring hører også en ændringslog: en simpel oversigt over alle anmodninger, deres konsekvens og deres status. Loggen er projektets hukommelse. Den viser, hvad der er sagt ja og nej til, hvem der besluttede det, og hvordan de mange små beslutninger tilsammen har flyttet projektet fra det oprindelige udgangspunkt. Uden en log forsvinder historien, og så bliver det umuligt at forklare bagefter, hvorfor projektet endte, hvor det gjorde.
Den berettigede ændring og den, der sniger sig ind
Hemmeligheden er at skelne mellem to slags ændringer, der ligner hinanden på overfladen. Den berettigede ændring udspringer af ny og reel viden: en lov er blevet skærpet, en antagelse holdt ikke, et behov har vist sig vigtigere end først antaget. Den slags fortjener at blive taget alvorligt, vurderet ærligt og ofte sagt ja til, netop fordi projektet bliver bedre af den. At håndtere ændringer er ikke det samme som at være stædig.
Den anden slags er lige-en-lille-ting-kravet, der sniger sig ind uden om processen. Det kommer sjældent som en formel anmodning, men som en bemærkning i en gang eller en linje sidst i en mail: kan I ikke lige også lige. Det er ikke født af nødvendighed, men af, at det virker nemt at bede om, når man alligevel er i gang. Problemet er ikke ondskab, men at ingen har vurderet, hvad det koster. Går man med til nok af dem, betaler holdet regningen i overarbejde og forsinkelse, uden at nogen nogensinde valgte det. Den gode projektleder afviser ikke sådanne ønsker koldt, men fører dem tilbage i den aftalte proces: skriv det som en anmodning, så vurderer vi konsekvensen, og så beslutter vi. Dermed bliver selv de små ting til synlige valg i stedet for usynlige lækager.
God ændringshåndtering hænger derfor sammen med resten af projektarbejdet. Den bygger på en klar kravspecifikation og et veldefineret scope, den beskytter den kvalitet, holdet har lovet, og den holder projektet fri af de klassiske faldgruber, hvor gode viljer langsomt æder tidsplanen op. Når leverandører er involveret, får processen desuden en juridisk side, fordi ændringer i arbejdets omfang påvirker det, der er aftalt i kontrakten, og derfor skal håndteres formelt. Og fordi hver ændring rykker ved planen, spiller ændringshåndtering tæt sammen med planlægningsparadokset: vi lægger planer på et tidspunkt, hvor vi ved mindst, og må derfor kunne justere dem bevidst, efterhånden som vi bliver klogere.
Kort sagt
Kravspecifikationen fastlægger, hvad projektet skal levere, og binder dermed an til scope. Men krav ændrer sig, og ukontrollerede ændringer, scope creep, er en hovedårsag til, at projekter skrider. Ændringshåndtering er den aftalte proces, der gør ændringer bevidste: en anmodning beskrives, konsekvensen for tid, økonomi og kvalitet vurderes, nogen med mandat beslutter ja eller nej, og først derefter opdateres planen. Versionsstyring og en ændringslog holder styr på, hvad aftalen er, og hvordan den har flyttet sig. Og den vigtigste dømmekraft er at skelne den berettigede ændring, som gør projektet bedre, fra det lille krav, der sniger sig ind uden om processen og betales i det skjulte.