Discovery-workshop: sådan afklarer I et IT-projekt, før det bliver dyrt

Salgschefen vil have en kundeportal, så kunderne selv kan se ordrer. Økonomichefen vil have, at fakturaerne kommer direkte fra e-conomic. Kundeservice vil have færre telefonopkald, og direktøren vil have det hele klar til messen i marts. Alle fire har ret, og alle fire tror, de taler om det samme projekt. En discovery-workshop er de timer, hvor det bliver tydeligt, at de ikke gør, og hvor de bliver enige om, hvad der skal bygges først.

I denne guide får I en komplet agenda, I kan kopiere, en oversigt over hvem der skal være med, hvad en workshop typisk koster, hvilke leverancer I bør stå med bagefter, og et regneeksempel. Den er skrevet til jer, der skal købe et IT-projekt, og som vil være sikre på, at pengene går til det rigtige.

Hvad er en discovery-workshop?

En discovery-workshop er første fase i et software- eller app-projekt. Den samler de mennesker, der ved noget om forretningen, brugerne og teknologien, i samme rum i en kort periode, og den har ét formål: at omsætte idéer og ønsker til et konkret, prioriteret scope, der kan designes, prissættes og bygges. Workshoppen besvarer typisk disse spørgsmål:

• Hvilket forretningsmål skal løsningen flytte, og hvordan måler vi det?
• Hvem er brugerne, og hvad prøver de at få gjort?
• Hvordan foregår arbejdet i dag, og hvor gør det ondt?
• Hvilke funktioner skal med i første version, og hvilke kan vente?
• Hvilke systemer skal løsningen tale med, og hvem ejer dem?
• Hvad er de største risici, og hvordan tester vi dem tidligt?
• Hvad er budgettet og tidsrammen, og hvad er realistisk inden for dem?

Hvad koster en discovery-workshop, og hvad sparer den?

Prisen afhænger af varighed, antal deltagere fra leverandøren og hvor meget efterarbejde der følger med. Med typiske bureaupriser på 1.100–1.300 kr. i timen kan I regne prisen ud selv: to facilitatorer i to dage plus forberedelse og opsamling er hurtigt 40–50 timer. Tabellen viser de formater, vi oftest ser på markedet.

Sæt det over for, hvad en misforståelse koster. Bliver en funktion bygget forkert, fordi ingen spurgte økonomiafdelingen, skal den designes om, bygges om og testes igen. I et projekt til 400.000 kr. kan bare to eller tre af den slags fejl let koste mere end hele workshoppen. Den største besparelse er dog ofte de funktioner, I beslutter at lade vente. En grundig prioritering flytter næsten altid en betydelig del af ønskelisten til en senere version. Læs mere om at lægge et realistisk budget til et IT-projekt.

Hvem skal deltage i en discovery-workshop?

Den rolle, der oftest mangler, er den daglige bruger. Ledelsen kender målet, men det er medarbejderen ved skranken eller i bilen, der ved, hvorfor det nuværende system bliver omgået med post-its. Sørg også for, at leverandøren stiller med de mennesker, der faktisk skal bygge løsningen. En workshop holdt af en sælger, der bagefter overleverer til et andet team, mister meget af sin værdi.

Hvordan ser agendaen for en discovery-workshop ud?

Dag 1: mål, brugere og arbejdsgange

Start med målet. En god øvelse er at skrive den overskrift, I gerne vil kunne sætte på en intern nyhed om et år, for eksempel “Kundeservice har halveret antallet af opkald om ordrestatus”. Derefter tegnes brugertyperne op med deres vigtigste opgaver. Resten af dagen går med at gennemgå de nuværende arbejdsgange på en lang tidslinje på væggen eller whiteboardet. Det er her, de vigtigste smertepunkter dukker op: dobbeltindtastning, manglende overblik, ventetid på svar.

Dag 2: løsning, prioritering og plan

Anden dag handler om løsningen. Designeren skitserer de vigtigste skærme sammen med deltagerne, og funktionerne skrives som brugerhistorier i formatet “Som kunde vil jeg se min ordrestatus, så jeg ikke behøver at ringe”. Integrationerne tegnes som et kort: hvilke systemer, hvilke data, hvilken retning. Til sidst prioriteres alt med MoSCoW-metoden i must, should, could og won’t this time, og risici får hver en plan for, hvordan de testes tidligt.

Hvilke leverancer skal I have efter en discovery-workshop?

• Et kort dokument med mål, succeskriterier, budget og tidsramme.
• Beskrivelse af brugertyper og deres vigtigste opgaver.
• Kort over nuværende arbejdsgange med smertepunkter markeret.
• Prioriteret liste over brugerhistorier med acceptkriterier for de vigtigste.
• Skitser eller wireframes af de centrale flows.
• Integrationskort med systemer, data og ansvarlige.
• Risikoliste med en plan for hver risiko.
• Afgrænsning af første version og en grov plan for de næste.
• Et estimat eller et tilbud til fast pris på første version.

Har I brug for at teste et flow på rigtige brugere, før I går videre, kan skitserne bygges om til en klikbar prototype. Den kan vises til kunder og medarbejdere på få dage, og det er den billigste måde at fange fejl i et flow på.

Discovery-workshop eller kravspecifikation: hvad skal I vælge?

Mange kombinerer de to: I skriver en kort kravspecifikation med mål og vigtigste behov, og workshoppen bruges til at skærpe og prioritere den. Vores skabelon til kravspecifikation er lavet til netop det, og den er et godt forarbejde til workshoppen.

Regneeksempel: kundeportal for en installatørvirksomhed

Forestil jer en installatørvirksomhed med 25 medarbejdere, der vil have en kundeportal. Tallene er et eksempel. Ønskelisten fra ledelsen har 40 punkter. På en todages workshop viser gennemgangen af arbejdsgangene, at to tredjedele af de opkald, kundeservice får, handler om to ting: hvornår montøren kommer, og hvor fakturaen er. Prioriteringen ender med 22 must-funktioner, og flere af de oprindelige ønsker, blandt andet en chat og et loyalitetsprogram, flyttes til version to. Første version bliver dermed lille nok til en af de faste pakker, og den kan lanceres på en brøkdel af den oprindelige tid.

Hvordan forbereder I jer til en discovery-workshop?

1. Udnævn én beslutningstager, og aftal hvem der har det sidste ord.
2. Skriv målet ned i én sætning, og hvordan I vil måle det.
3. Saml eksisterende materiale: regneark, skemaer, skærmbilleder og statistik.
4. Lav en liste over systemer, løsningen skal tale med, og hvem der ejer dem.
5. Tal med 3–5 brugere eller kunder inden workshoppen, og tag noter med.
6. Afklar budgetrammen, også selv om den er foreløbig.
7. Sørg for, at aftalen sikrer jer ejerskab til alle resultater.
8. Book lokaler og kalendere for alle deltagere i god tid.

Er idéen helt ny, så start et skridt tidligere og valider idéen med samtaler og en landingsside, før I investerer i en workshop. Så går workshoppen med at forme løsningen frem for at diskutere, om problemet findes.

Hvornår har I brug for en stor discovery, og hvornår er et kort møde nok?

En fuld discovery betaler sig, når der er flere brugertyper, flere afdelinger med hver deres ønsker, integrationer til systemer, I ikke selv kontrollerer, eller når budgettet er stort nok til, at en fejl gør ondt. En hjemmeside eller en afgrænset app med en klar opgave kan derimod afklares på et enkelt møde. Når vi laver et tilbud til fast pris, gennemgår vi de samme spørgsmål i let form: hvem bruger løsningen, hvad skal den kunne, og hvilke systemer skal den tale med. Det er sådan, vi kan levere et skriftligt tilbud inden for 24 timer. Beskriv jeres projekt her, så vurderer vi også, om en større discovery giver mening for jer.