Hur undviks misslyckade webbprojekt?

Den största anledningen till att webbprojekt misslyckas beror på ett bristande förarbete som resulterar i en felaktigt skriven kravspecifikation.

Visserligen finns det verksamheter som själva genomför ett förarbete innan projektstart, för att sedan ha det som underlag vid beställning av webbprojekt. Den så kallade kravspecifikationen ingår då i ett förfrågningsunderlag som leverantörens offert baseras på.

Kravspecifikationen är tyvärr oftast bristfälligt skriven och saknar väsentliga krav som borde ingå i en webblösning, exempelvis dess prestanda och säkerhet. En professionell leverantör kan se att det behövs en betydligt mer detaljerad och strukturerad kravspecifikation. Annars finns det en stor risk för val av fel teknik samt att estimerad tidsplan och budget inte håller.

Du kan läsa mer om varför webbprojekt misslyckas här.

Utifrån vår erfarenhet inom branschen är den största anledningen till misslyckade webbprojekt bristande förarbete. Detta undviks genom att:

• Ta fram en korrekt skriven och genomarbetad kravspecifikation bestående av funktionella och icke-funktionella krav.
• Analysera vilka som är de mest lämpade teknikerna för webblösningen baserat på hållbarhet, flexibilitet och kostnadseffektivitet.
• Använda en projektmetodik som är baserad på sprintar (faser) med leverans efter varje sprint.

Kravspecifikation

En ofullständig kravspecifikation som endast består av en punktlista räcker inte. En kravspecifikation ska lägga grunden för ett lyckat webbprojekt, vilket innebär att den ska beskriva den tilltänkta webblösningen på ett strukturerat och tydligt sätt.

För att göra kravspecifikation så strukturerad som möjligt rekommenderar vi att dela upp den i funktionella och icke-funktionella krav. De funktionella kraven beskriver hur den tilltänkta webblösningen interagerar med användare, det vill säga vad en användare kan göra.

Medan de icke-funktionella kraven är alla andra krav som du har på webblösningen såsom dess grafiska gränssnitt och prestanda. Som till exempel en beskrivning av webblösningens laddningstider.

Funktionella krav

En välskriven och detaljerad kravspecifikation bör numreras och de funktionella kraven bör skrivas med hjälp av så kallade användarberättelser (user stories). Detta innebär att de funktionella krav som finns beskrivs utifrån användarens perspektiv för att förtydliga vad som är möjligt för användaren att genomföra. Ett exempel på detta är:

1.01 Som en användare ska jag kunna logga in genom att fylla i användarnamn och tillhörande lösenord.

För att undvika missförstånd och en inkorrekt estimering av projektet rekommenderar vi att allt en användare kan göra i den tilltänkta webblösningen kan specificeras med hjälp av användarberättelser. Detta kräver mycket arbete och förståelse för webbutveckling och -projekt, då väldigt många krav bör specificeras. Dock är detta nödvändigt för att olika parter ska ha samma bild av vad som ska levereras i projektet.

Icke-funktionella krav

De icke-funktionella kraven beskriver de övriga krav som finns på webblösningen såsom dess grafiskt gränssnitt, prestanda, säkerhet och användarvänlighet. Det är väldigt vanligt att de icke-funktionella kraven inte är tydligt definierade i en kravspecifikation vilket kan leda till felaktig utveckling och inkorrekt projektestimering.

Under våra år inom branschen har vi sett verksamheter beställa sökmotorer utan definierar laddningstider vid sökningar. Eller e-handlar utan krav på användarvänlighet eller prestanda. Detta resulterar lätt i lösningar med låg användarvänlighet som kan skada varumärket.

Genom att tydligt definierar vilka icke-funktionella krav som finns på den tilltänkta webblösningen, kan problem som detta undvikas. Att skriva icke-funktionella krav kan vara svårt och kräver erfarenhet inom webb- och systemutveckling.

Har du svårighet att ta fram en genomtänkt och välskriven kravspecifikation? Kontakt oss, så kan vi diskutera vilka krav som är viktiga för just din webblösning!

Val av rätt teknik

Om en kravspecifikation inte är välskriven eller tillräckligt detaljerad, finns det en stor risk att fel teknik väljs innan projektstart. Fel val av teknik kan till exempel begränsa webblösningens prestanda, användarvänlighet och möjligheten för vidareutveckling.

Val av teknik ska alltid utvärderas utifrån tre kriterier; hållbarhet, flexibilitet och kostnadseffektivitet. Med dessa tre punkter i åtanke kommer en trygg och kostnadseffektiv teknik att väljas som kan vidareutvecklas efter färdig lösning. Vid val av teknik är det första steget att välja teknisk plattform. Bör den tilltänkta webblösningen utvecklas i ett CMS (Content Management System) eller ett webbramverk?

Agil projektmetodik

Att arbeta agilt är en självklarhet och något alla leverantörer skyltar med, men ändå följs det inte av så många leverantörer. Det är väsentligt med regelbundna avstämningar med beställare och framförallt delleveranser.

Det finns en stor risk i att endast visa upp ett webbprojekt för beställaren vid slutet av projektet. Istället bör det finnas ett flertal delleveranser där beställaren får ta del av resultatet på en testserver och därmed ge feedback redan under utvecklingsfasen.

I webbprojekt är det otroligt viktigt med löpande kvalitetssäkring från båda parter. Om inte detta görs löpande under projektets gång finns en risk att det blir många ändringar vid slutet av projektet. Dessa ändringar kan riskera att försena projektet och överskrida den estimerade budgeten eftersom omarbete vanligtvis tar längre tid än väntat.

Vår bästa rekommendation i detta stadie är att ha goda marginaler i tidsplanen. Det är viktigt att räkna med att många systemfel och buggar kommer identifieras under projektets gång. Således behövs det finnas gott om tid för både testning och åtgärdande av system- och designfel.

Ständigt under utvecklingsfasen är det viktigt med ett tätt samarbete mellan båda parter. Just därför bör en beställares engagemang heller inte förringas. En beställare ska vara delaktiga under hela projektets gång med allt ifrån feedback till kvalitetssäkring.

Sammanfattningsvis

Utifrån vår erfarenhet inom branschen beror misslyckade webbprojekt på ett bristande förarbete. Men genom att ta fram en korrekt kravspecifikation med funktionella och icke-funktionella krav som formuleras på ett strukturerad sätt kan detta undvikas.

Utöver detta behöver de mest lämpade teknikerna utvärderas utifrån hållbarhet, flexibilitet och kostnadseffektivt. Dessutom rekommenderar vi under projektets gång att använda en projektmetodik som är baserad på spritar (faser) med leverans efter varje fas, på så sätt minimeras risken för stora omarbetningar i slutet av projektet.

Om ett ordentligt förarbete genomförs redan innan projektstart, minskar risken för att projektet misslyckas. Leverantören och beställaren har då samma förväntningar, vilket resulterar i mindre missförstånd och färre förseningar.