Når det så er sagt, er det faktisk ofte sådan, at kunderne eller it-leverandøren er for hurtige til at træffe beslutning om teknologisk platform i stedet for først at afdække de forretningsmæssige behov i tilstrækkelig grad. Meget hurtigt bliver behovet for fx at effektivisere en arbejdsgang eller forbedre servicen overfor kunder eller borgere italesat som: “Vi skal have implementeret et nyt system XYZ” – frem for at fokusere på, hvad det egentlig er, man gerne vil opnå med projektet. Den konkrete italesættelse af systemet tidligt i forløbet fører ofte til en selvopfyldende profeti, hvor parterne i projektet bliver blinde overfor andre muligheder, glemmer analysen af behovene og implementerer det først italesatte system – uagtet, at der kunne være andre løsninger, der opfyldte behovet bedre.
Frem for at starte med at træffe beslutning om teknologi og design, bør fremgangsmåden være at indlede projektet med at gennemføre en forretningsanalyse, der afdækker, hvad der skal til for at understøtte kundens behov. I nogle tilfælde, er det måske ikke engang implementeringen af en it-løsning, der er det rigtige svar, men mere et spørgsmål om at ændre arbejdsgangen eller foretage tilpasninger i den eksisterende løsning – analog som digital. Ofte kan en it-løsning dog bidrage til en effektiviseringsgevinst, men uanset, hvad løsningsforslaget omfatter, bør der altid udarbejdes en business case, der afdækker, de økonomiske såvel som de kvalitative forhold omkring beslutningen. Business casen skal gennem projektets levetid revideres, efterhånden som man bliver klogere på løsningens design, og de gevinster og omkostninger, der er forbundet med projektet.
I Visma Consulting gennemfører vi flest muligt projekter efter den agile udviklingsproces, Scrum. Til trods for, at et af mantraerne i agil udvikling er at undgå “big design up front”, er det nødvendigt at indlede med en foranalyse, som scoper projektets omfang og analyserer forretningens behov. Det er meget vigtigt, at analysen sker i tæt samarbejde med kunden, så kunden tager ejerskab over de forretningsmæssige behov, samtidigt med, at vi kan udfordre kunden på, om det nu er det, hun har behov for. Vi ved naturligvis ikke mere om kundens forretning, end kunden selv, men ofte kan det være gavnligt at kigge på udfordringerne fra forskellige vinkler.
Afhængigt af projektets karakter og omfang vil vi så bringe forskellige værktøjer i spil. Det kan fx være en interessentanalyse, kortlægning af forretningshændelser, modellering af forretningsprocesser og udarbejdelse af use cases. Der bliver på dette tidspunkt ikke lavet et detaljeret teknisk design (det ville jo netop være “big design up front”), men det er nødvendigt at udarbejde en logisk arkitektur på baggrund af kundens forretningsmæssige krav. På baggrund af denne kan der så træffes beslutning om teknologisk platform – om der kan anvendes standard-software, eller løsningen skal specialudvikles, mv.
Efter foranalysen skal det egentlige udviklingsprojekt igangsættes. Her arbejder vi med et “sprint 0”, hvor vi ud fra foranalysen sætter rammerne for projektet, får infrastrukturen op at køre, osv., inden vi fortsætter med udviklingssprints’ene (sprint 1-X)…men det er en helt anden historie.
