Projekt- och behovsanalys för ett lyckat webbprojekt

Det första steget till alla projekt är att lägga upp en strategi, det gör vi genom förstudier och behovsanalys. Detta är fundamentet för projektgenomförandet. Utan en strategi saknar vi riktning för projektet. Då blir det svårt att hitta rätt väg och resultatet blir därför sämre. Det här arbetet sammanställs i en “Projekt och Behovsanalys”

Behovsanalys eller förstudie?

I grunden är en behovsanalys som en kompass för ett projekt. Innan projektet påbörjas är det avgörande att förstå målet och den bästa vägen dit. Inom projektledning hjälper en behovsanalys oss att identifiera exakt vad projektet syftar till att uppnå och vilka utmaningar det kan möta.

När vi dyker djupt in i ett projekts krav, förväntningar och begränsningar säkerställer behovsanalysen att alla ansträngningar kanaliseras i rätt riktning.

Den lyfter fram luckor, bestämmer prioriteringar och anpassar alla intressenter till en gemensam vision. Utan detta grundläggande steg riskerar ett projekt att vandra planlöst, vilket leder till slöseri med resurser och missade mål.

Behovsanalys är det första, avgörande steget för att säkerställa att varje projekt börjar på rätt fot, vilket skapar rätt förutsättningar för framgång och hög ROI.

En behovsanalys innehåller för det mesta följande punkter:

• Projektets mål och syfte
• Teknisk genomförbarhet
• Riskhantering
• Användarinvolvering
• Kommunikation och samarbeten

En förstudie görs för att ta fram förutsättningarna för ett kommande projekt, en produkt eller en process innan projektutvecklingen påbörjas. Det primära målet med en förstudie är att fastställa omfattningen, analysera nuläget, strukturera innehållet och kartlägga intressenter. Vidare bedöms även affärsnyttan, krav tydliggörs och ett lösningsförslag tas fram.

Med en förstudie kan organisationen:

• Bedöm genomförbarhet
• Identifiera problem
• Samla in feedback
• Minska riskerna
• Validera antaganden

I huvudsak fungerar förstudien som ett sista verifieringssteg, vilket säkerställer att den fullständiga lanseringen är smidigare, effektivare och mer sannolikt att den blir framgångsrik.

Varför ska man göra en projekt- och behovsanalys?

Att designa och utveckla en företagsportal, internt arbetsverktyg, e-handelslösning eller webbplats handlar inte bara om hur det ser ut, det handlar även om hur det ska fungera och prestera.

Syftet med projekt- och behovsanalysen är att skapa de förutsättningar som krävs för ett genomtänkt och lyckat projekt. På RocketLabs hjälper vi till i hela processen när vi tillsammans med er bygger smarta, innovativa och strategiska lösningar för att effektivisera, automatisera och kvalitetssäkra er verksamhet.

Projektets mål och syfte
Denna dimension avser projektets huvudmål och dess underliggande intentioner. Den ger en klar riktlinje, skapar förståelse för förväntade resultat och fungerar som en vägledande kompass för beslutsfattande genom hela projektets livscykel.

Teknisk genomförbarhet
En noggrann utvärdering som avgör om projektets tekniska aspekter är genomförbara givet tillgängliga resurser och teknik. Den överväger potentiella tekniska hinder och avgör behovet av tekniska innovationer för att uppnå projektmålen.

Riskhantering
En systematisk process för att identifiera, bedöma och prioritera potentiella risker. Detta inkluderar utveckling av strategier för att minska, övervaka och kontrollera sannolikheten eller inverkan av oväntade händelser.

Användarinvolvering
En metodik som prioriterar involvering av slutanvändare vid utveckling och utvärdering. Denna praxis garanterar att produkten eller tjänsten uppfyller faktiska användarbehov och förväntningar, vilket leder till större acceptans och framgång på marknaden.

Kommunikation och samarbete
En kritisk aspekt som betonar värdet av kontinuerlig interaktion och gemensamt arbete mellan projektteamet och intressenter. En transparent och effektiv kommunikationsstrategi säkerställer att alla deltagare har en enhetlig förståelse och riktning, vilket optimerar projektets utförande.

Hur gör man en projekt- och behovanalys?

Projekt- och behovsanalysen grundar sig i en workshop där resultatet sammanställs av projektledaren till ett lösningsförslag som ligger i linje med de ramar som satts upp för projektet.

Här presenteras projektet utefter de målgrupper och user personas som projektet vänder sig till med tillhörande kravställning, user stories och acceptanskriterier. Alla delar är prioriterade, estimerade och beskrivna tillsammans med flödesschema och wireframes.

Lösningsförslaget ligger därefter som grunden för projektet och det arbete som projektteamet skall utföra.

Vad består projekt- och behovsanalysen av:

• Workshop tillsammans med nyckelpersoner
• KPI - Målformulering med SMART-modellen
• Beskrivning av målgrupper och user personas
• Kravställning med user stories och acceptanskriterier
• Projektbeskrivning med flödesscheman och wireframes
• Estimat för tid och kostnad
  
  

Workshop

För att komma igång är det bra att inleda projekt- och behovsanalysen med en workshop där alla nyckelpersoner är med. Här jobbar man tillsammans med brainstorming för att identifiera  och fastställa projektets ramar, kravställning och mål.

En workshop för projektet sträcker sig normalt över en halv dag till några dagar beroende på projektets omfattning.

Vad går vi igenom på en workshop:

• Målformulering genom SMART-modellen (KPI)
• Målgrupper och user personas
• Riktlinjer och kravspecifikation för projektet
• Konkurrensanalys
• Grafisk profil, layout och design
• Projekttriangeln: omfattning, tid och kostnad

Målformulering: SMART-modellen (KPI)

Era KPI:er (Key Performance Indicators) ska uttrycka de strategiska målen i projektet. Syftet är att kunna följa och mäta framgången i projektet efter lansering. Tillsammans definierar vi tydliga KPI:er med målformulering genom SMART-modellen.

Fördelarna med SMARTa mål är att det delar upp stora mål i mindre bitar och skapar en handlingsplan för framgång. Samtidigt får vi genomtänkta mål i projektet redan från början vilket gör att det blir lättare att spåra framgången.

SMART innebär att ett mål skall vara

• Specifikt (Ange exakt vad du vill åstadkomma, vem vad, var, varför, vilket)
• Mätbart (Visa hur du skall mäta och utvärdera om målet har uppnåtts)
• Accepterat (Alla involverade har accepterat målet och hur det skall nås)
• Realistiskt (Säkerställ att målet är rimligt att uppnå, varken för lätt eller för svårt)
• Tidsatt (Ange när målet skall vara uppnått)

Skriv ner det som är Specifikt

Ett SMART mål bör vara tydligt och specifikt. Specifika mål har en betydligt större chans att nås. Försök svara på följande fem frågor för att formulera specifika mål:

• Vem: Vem är involverad i detta mål?
• Vad: Vad vill vi åstadkomma?
• Varför: Varför vill vi uppnå detta mål? Varför är detta mål viktigt?
• Var: Var ska detta mål uppnås?
• Vilket: Vilka resurser eller begränsningar är inblandade?
• När: När vill vi uppnå detta mål?

I nästa steg tar du fram vad som går eller skulle kunna gå att Mäta

Ett SMART mål måste ha kriterier för att mäta framsteg. Om det inte finns några kriterier går det inte att avgöra om målet är uppnått. Ett mätbart mål bör ta upp frågor som:

• Vilken mätbar enhet skall användas?
• Hur många eller hur mycket?
• Vad skall vara uppfyllt för att målet skall ses som klart?

Finns Acceptans för målet?

Det här steget handlar om att se till att ditt mål är accepterat av samtliga berörda parter som är involverade i målet. Ett accepterat mål kommer vanligtvis att svara på frågor som:

• Är vi beredd att genomföra målet?
• Verkar det vara värt arbetet som krävs?
• Är det här rätt tidpunkt?
• Matchar detta våra andra ansträngningar/behov?
• Är vi rätt personer för att nå detta mål?

Går målet att nå – är det Realistiskt?

Ett SMART mål måste vara realistiskt och uppnåeligt för att bli framgångsrikt. Ett realistiskt mål kommer vanligtvis att svara på frågor som:

• Hur kan vi uppnå detta mål?
• Hur realistiskt är målet med tanke på begränsningar?
• Har vi resurser och förmåga att nå målet? Om inte, vad är det vi saknar?
• Har vi tidigare lyckats nå målet?

När ska målet nås? Sätt en Tid!

Ett SMART mål måste vara tidsbestämt, d.v.s. att det har ett start- och slutdatum. Du ska ha en deadline att fokusera på och något att arbeta mot. Den här delen hjälper till att förhindra att vardagliga uppgifter prioriteras framför projektets långsiktiga mål. Ett tidsbestämt mål svarar vanligtvis på dessa frågor:

• När ska målet vara nått? Har målet en deadline?
• Vad kan vi göra om sex månader?
• Vilka aktiviteter kan vi göra om sex veckor?
• Vad kan vi göra idag?

Målgrupp och user personas?

En målgrupp är den grupp människor som du vill nå och sälja dina produkter/tjänster till. Denna grupp människor delar samma intressen och egenskaper utifrån ett demografiskt perspektiv.

User personas fokuserar istället på egenskaperna hos en enskild person som beskriver din ideala kund eller typ av användare, inklusive beteende, intresse, behov och livsstil.

Själva syftet med en persona är att du skapar en fiktiv person som representerar antingen hela målgruppen eller en del av hela din målgrupp, om ni har flera målgrupper att nå ut till. En persona ska också underlätta ert dagliga arbete med att försöka nå ut till er målgrupp!

Målgrupp

Beskriv vilka personer du vill nå ut till eller de grupper som kommer att vara användare av webbplatsen. När vi känner till målgruppen kan vi börja segmentera ännu mer genom att skapa våra user personas.

Försök att skapa flera olika user personas för att få en tydlig bild av olika kunder, besökare eller användare. På så vis blir det lättare att kravställa projektet via user stories.

User personas:

1. Ge personen ett namn
2. Vilken ålder är personen?
3. Är din ideal målgrupp gift, sambo eller singel?
4. Har personen familj? Hur många barn?
5. Vad jobbar personen med?
6. Vad har personen för inkomst?
7. Vad gör personen på sin fritid?
8. Använder personen sociala medier? Vilka? På vilket sätt?
9. Har personen något speciellt intresse som skulle ge oss idéer om hur vi kan skapa bra innehåll för att få deras uppmärksamhet?
   

Konkurrensanalys

Med allra största säkerhet har ni konkurrenter. Perfekt! Från konkurrenter finns mycket information att hämta. Information om vad de gör bra, där det går att hämta inspiration och vad de gör mindre bra, där man bör undvika att ta efter.

Kravställning med user stories och acceptanskriterier

För oss är ett av de viktigaste momenten kravställningen. Även om alla projekt alltid ska vara lösningsfokuserade och det generellt sett är en bra approach är det viktigt att lösningen kommer ur en behovsanalys.

Därför är en gedigen kravställning en grundpelare och en nödvändig förutsättning för ett lyckat projekt. För bästa resultat och för att undvika oklarheter tar vi processen kring kravställning ett steg längre och alla krav formuleras ur ett användarperspektiv (User Stories).

Vem behöver den här funktionen? Varför behövs den här funktionen? Hur lång tid tar det att utveckla den här funktionen? Vilken prioritet eller relevans har den här funktionen?

Först när kravställningen är klar kan projektet tidsestimeras och projektbeställaren kan prioritera utifrån kostnad och relevans. Det är ganska sällan budgeten räcker till att göra allt. En välformulerad kravställning möjliggör det för projektbeställaren att fatta informerade och kloka beslut och få maximalt värde för sin investering.

Kravställning för oss på RocketLabs är en process som syftar till att alla nyckelpersoner i projektet ska förstå vad som kommer att göras och levereras. Ofta finns det även tredjepartsaktörer som behöver ta del av hela eller delar av kravställningen för att kunna utföra sin del av projektet. För oss är kravställningen ett agilt dokument, det är inte hugget i sten, utan kan revideras och kompletteras även efter att utvecklingen kommit igång. Alla förändringar är välkomna som kan göra slutprodukten bättre.

För att beskriva krav så tydligt som möjligt använder vi oss av User Stories (kravställningens minsta beståndsdel). En User Story är ett format som gör det lätt för icke tekniska personer att förstå vad en viss funktion finns och hur den ska uppnås.

Samtidigt är User Stories ett enkelt sätt att beskriva funktionalitet ur en användares synvinkel utan att behöva skriva tekniska specifikationer (de tekniska detaljerna är upp till utvecklingsteamet att lösa).

För att förtydliga en User Story skriver man acceptanskriterier som förtydligar vad det är som kommer levereras tillsammans med funktionella- och tekniska krav som gör att utvecklarna förstår vad som ska implementeras.

Tips!
En bra kravställning är en förutsättning för ett bra slutresultat. Kravställningen är en väldigt viktig del av projektet, om inte den viktigaste. Den säkerställer att det finns en samsyn hos alla involverade och vad som skall göras och levereras. Risken för dolda antaganden eller missuppfattningar minimeras. Desto bättre kravställning, desto bättre resultat.

Hur skriver man en User Story?

En user story är en kort beskrivning av vad en användare vill uppnå. Varje user story måste ha acceptanskriterier för när kravet är uppfyllt. En user story kan vid behov även kompletteras med funktionella och/eller tekniska krav för att tydliggöra vad som skall utvecklas.

Det är också viktigt att user stories är prioriterade för att utvecklingsteamet skall veta i vilken ordning olika krav skall utföras eller för att projektbeställaren ska kunna fatta beslut om vad som behöver eller kan prioriteras bort för att hålla ramarna inom projekttriangeln.

Som en <Typ av användare> vill jag kunna <Utföra en handling> så jag kan <Uppnå ett mål>

• <Typ av användare> vem bygger vi för, vem är användaren?
• <Utföra en handling / Mål> vad ska vi bygga?
• <Uppnå ett mål / Anledning> vad är anledningen till att bygga detta?

Exempel: Som en besökare vill jag kunna spara produkterna i min kundvagn så jag kan komma tillbaka till webbplatsen vid ett senare tillfälle och slutföra mitt köp.

Funktionella krav

Funktionella krav beskriver hur en användare ska kunna utföra handlingen eller vad som ska hända i systemet.

Tekniska krav

Tekniska krav eller ibland kallat "icke- funktionella krav” beskriver tekniska aspekter som utvecklingsteamet skall ta hänsyn till och uppfylla i kravet.

Acceptanskriterier

Acceptanskriterier är påståenden som underlättar för utvecklingsteamet och testare. Dessa påståenden används som ett "definition of done" för att säkerställa att kravet blivit uppfyllt.

Prioritera krav med MoSCoW metoden

Prioritering används för att tydliggöra vilka krav som ska prioriteras och i vilken ordning.

• M – Must have (Måste ha), krav som anses vara obligatoriska för driftsättning
  
  
• S – Should have (borde ha), detta är krav som borde ingå i projektet om det är möjligt. Dessa är viktiga men inte avgörande för driftsättning. Ibland kan det vara smärtsamma att lämna utanför, men projektet är fortfarande genomförbar
  
  
• C – Could have (kan ha), krav som kan inkluderas så länge de inte påverkar M – eller S -kraven. Det vill säga att kraven är önskvärda men mindre viktiga och påverkar inte helheten om de utelämnas.
  
  
• W – Wont have (kommer inte att ha), krav som implementeras vid ett senare tillfälle. Ibland även kallat Nice-to-have features. Vilket kan ses som en önskelista med funktioner inför en framtida release.

Projektbeskrivning, flödesschema och wireframes

För att få en mer övergripande och tydlig bild av projektet görs en moment indelad projektbeskrivning där alla moment illustreras tillsammans med flödesscheman. Det visuella i ett flödesschema blir ett viktigt komplement vilket förtydligar hur olika delar i projektet hör ihop.

Samtliga User Stories som tagits fram under kravställningen placeras i rätt moment och bildar på så vis en gruppering av arbetsuppgifter till utvecklingsteamet.

Andra verktyg vi använder oss av är wireframes vilket fungerar som ett kommunikationsunderlag mellan projektbeställaren och utvecklingsteamet. Wireframes är skisser för projektet som visar grundläggande layout, navigation och struktur innan man har en färdig design.

Wireframe visar alltså var olika komponenter ska finnas och ibland också vad de ska innehålla, snarare än vilken färg och form de ska ha. Eftersom wireframes används i början av designprocessen fungerar de som en visuell kravspecifikation och kompletterar projektbeskrivning och flödesscheman där det behövs. Wireframes baseras på användarnas behov och säkerställer att vi får med alla de komponenter som måste finnas.

Tips!
En fördel med att använda wireframes är att det är ett snabbt, enkelt och billigt sätt att testa och utveckla idéer. Det är bättre att testa, iterera och få möjlighet att upptäcka eventuella fel tidigt i processen, innan man har en färdig produkt. Eftersom man med hjälp av wireframes skalar bort designen ligger fokus först och främst på att få ihop en bra grundstruktur, användarvänlighet och flöden som behöver tillgodoses

Projekttriangeln: Ett sätt att förtydliga projektets omfattning, tid och kostnad

När man arbetar med ett projekt så har man ofta ett tydligt mål som man strävar efter och en plan på hur man vill uppnå målet. I ett projekt så möter man dock begränsningar av olika slag som man under projektets gång behöver ta hänsyn till och ha en plan för. När det finns en tydlig plan och ett mål för projektet går det att använda sig av ”Projekttriangeln”.

En projekttriangel är en illustration av tre element där de vägs mot varandra och som också har olika beroenden mot varandra. Om en faktor i triangeln påverkas så kan de andra två också komma att påverkas. Man placerar ut faktorerna i en illustration för att få en tydlig bild om vad det är man fokuserar på och detta är något som alla i projektet kan ta del av. De tre vanligaste elementen som man brukar ta hänsyn till är tid, budget, och resultat.

Det är viktigt att man som projektbeställare förstår att man exempelvis inte kan uppnå något snabbt och samtidigt säkerställa hög kvalité med en låg budget eller samma mängd resurser. I det fallet så behövs det mer resurser, exempelvis mer arbetskraft eller pengar. Är det så att man vill ha högre kvalitet men bli färdig snabbt eller önskar tillföra mer funktionalitet till sitt projekt så kommer kostnaden att behöva gå upp för att kompensera.

"Välj två"-triangelteorin visar hur alla projekt fungerar inom de tre huvudsakliga gränserna kostnad, tid och värde. Att ändra en sida av triangeln kommer alltid att påverka de andra, vilket gör det mycket utmanande att samtidigt uppnå alla tre projektmålen.

Under projekt- och behovsanalysen behöver man ta ställning till vilka delar i projekttriangeln som är högst prioriterade.

- Ska resultatet levereras med hög kvalitet, behöver projektet utföras snabbt eller har projektet en låg budget? Men kom ihåg, du får bara välj två".

Hur kan vi hjälpa till?

På RocketLabs förstår vi att ni är unika och att ni driver företag för att ni vill differentiera er från era konkurrenter på ett sätt som är värdefullt för era både er och era kunder. Vi vet att ett av de viktigaste målen för ert företag är att övertyga era kunder om just detta så er verksamhet kan fortsätta växa.

För oss är goda relationer viktigt och vi vill vara en naturlig del av er verksamhet. Det ger oss en unik möjlighet att ta del av era tankar och idéer för att sen väva ihop det med vår expertis, kunskap och erfarenheter av att ha utvecklat webbapplikationer i över 10 år.

För oss på RocketLabs är viktigt för oss att förstå ert behov på djupet. Vårt syfte är att hjälpa företag utveckla webb- och systemapplikationer med innovativt tänkande och smarta lösningar.

Därför studerar vi noggrant varje projekt för att kunna leverera en tillförlitlig och effektiv lösning. Vi analyserar alla tillgängliga alternativ och ger kompetent rådgivning för att vägleda er till välgrundade beslut.”

Det är alltid vår avsikt och främsta mål att kunna bli en långsiktigt och trogen samarbetspartner där vi över lång tid växer tillsammans och vi är med och levererar professionella lösningar som hjälper ert företag och verksamhet både idag och i framtiden.

Vi är fast beslutna om att alltid kunna leverera maximalt värde. Det är därför vår uppfattning att vi jobbar bättre tillsammans med några väl utvalda nyckelkunder och deras projekt där vi kan ge vårt fulla fokus till er verksamhet och de utmaningar ni ställs inför.

Om du har en begränsad budget kan det absolut vara en idé att bygga ett projekt med hjälp av Wordpress. Men för ett långvarigt och hållbart projekt som kan växa tillsammans med er rekommenderar vi alltid att bygga en lösning anpassad för er verksamhet. Är er största prioritet ett projekt till så låg kostnad som möjligt är vi tyvärr inte rätt för varandra.

Tillsammans är vi nyckelpersoner i projektteamet:

• Projektbeställare
• Projektledare
• Systemutvecklare
• UI / UX designer
• Content strateg
• SEO Specialist