I år har vi varit verksamma inom branschen i ett decennium, vilket innebär att vi har varit delaktiga i hundratals webbprojekt. Under dessa år har vi lärt oss mycket bland annat hur misslyckade webbprojekt kan undvikas.
En viktig del i detta är att säkerställa vad en beställare bör veta innan beställning. Detta blogginlägg kommer därför behandla de fem vanligaste misstagen som vanligtvis görs och leder till dyrare och försenade webbprojekt.
Felaktig förstudie
Det är många som hävdar att avsaknaden av ett förarbete är en anledning till misslyckade webbprojekt. Men vi menar snarare att det är felaktiga förarbeten som leder till misslyckade webbprojekt.
Det är vanligt att beställaren själv framställer en kravspecifikation, dock är det svårare att framställa en korrekt kravspecifikation än vad man kan tro. Det krävs kunskap inom både kravhantering och webbprojekt för att inkludera samtliga viktiga funktionella och icke-funktionella krav.
Utöver en korrekt skriven kravspecifikation är även ett tekniskt lösningsförslag viktigt. Lösningsförslaget ska framställas på ett systematiskt sätt där olika webbtekniker jämförs och utvärderas utifrån hållbarhet, flexibilitet och kostnadseffektivitet. Därefter kan en tidsplan och budget estimeras, annars riskeras estimatet att bli tomma gissningar.
Brist på engagemang
Det är vanligt att företag beställer webbprojekt och sedan endast har ett fåtal avstämningar innan färdigställning och lansering. Detta leder ofta till att projektet måste omarbetas, blir försenat och dyrare än väntat.
Ett webbprojekt är beroende av regelbundna avstämningar för att säkerställa en bra leverans eftersom en kravspecifikation omöjligt kan inkludera varje detalj av den tilltänkta webblösningen. Genom workshops och kontinuerliga avstämningsmöten måste detaljer och eventuella missförstånd diskuteras för att sedan korrigeras.
Därför måste du som beställare reservera tid för oväntade problem och beslut. Under projektet bör det dessutom avsättas tid för att testa webblösningen i flera olika omgångar. Självklart ska detta även göras av leverantörer under projektets gång. Men för att du som beställare ska känna dig trygg i att utvecklingen av webblösningen lever upp till dina förväntningar så krävs stort engagemang.
Vi har skrivit ett inlägg om hur mycket engagemang som krävs av en beställare av webbprojekt, du kan läsa det här.
Marginaler i tidsplan
Om en leverantör offererar två månaders arbete för utveckling av din tilltänkta webblösning, betyder inte detta att webblösningen är färdig två månader efter projektstart. Du bör alltid räkna med långa ledtider under projektet som kan bero på många olika faktorer. Vanliga anledningar till att ledtider uppstår är att det behövs underlag från leverantörer av tredjepartssystem, korrigeringar efter testning eller eventuella tekniska problem.
I webbprojekt finns det många olika risker som kan innebära potentiella förseningar, därför bör det alltid finnas goda marginaler under projektets gång. Som tumregel bör antalet arbetstimmar dubblas för att få fram en rimlig tidsplan. Detta innebär att om webbprojektet kräver 320 arbetstimmar, bör det sättas en deadline 640 arbetstimmar efter projektstart vilket motsvarar 80 arbetsdagar (3,8 månader).
Det är viktigt att säkerställa att det finns goda tidsmarginaler mellan färdigställandet av webbprojektet inför lansering och den faktiska lanseringsdagen. På så sätt har du god tid att utvärdera webblösningen och planera inför lansering. Således kan du undvika att aktiviteter som är beroende av webblösningens lansering behöver skjutas upp såsom marknadskampanjer eller personal som ska arbeta med webblösningen.
Dessutom bör du alltid räkna med att kravspecifikationen förändras under projektets gång. Detta beror på att en webblösningens funktionalitet och utseende kan vara svårt att bestämma från start. De eventuella ändringarna kommer även påverka projektets budget och tidsplan, dock kan stora ändringar undvikas genom ett ordentligt förarbete.
Är du intresserad av att läsa om hur du undviker misslyckade webbprojekt? Läs vårt blogginlägg här.
Underhållskostnader
Det är vanligt att företag blir förvånade över att en webblösning kräver högre underhållskostnad än förväntat. Många inkluderar endast hostingkostnader och tror att det är den enda löpande kostnaden efter projektavslut. Men sanning är att alla webblösningar behöver kontinuerligt underhåll, detta kan handla om allt ifrån buggfixar, uppdateringar och eventuell vidareutveckling.
Faktum är att webbteknik alltid behöver uppdateras och buggar alltid kommer att uppstå, även i välskriven källkod. I detta stadie är det viktigt att se över ditt supportavtal med leverantören.
Vanligtvis kräver en hemsida underhållskostnader på ett par tusen per månad, medan ett webbsystem kan kosta flera tusen i månaden. För att budgetestimeringen ska bli så pass korrekt som möjligt, bör dessa kostnader finnas i budgetkalkylen redan vid beställning av webbprojekt.
Enhetsanpassning
Det är vanligt att beställare förväntar sig att den tilltänkta webblösningen ska fungera felfritt i samtliga mobila enheter, dock bör du aldrig förvänta dig detta. Detta beror på att det inte finns någon leverantör som lovar eller kan leva upp till en webblösning som fungerar optimalt på alla enheter.
Vanligtvis nämner inte leverantören vilka enheter, webbläsare och operativsystem som webblösning kommer stödja, men du bör inte räkna med alla. Detta beror på att det är ett otroligt tidskrävande arbete att testa i så många enheter, då vi pratar om minst hundratals olika. Inte ens ett simuleringsprogram såsom Browserstack har stöd för alla dessa enheter.
Vår rekommendation är att alltid utgå ifrån de mest populära enheterna, webbläsarna och operativsystemen. Genom en enkel Google-sökning kan du se vilka som är mest populära, för att sedan diskutera med din leverantör vilka enheter som bör stödjas.
Bli inte avskräckt om din webblösning inte stödjer många enheter, din webblösning kommer se bra ut och fungera väl i fler än dessa. Dock kan detta inte garanteras och just därför är förvaltningsavtalet extra viktigt, eftersom felaktigheter såsom enhetsanapssning kan uppdagas efter lansering och korrigeras därefter.
Har du frågor och funderingar gällande hur du kan undvika dessa misstag? Kontakt oss, så hjälper vi dig vidare!