Ändringar i projektet – hantera scope creep utan konflikt
Av CodexierPublicerad 5 min läsning
Varje webb- eller mjukvaruprojekt ändrar form under resans gång, eftersom kunden ser det verkliga resultatet och förstår det bättre än briefen. Det är sunt. Det som gör det till konflikt är när ändringarna är osynliga: leverantören tar några på sig, ogillar resten, och slutfakturan eller den missade deadlinen landar som en överraskning. En rutin för ändringar gör varje ändring synlig, prissatt och beslutad, och den tar fem minuter per ändring.
Därför växer omfattningen
Omfattningen växer av tre skäl som inte har med dåligt uppförande att göra. Briefen skrevs innan kunden sett något, så den beskrev en gissning. Intressenter som inte var med på uppstarten kommer till första granskningen med egna krav. Och små önskemål känns gratis att be om och pinsamma att ta betalt för, så de samlas i tysthet tills leverantörens timmar är slut. Att förstå detta ändrar tonen: ett ändringsönskemål är ingen anklagelse, det är bokföring.
Definiera omfattningen tydligt
Man kan inte hantera ändringar av något som aldrig fastställdes. Omfattningen måste vara konkret nog för att båda sidor ska kunna peka på den och säga om ett önskemål ligger innanför eller utanför.
- Lista leverablerna: vilka sidor, vilka funktioner, vilka integrationer, vilka språk, med en mening acceptanskriterier för var och en.
- Lista det som uttryckligen är undantaget, särskilt sådant som diskuterades och ströks; det är det första som smyger sig tillbaka.
- Ange antalet revisionsrundor som ingår per leverabel och vad en runda innebär.
- Ange vem på kundsidan som får godkänna ändringar, så att önskemål från en kollega inte blir arbete av bara farten.
För ett paket till fast pris, som vår lansering av företagshemsida, är den här listan själva paketbeskrivningen, vilket är ett skäl till att fasta priser minskar konflikter: omfattningen är offentlig innan någon skriver på.
En logg för ändringar
Loggen är ett delat dokument, ett kalkylblad eller en tavla, som båda sidor kan se när som helst. Varje önskemål får en rad. Formatet betyder mindre än disciplinen att varje önskemål hamnar där, även de leverantören väljer att göra gratis.
| Kolumn | Vad som står där | Därför |
|---|---|---|
| Nummer och datum | Löpande, med vem som bad om det | Gör önskemålet refererbart i varje senare samtal |
| Beskrivning | En eller två meningar om vad som önskas och varför | Varför-delen avslöjar ofta ett billigare sätt att möta behovet |
| Uppskattning | Timmar eller kostnad, och effekten på deadline | Kunden beslutar med riktiga siffror |
| Beslut | Godkänt, avböjt eller uppskjutet, av vem, vilket datum | Ingen minns senare ett muntligt ja |
| Status | Ej påbörjat, pågår, klart, verifierat | Visar kunden vad godkännandena har blivit |
Ett önskemål leverantören tar på sig utan kostnad hamnar ändå i loggen med uppskattning noll. Det dokumenterar välviljan och visar mönstret om små gratisjobb hopar sig.
Uppskatta och godkänn ändringar
Uppskattningar av ändringar ska vara snabba och ärliga snarare än exakta. Ett svar samma dag i form av ett intervall, med effekten på tidplanen tydligt angiven, är det som låter kunden besluta medan önskemålet fortfarande är färskt. Bunta små önskemål i en veckovis omgång så att ingen sida lägger mer tid på rutinen än på arbetet. Godkännandet måste komma från den namngivna personen, skriftligt, innan arbetet börjar; ett svar i loggen eller ett mejl räcker. Och var tydlig med vad som händer med deadline: en ändring som godkänns efter halvtid flyttar den nästan alltid, och att säga det vid godkännandet undviker grälet vid leveransen.
I ett projekt till fast pris är ändringen en separat liten beställning med eget pris; i ett projekt på löpande räkning är den en justering av budgeten. I båda fallen ser kunden den löpande summan av godkända ändringar vid varje granskning. Våra egna betalningsvillkor för ändringar beskrivs i guiden om förskott och betalningsvillkor.
Säg senare i stället för nej
De flesta ändringsönskemål är bra idéer vid fel tidpunkt. Att avböja dem skapar friktion; att ta dem på sig skapar överdrag. Det tredje svaret är att skjuta upp: lägg önskemålet på en lista för fas två med sin uppskattning, leverera den överenskomna omfattningen på det överenskomna datumet, och gå sedan igenom listan med fräscha ögon. Hälften kommer inte längre att kännas nödvändig när sajten eller systemet är live, och den andra hälften blir ett rent, prissatt andra projekt i stället för ett utdraget första. Det är också det ärliga svaret till en kund som frågar om de ska lägga till funktioner nu: oftast inte; lansera först, besluta sedan utifrån verklig användning. Ett kostnadsfritt samtal innan ett projekt startar är där vi sätter upp den här rutinen, och paketpriserna finns på prissidan.
Vanliga frågor
Är inte en rutin för ändringar för byråkratisk för ett litet projekt?
Ett delat kalkylblad med fem kolumner är hela rutinen, och varje post tar några minuter. Små projekt drabbas mest av scope creep eftersom de har minst marginal, så rutinen betyder mer där, inte mindre.
Vad gör jag om leverantören hävdar att något självklart är en ändring?
Gå tillbaka till omfattningslistan och acceptanskriterierna. Är punkten underförstådd i en leverabel, som ett formulär som faktiskt skickar mejl, ingår den. Är listan tyst är det en verklig lucka, och det rättvisa utfallet är oftast att dela kostnaden. En tydlig omfattning från början förebygger de flesta av dessa.
Kan ändringar vara gratis?
Ja, och bra leverantörer tar små ändringar på sig. Logga dem ändå med uppskattning noll. Loggen visar då både välviljan som getts och punkten där små ändringar blivit en verklig kostnad som behöver diskuteras.
Startar ni ett projekt och vill ha ändringsrutinen på plats från dag ett?
Ta med er brief eller offerten ni fått. På femton minuter kan vi kontrollera om omfattningen är definierad väl nog för att hantera ändringar, och visa loggen vi använder i varje projekt.
Boka ett kostnadsfritt 15-minuterssamtal