Byta byrå mitt i projektet
Av CodexierPublicerad 5 min läsning
Att byta byrå halvvägs genom ett hemside- eller appprojekt känns som ett nederlag, och det kostar tid. Men att stanna hos en leverantör som missar varje deadline eller slutat svara kostar mer. Skillnaden mellan ett rörigt byte och ett kontrollerat är ordningen: säkra åtkomst och material innan något annat, dokumentera var projektet står, ge den nya leverantören ordentligt underlag och avsluta det gamla avtalet snyggt. Här går vi igenom den ordningen.
När det är rätt att byta
En del problem går att lösa i ett rakt samtal: otydliga prioriteringar, en ny kontaktperson eller en omfattning som växt utan att någon märkt det. Prova det först, skriftligt, med konkreta problem och ett datum. Händer ingenting är det du redan betalat inget skäl att stanna.
| Signal | Går det att lösa? |
|---|---|
| Missade deadlines med förklaringar och nya planer | Ofta; förhandla om planen |
| Missade deadlines utan förklaring, gång på gång | Sällan |
| Inga svar på flera veckor | Sällan |
| Kvalitetsproblem som kommer tillbaka efter rättningar | Sällan |
| Oenighet om omfattningen | Ofta; klargör med en skriftlig process för ändringar |
Säkra åtkomst och material
Det viktigaste steget sker i det tysta, innan något meddelas. Kontrollera att det är ni, inte byrån, som äger eller har administratörsåtkomst till allt projektet bygger på. Guiden om vem som äger hemsidan förklarar varför det spelar roll.
- Domän: registrerad i ert företags namn, med egen inloggning hos registraren
- Hosting och servrar: kontot i ert namn, eller åtminstone er administratörsåtkomst
- Kodförråd: ägar- eller administratörsåtkomst till projektet i GitHub, GitLab eller Bitbucket
- Publiceringsverktyg och adminpaneler: ett eget administratörskonto
- Tredjepartstjänster: analys, Search Console, betalleverantörer, mejlutskick, Google Företagsprofil
- Designfiler: åtkomst till projektet i Figma eller motsvarande, inte bara exporterade bilder
- Inloggningsuppgifter sparade där ni har kontroll, till exempel i en lösenordshanterare
Dokumentera nuläget
Den nya leverantören behöver en ärlig bild. Be den avgående byrån om en skriftlig status och gör parallellt en egen lista. Där de två skiljer sig har du hittat riskerna.
- Vad som är klart, testat och godkänt
- Vad som är påbörjat men inte klart
- Vad som inte är påbörjat
- Kända fel och tillfälliga lösningar
- Miljöer: var den skarpa versionen, testversionen och utvecklingsversionen finns
- Integrationer och deras inloggningsuppgifter
- Vad som fakturerats och betalats, per delleverans
En kort teknisk genomgång av den nya leverantören, innan de lämnar pris, är värd att betala för. Kod som ser nästan klar ut kan vara bristfällig i grunden, och det är bättre att veta innan du skriver på.
Ge underlag till den nya leverantören
Ge det nya teamet allt: den ursprungliga kravspecifikationen och offerten, ändringsbeställningarna, statusdokumentet, åtkomst till koden och designen och en ärlig beskrivning av vad som gick fel. Att dölja konflikten hjälper ingen; den nya leverantören behöver veta vilka förväntningar som inte uppfylldes.
| Steg | Syfte |
|---|---|
| Teknisk bedömning av befintlig kod | Avgör om ni ska fortsätta, skriva om delar eller bygga om delar |
| Reviderad omfattning och plan | Skilj det som återstår från det som måste göras om |
| Fast pris eller uppskattning för resten | Först efter bedömningen |
| Tydliga villkor för ägande och åtkomst i det nya avtalet | Så att det här inte händer igen |
Räkna med en del omarbete. Få team kan ta över ett annat teams halvfärdiga kod utan att ändra delar av den, och en leverantör som lovar att inget behöver göras om har troligen inte tittat noga.
Avsluta det gamla avtalet
Läs villkoren för uppsägning innan du säger upp: uppsägningstid, betalning för utfört arbete och ägande av kod och design vid uppsägning. Betala för godkända leveranser, bestrid resten skriftligt och begär en slutlig överlämning av allt på åtkomstlistan. Håll en saklig ton; du kan behöva deras hjälp med en fråga senare.
- Säg upp skriftligt med hänvisning till avtalspunkten
- Lista vad du anser är levererat och vad du anser att du är skyldig
- Begär överföring av alla kvarvarande konton och filer till ett visst datum
- Kontrollera att byråns åtkomst tas bort efteråt
- Finns en verklig tvist om pengar eller rättigheter, ta hjälp av en jurist i stället för att trappa upp via mejl
När du inte ska byta, och hur vi hjälper
Är projektet några dagar från lansering och problemen kosmetiska kan det vara mindre riskabelt att slutföra med nuvarande leverantör och byta för underhållet efteråt. Att byta enbart på grund av priset lönar sig också sällan. När ett byte är rätt tar vi över halvfärdiga hemsideprojekt: först en teknisk genomgång, sedan en fast omfattning för att slutföra företagshemsidan. Se priser eller boka ett kort samtal och berätta om din situation.
Vanliga frågor
Kan den gamla byrån vägra lämna ut koden?
Det beror på avtalet. Står det att ni äger koden när den är betald har ni rätt till de delar ni betalat för. Är ägandet oklart, ta juridisk rådgivning innan du håller inne betalning eller trappar upp.
Blir kostnaden dubbel om vi byter?
Det kostar oftast mer, främst för den nya leverantörens bedömning och en del omarbete. Det är ändå ofta billigare än att fortsätta med en leverantör som inte levererar.
Ska den nya leverantören fortsätta på den gamla koden eller börja om?
Bestäm det efter en teknisk genomgång, inte före. Många projekt kan fortsätta med viss omskrivning; en del grunder är för svaga att bygga vidare på.
Hur undviker vi det här med nästa leverantör?
Ha alla konton i företagets namn från första dagen, betala mot godkända delleveranser och skriv in ägandet av kod och design i avtalet.
Fast i ett projekt som står still?
Beskriv var projektet står i ett kort samtal. Vi säger vad du ska säkra först och om det är rimligt att ta över.
Boka ett kostnadsfritt 15-minuterssamtal