· Projektbasen
”Ska projektet vara agilt eller traditionellt?” är ofta för stor som första fråga. Samma projekt kan innehålla ett lagkrav som inte är förhandlingsbart, en lösning som behöver prövas med användare och ett införandedatum som någon annan styr. En enda etikett säger inte hur de tre delarna ska hanteras.
Här får du Projektbasens eget fiktiva fall och beslutstest. Det hjälper dig att bestämma vad som ska låsas, vad som ska prövas tidigt och vad teamet får ändra inom tydliga gränser. Testet är ett arbetsunderlag, inte en standard eller ett kundfall.
Börja med vad ni behöver kunna lära er
Scrum Guide beskriver Scrum som ett ramverk för komplexa problem där resultat granskas och kommande arbete anpassas. Under en sprint ska målet skyddas, medan omfattningen kan förtydligas och omförhandlas när teamet lär sig mer. Det är alltså inte samma sak som att allt får ändras när som helst.
GOV.UK:s vägledning om discovery skiljer problemet från en förutbestämd lösning och rekommenderar att användarbehov, begränsningar och riskfyllda antaganden undersöks före byggbeslutet. Deras översikt över agila metoder säger också att flera metoder och tekniker kan kombineras när man förstår varför de används. Vägledningen gäller brittiska digitala tjänster; använd principerna som metodstöd, inte som svensk regel.
Tre frågor är därför mer användbara än metodetiketten:
- Vad vet vi tillräckligt mycket om för att fatta beslut nu?
- Vilket sent ändringsbeslut skulle bli dyrt, farligt eller rättsligt omöjligt?
- Vilken osäkerhet kan vi minska med ett litet prov innan vi binder hela budgeten?
Beslutstestet: kunskap nu och kostnad att ändra sent
Skriv projektets viktiga beslut som separata rader. Bedöm sedan två saker: hur starkt underlaget är i dag och vad en sen ändring skulle kosta i tid, pengar, risk eller förtroende. Tabellen är Projektbasens egen arbetsmodell.
| Underlag i dag | Kostnad att ändra sent | Arbetssätt för beslutet |
|---|---|---|
| Starkt | Hög | Baslinjesätt beslutet, dokumentera mandat och ändringsväg. |
| Svagt | Hög | Pröva antagandet tidigt innan ett stort åtagande görs. Sätt ett stopp- eller fortsättningsbeslut. |
| Svagt | Låg | Låt lösningen vara justerbar inom mål, kostnadsram och kvalitetskrav. Granska ofta. |
| Starkt | Låg | Välj den enklaste fungerande lösningen och undvik onödig metodadministration. |
Ett ”starkt” underlag behöver gå att peka på: lagtext eller beslut, verifierat avtal, användarstudie, tekniskt prov eller utfall från tidigare leverans. Att en senior person är säker är inte i sig samma sak som bevis.
Fiktivt fall: en bokningstjänst med både hårda gränser och öppen lösning
Ett projekt ska ersätta en intern bokningstjänst. Den beslutade kostnadsramen är 1 200 000 kr exklusive moms. Verksamheten behöver en användbar första version senast 30 november. Följande belopp och datum är fiktiva och inte marknadspriser.
| Beslut | Underlag och sen ändringskostnad | Hantering |
|---|---|---|
| Behörighet, tillgänglighet och lagring av personuppgifter | Kraven behöver verifieras av ansvariga roller. Fel sent kan stoppa lansering. | Fast kvalitetsgräns. Namnge kravägare och godkännandepunkt innan byggstart. |
| Vilket problem som ska lösas | Intervjuer visar långa ledtider, men orsaken är ännu inte bekräftad. | Tre veckors avgränsad undersökning med tydligt fortsättningsbeslut. |
| Exakt bokningsflöde | Två lösningar verkar möjliga och är billiga att prototypa. | Testa båda med användare innan full utveckling. |
| Integration med kalendersystemet | Teknisk genomförbarhet är okänd och kan bli dyr att ändra sent. | Gör ett tidigt tekniskt prov och få ett skriftligt integrationsbeslut. |
| Ordning på förbättringar efter första versionen | Nyttan blir tydligare först efter användning. | Håll ordningen justerbar och granska verkligt utfall vid varje beslutspunkt. |
Projektgruppen reserverar i sitt planeringsunderlag 180 000 kr för undersökning och tekniskt prov, 720 000 kr för första användbara versionen och 180 000 kr för införande och verifiering. Planerad kostnad är då 1 080 000 kr, vilket lämnar 120 000 kr oallokerat inom kostnadsramen. Det är inte en automatisk riskreserv, besparing eller tillåtelse att spendera. Okända integrationskostnader är fortfarande okända och behöver ett eget beslut.
Efter det tekniska provet visar ett verifierat estimat att integrationen kräver ytterligare 160 000 kr. Om övriga delar är oförändrade blir scenariot 1 240 000 kr, alltså 40 000 kr över ramen. Då behöver rätt beslutsfattare välja mellan mer budget, mindre omfattning, en annan lösning eller stopp. Att kalla projektet agilt löser inte avvikelsen.
Ett 25-minuters metodvalsmöte
Minut 0–5: formulera utfallet och gränserna
Skriv ett resultat som går att pröva: ”Behöriga medarbetare kan hitta och boka en ledig tid utan manuell dubbelregistrering.” Lista sedan rättsliga krav, kvalitetskrav, kostnadsram, sista användbara datum och vem som får ändra dem. Blanda inte ihop önskad lösning med obligatorisk gräns.
Minut 5–12: sortera fem till åtta beslut
Använd de två axlarna i beslutstestet. Skriv vilket underlag som saknas. Om gruppen inte kan bedöma en sen ändringskostnad är även det en osäkerhet som behöver ägare och kontrolltid.
Minut 12–18: välj kontrollmekanism per beslut
- Baslinje och ändringskontroll för beslut som måste vara stabila.
- Tidigt prov för dyra antaganden med svagt underlag.
- Kort återkopplingscykel för lösningsdetaljer som får utvecklas med ny kunskap.
- Flödesstyrning när många oplanerade ärenden behöver prioriteras löpande.
Använder ni Scrum behöver ni använda Scrum som ramverk, inte bara döpa möten till sprintar. Scrum Guide är tydlig med att delar kan användas separat men då är resultatet inte Scrum. Skriv därför vad ni faktiskt gör och varför.
Minut 18–25: bestäm nästa bevis och nästa beslut
Varje osäker rad får en ansvarig, en leverans och ett datum. Exempel: ”Teknikansvarig visar senast 25 september att kalenderintegrationen kan skapa, ändra och avboka en testbokning. Styrgruppen beslutar därefter om byggstart och kostnadsram.”
Dokumentera alternativet utan automatisk vinnare
Öppna Beslutsmatrisen. Verktyget jämför två alternativ men rangordnar dem inte åt dig. Skriv frågan ”Ska vi binda hela lösningen nu eller finansiera ett avgränsat prov först?” och ange kostnadsram, slutdatum och obligatoriska krav som kriterier.
Beskriv för varje alternativ resultat, resursbehov, tid, beroenden, osäkerheter och nästa kontroll. Lämna rekommendationen öppen om integrationsunderlaget saknas. Underlaget finns bara i sidan medan du arbetar; kopiera eller ladda ned texten innan du lämnar den.
När en metodförändring påverkar kostnaden kan du visa den i Projektprognosen. Lägg ett obeslutat kostnadsförslag som scenario, inte i huvudprognosen, tills rätt beslut finns. Betan lagrar en arbetsyta lokalt i webbläsaren och skickar inget automatiskt.
Fortsätt med guiden om hur kostnad, budget och ändringsbeslut hålls isär. Metodvalet bestämmer hur ni lär och styr arbetet; det upphäver inte ekonomiskt ansvar eller beslutsmandat.
Kontrollfrågan att ta med
Fråga inte bara ”vilken metod använder vi?” Fråga: Vilka beslut måste vara stabila, vilka antaganden måste prövas före åtagande och vem får ändra resten? Svaret går att omsätta i styrning. Etiketten ensam gör det inte.
Källor och redaktionell information
The 2020 Scrum Guide, GOV.UK: How the discovery phase works och GOV.UK: Agile methods – an introduction kontrollerades 12 september 2026. GOV.UK-sidorna var senast uppdaterade 21 juni 2021 respektive 27 juli 2016. Källorna stöder principerna om empiriskt lärande, tydliga mål, problemförståelse, begränsningar och medvetet metodval; de stöder inte Projektbasens fyrfältare, mötestid, fiktiva belopp eller rekommendation i ett verkligt projekt. Artikeln är framtagen med AI-stöd. Ingen personlig experterfarenhet, genomfört kundprojekt eller mänsklig granskning påstås.