Så avgränsar du ett pilotprojekt för programvara

Låt syftet sätta gränsen – inte tvärtom

Boverket: en detaljplan får inte omfatta ett större område än vad syftet och genomförandetiden kräver, och inte vara mer detaljerad än syftet kräver (PBL 4 kap. 32 §). Samma princip gäller piloten. Bestäm först vad ni ska lära er eller bevisa, och låt syftet styra hur många processer, användargrupper och integrationer som får plats.

Programvara har tre format, och syftet avgör vilket. En Proof of Concept är ett inledande experiment som ger ja eller nej på om en teknisk lösning är genomförbar. En prototyp är en enkel modell av hur produkten ska se ut och fungera, avsedd för användartester. En Minimum Viable Product är den första körbara versionen, som ger värde i begränsad form och byggs vidare med användarfeedback.

Skriv syftet som en fråga som går att besvara, inte som ett område. Då tvingas ett ja, ett nej eller ett mätvärde fram när piloten är slut.

Frågorna avgör om piloten är lyckad. En PoC besvarar om modellen fungerar med er data, om tekniken går att integrera i den befintliga miljön, vilken plattform som passar bäst – moln, hybrid eller lokal drift – och om datan är tillräckligt strukturerad för tillförlitliga svar. Svaren är i sig pilotens resultat.

Generativ AI är ett konkret exempel. En PoC är då ofta en mini-applikation som med etablerade LLM som ChatGPT, Claude eller Dall-e programmatiskt löser en definierad uppgift.

Inför starten kan en mall för AI-mognadsbedömning i Word eller Google Docs användas för att bedöma rätt startläge.

Gå igenom varje önskad del och stryk allt som inte behövs för att besvara frågan – det som återstår är pilotens omfattning. Krav och funktioner som inte tjänar syftet hör inte hemma i den här fasen, hur nyttiga de än är i ett färdigt system.

Håll formaten isär i syftet. En PoC ger insikt och lärdomar, inte en färdig applikation; först med en MVP blir säkerhet, integrationer, skalbarhet och prestanda produktionsredo. Ett syfte som lovar ett användbart system men beskriver en PoC är en gräns som spricker i efterhand.

Skillnader mellan PoC, prototyp och MVP

Avgränsa i två riktningar: bredd och djup

Boverket beskriver ett planområde i två riktningar: det ska avgränsas horisontellt och får även avgränsas vertikalt (Boverkets föreskrifter 2020:5, 3 kap. 1 §). Utan vertikal avgränsning gäller planområdet i princip obegränsat i höjdled. Samma mekanik gäller en pilot.

Den horisontella gränsen svarar på vad som omfattas i bredd: vilka delar av verksamheten, vilka användargrupper och vilka datamängder. Den vertikala gränsen svarar på hur långt in i kedjan piloten går – från inläsning hela vägen till beslut, eller bara fram till en första prototyp som någon annan tar vidare.

Saknas den vertikala gränsen fortsätter piloten i praktiken obegränsat framåt: den omfattar allt som kommer efter.

Översatt till programvara är den horisontella gränsen vilka system, integrationer, användargrupper och datamängder som ingår. Den vertikala gränsen är hur långt in i kedjan piloten går: ett ja eller nej i test- eller labbmiljö, eller en körbar version i produktionsnära drift med säkerhet, integrationer och skalbarhet.

Konkreta test att avgränsa till: en implementation som kräver hög genomströmning av data för att verifiera att den valda arkitekturen – till exempel en molntjänst – klarar det, eller att ett ramverk eller en tredjepartsintegration fungerar som ni önskar.

Gränsen måste gå att peka på, inte bara beskrivas i ord; Boverket kräver att avgränsningen ska kunna redovisas tydligt. Lista vilka register, system, processer och roller som ingår – och hur många. Ett antal går att redovisa och följa upp; formuleringar som ”några handläggare” eller ”de viktigaste flödena” gör det inte.

Bestäm också vilken driftsmiljö piloten får använda – moln, hybrid eller lokal drift – och hur många tredjepartsintegrationer som får ingå. Det är antal som går att redovisa och följa upp, till skillnad från en beskrivning i ord.

Formulera uppdraget så att det går att följa upp

KB-utredningen visar hur ett uppdrag kan se ut: genom beslut den 19 december 2002 bemyndigade regeringen chefen för Utbildningsdepartementet att tillkalla en särskild utredare (dir. 2002:156). Med stöd av bemyndigandet anställdes departementsrådet Gunnel Stenqvist den 7 januari 2003 som särskild utredare, och den 1 april 2003 anställdes en biträdande sekreterare.

Den 2 oktober 2003 beslutade regeringen genom tilläggsdirektiv att förlänga utredningstiden från den 1 oktober till den 31 december 2003. Betänkandet överlämnades i december 2003.

KB-utredningens fyra fält fungerar som avgränsningsmall även för en programvarupilot: bemyndigande, direktiv, ledning och redovisningsdatum. Lägg till tre programvarunära fält: leveransformat, driftsmiljö och en uttrycklig gräns mot vad som inte är en färdig applikation.

Skriv pilotuppdraget med samma fyra fält. Först ett bemyndigande: vem får fatta vilka beslut, vilken budget och vilka personresurser piloten får använda. Sedan ett direktiv: vad som ska undersökas eller byggas, och vad som uttryckligen inte ingår. Därefter en utsedd ledning – en namngiven ansvarig, plus eventuellt sekreterar- eller projektstöd. Till sist en tidpunkt för redovisning, med datum.

Sätt en budget i proportion till vad piloten sparar. En avgränsad PoC ryms inom en begränsad budget och genomförs under kort tid; PoC-tiden mäts i veckor snarare än månader. En MVP utvecklas iterativt med användarfeedback och kräver en annan budget.

Konkreta nivåer: en typisk PoC landar på 30 000–60 000 kr och levereras inom 1–2 veckor, med en rapport med resultat och rekommendation för nästa steg. Var i spannet ni landar beror främst på hur tillgänglig och strukturerad er data är, och hur snävt användningsfallet kan avgränsas.

Ett ifyllt uppdrag kan se ut så här: bemyndigande – en budget på 30 000–60 000 kr och en namngiven ansvarig; direktiv – undersök om en AI-modell kan förutsäga kundbeteenden, inget annat; ledning – den ansvarige plus projektstöd; redovisning – ett fast datum.

KB:s förlängning var ett formellt tilläggsdirektiv med ett nytt datum – inte en glidande överenskommelse i korridoren. Inför samma regel i piloten: en förlängning beslutas av den som gav uppdraget. Den dokumenteras med ett nytt slutdatum. Då syns det i efterhand om det var tiden eller avgränsningen som brast.

Typiska kostnader och tider för olika pilotformat

Tidsram för en typisk PoC-pilot

Roller, kompetens och externa experter

KB-utredningen hade tre arbetsgrupper knutna till sig, och experter från berörda myndigheter och organisationer bistod utöver dem. Modellen passar en pilot: en kärna som äger arbetet och experter som kopplas in på avgränsade frågor och sedan lämnar.

Upphandlingsmyndigheten beskriver att beställaren formar sin projektgrupp utifrån förstudien och insikter från arbetet i tidiga skeden, och att ett byggprojekt kräver olika roller och kompetenser. Intern kompetens kan behöva förstärkas med extern kompetens för att ta fram underlag.

Lista pilotens roller – beställare, projektledning, domän- och användarkompetens, utveckling, test, juridik, informationssäkerhet, tillgänglighet – och markera vad som finns internt och vad som ska köpas in.

Datakompetens hör till kärnan. PoC:n ska svara på om er data är tillräckligt strukturerad och om modellen fungerar med den; utan den kompetensen går frågan inte att besvara.

Markeringen är i sig ett avgränsningsbeslut. Allt som ska upphandlas tar tid innan arbetet kan börja, och varje extern roll behöver ett mandat som ryms inom uppdraget. Lägg hellre till tid i uppdraget än roller som ingen hunnit upphandla.

Räkna in kompetens om den valda driftsmiljön och om de integrationer som ingår; moln, hybrid och lokal drift ställer olika krav. Behöver kompetensen köpas in gäller reglerna om offentlig upphandling, och Konkurrensverket har i ställningstagande 2024:1 uttalat sig om kostnadsfri tillgång till upphandlingsdokument.

Från förstudie till konkretiserade projektmål

Upphandlingsmyndigheten beskriver projekteringsskedet så att förstudien och andra handlingar ska konkretiseras och utgöra underlag för det fortsatta arbetet, och att projektmål – till exempel hållbarhet och gestaltning – ska föras vidare till de konsulter som ska utföra arbetet. I en pilot är det i den övergången som avgränsningen antingen följer med eller tappas.

Gör avgränsningen till en överenskommelse i stället för en anteckning. Skriv in den i uppdragsbeskrivningen till dem som ska utföra arbetet och låt den gå igen i aktivitets- och tidsplanen.

Upphandlingsmyndigheten framhåller att framgångsrik strategisk planering bygger på en väl genomarbetad aktivitets- och tidsplanering, och att planeringen har stor betydelse för projektmedlemmarnas arbetsklimat. Står målen bara i förstudien är det ingen som mäter dem i genomförandet.

Övergången från PoC till MVP är den mest utsatta punkten. En vanlig missuppfattning är att en avslutad PoC innebär en färdig applikation; oftast saknar den skalbar arkitektur, säkerhetslösningar, integrationer och prestanda för verklig användning.

Sätt ord på vad en MVP ska leverera: den första körbara versionen, en fungerande arkitektur som går att bygga vidare på och funktioner fokuserade på kärnnyttan. PoC:n svarar på om det kan fungera; MVP:n svarar på hur det fungerar när ni använder det.

Beskriv båda utfallen i förväg. Svarar PoC:n ja går arbetet vidare mot en MVP; svarar den nej behöver ni backa bandet och hitta en annan lösning. Var tydlig från start med vad som ska levereras och varför, så att avgränsningen följer med in i genomförandet.

Skriv ner vad som ligger utanför

En lista över vad som inte ingår är lika viktig som kravlistan. Boverket kräver att avgränsningen ska gå att redovisa tydligt – det gäller även en pilot. Finns gränsen bara i projektledarens huvud går den inte att redovisa, varken till styrgruppen under arbetet eller vid en efterhandsgranskning.

Konkretisera gränsdragningen mot tre saker: angränsande system och register som piloten inte rör, angränsande processteg före och efter som ligger utanför, och pågående initiativ på samma område som ni avstår från att överlappa. KB-utredningen redovisade berörda myndigheter och pågående utredningar som en del av sitt arbete.

Fyra saker hör ofta hemma utanför en programvarupilot: skalbar arkitektur, säkerhetslösningar, integrationer och prestanda för verklig användning. Det är just de delar en PoC inte levererar.

Design- och affärsbiten kan också vänta. De utvecklas först när PoC:n visat att den tekniska lösningen är genomförbar.

Skriv också in vilken data piloten får röra. En PoC körs i test- eller labbmiljö, medan en MVP arbetar produktionsnära med säkerhet, integrationer och skalbarhet – gränsen mellan dem är ett avgränsningsbeslut, inte en teknisk detalj.

Tillgänglighet och användarnas förutsättningar

Tillgänglighetsfunktioner är inbyggda i program och format och förutsätts därför lätt vara kända.

Bestäm tidigt vilka tillgänglighetskrav som ingår i just den här piloten och vilka som medvetet skjuts till en senare fas. Krav som påverkar datamodell, gränssnittsstruktur och innehållsformat behövs redan nu, eftersom de är kostsamma att lägga på i efterhand; detaljer som rör enskilda vyer kan komma senare. Skriv in båda listorna i avgränsningen, så att det som skjuts framåt är ett dokumenterat beslut och inte en försummelse.

Formatkraven är reglerade. Lagen om den offentliga sektorns tillgängliggörande av data genomför EU:s öppna data-direktiv och trädde i kraft den 1 augusti 2022; den ställer bland annat krav på i vilka format olika slag av data ska göras tillgängliga.

Eftersom funktionerna ligger i programmen och formaten behöver den som skriver information veta hur de används och hur informationen konverteras vidare. Det är en avgränsningsfråga: tas den kompetensen med i piloten, eller skjuts den till en senare fas?

Följ upp och justera gränsen under resan

Bestäm i förväg vilka mått som visar att piloten håller sig inom ramen – antal processer, användare, systemkopplingar, ledtid, kostnad – och vid vilka tillfällen de ska mätas.

Lägg fast vad som räknas som ett lyckat resultat innan mätningen börjar: ett ja eller nej på frågan ni ställde, och ett svar på om lösningen är värd att bygga.

Programvarunära mått att stämma av: prestanda, genomströmning av data, robusthet och tillförlitlighet samt datakvalitet. Har piloten formen av en PoC ska den dessutom ge ett enkelt ja eller nej – det svaret är i sig det viktigaste resultatet.

Skilj på insikt och körbar version i uppföljningen. En PoC ska lämna lärdomar om vilken väg som fungerar och vilka risker som finns; en MVP ska vara en version som används i verkligheten och kan byggas vidare på. Mätningen visar om gränsen var satt vid det ena eller det andra.

Stäm av vid de givna tillfällena i stället för löpande. När mätningen visar att gränsen behöver flyttas – fler användare, en integration till, en förlängd period – besluta skriftligt, som med KB-utredningens tilläggsdirektiv: ett nytt beslut och ett nytt datum. Då syns det i efterhand om ändringen berodde på att avgränsningen var fel satt eller på att syftet förändrades under resan.

Ett avgränsat test kan visa att tekniken fungerar men att kostnaden för att driva lösningen i produktion inte är motiverad. Utan den insikten bygger ni vidare på något som blir dyrt att förvalta. Låt därför uppföljningen omfatta både teknisk genomförbarhet och affärsnytta.

En PoC på några veckor kostar en bråkdel av en fullskalig utveckling.