- Startsida
- Kunskapsbank
- Lägg grunden till ett lyckat Sitevision-projekt
Lägg grunden till ett lyckat Sitevision-projekt
Projekt och beställning
Står du och din organisation inför ett nytt webbprojekt? Här får du några tips och goda råd på vägen. Läs och ta ett litet steg mot att bli en bättre kravställare.
Before anything else, preparation is the key to success. Så uttalade sig Alexander Graham Bell, länge räknad av många som telefonens fader*. Även om den skotsk-kanadensiske uppfinnaren kastade in handduken ganska precis 80 år innan den första webbplatsen i Sitevision såg sitt ljus, så gäller denna sanning i alla högsta grad då det kommer till att genomföra lyckade webbprojekt.
I min roll som projektledare och utvecklare på Limepark har jag genom åren fått erfara både lyckade och mindre lyckade exempel på förarbeten, vilket i hög grad sedan påverkat projektets framgång. Min ambition med den här artikeln är inte att hänga ut någon, utan att helt enkelt dela med mig av lite tankar och råd som ni i egenskap av beställare kanske kan dra nytta av innan ni vänder er till oss eller någon av våra branschkollegor. Jag kommer i vissa fall måla med väldigt breda penseldrag för att begränsa mig i detta breda ämne och för att exemplifiera kommer jag att ta min utgångspunkt i de vanligaste typerna av projekt i Sitevision som vi på Limepark är involverade i.
Pling! Ljudet av ett nytt e-postmeddelande som ramlat in i vår info-mail. En förfrågan. Kul! Kunden önskar bygga en ny webbplats i Sitevision, den ska “vara responsiv” och man har en rad system som ska integreras. Det finns en lång lista med punkter och krav, många känns igen från andra liknande offertförfrågningar. Det finns en tight tidplan (helst skulle webbplatsen ha lanserats igår). Nu vill kunden ha in offerter från olika leverantörer.
När svarstiden är över har ett gäng leverantörer gjort en tolkning av vad det är kunden egentligen vill ha, en uppgift med en inbyggd svårighet då kunden paradoxalt nog ofta inte heller vet. Anbud på en webbplats spretar ibland betänkligt och det beror ofta på att förfrågningsunderlaget är ospecifikt och att leverantörer därmed gör olika tolkningar eller har olika ambitionsnivå. Vill man få bra och likvärdiga anbud som är enkla att jämföra är det jätteviktigt att förfrågningsunderlaget är tydligt och avgränsat.
Punkter att fundera över
Här är några punkter som jag tycker är vettiga att fundera över i samband med en upphandling eller enklare offertförfrågan:
Fundera igenom vad det är ni verkligen vill ha och var specifik
Om inte ni vet vad ni vill ha så kommer inte leverantören att veta det och i slutändan kommer ni således heller aldrig veta om ni fick de svar ni ville. Dessutom kommer ni att finna att de offerter ni får in skiljer sig markant åt, inte på grund av att det ni vill ha nödvändigtvis kostar så olika hos olika leverantörer utan för att man helt enkelt har gjort olika tolkningar av vad ni verkligen önskar. Syna de poster där leverantörerna skiljer sig åt mest och fundera på om något kan ha missuppfattats.
Använd skallkraven rätt
Är en viss funktionen verkligen ett krav till varje pris? Använd inte färdiga kravlistor bara för att fylla ut ett frågeunderlag för en falsk känsla av att “täcka upp så mycket som möjligt”. Tänk efter: Är detta verkligen de krav vi har? Är det en funktion som hela projektet är beroende av eller är den enbart “bra att ha”? Ställ er frågan varför ni har de kraven, om ni inte kan svara på den frågan är det dags att tänka till en sväng till. I slutänden handlar det om att ni bara ska betala för det ni verkligen behöver!
Gör förstudier ifall det behövs
Utred där vad ni har för målgrupper och vad de ska dra för nytta av ert projekt, granska besöksstatistik, genomför intervjuer, dra ihop workshops och gör annat som krävs ända tills ni har en klar bild av vad det är ni behöver få ut av projektet. Se dock alltid till att dessa har ett tydligt syfte för att inte lägga tid i onödan på mängder av workshops och abstrakta strategidokument som inte kommer att användas ändå.
Var ute i tid!
Pressade tidplaner medför ofta dyrare projekt och risken är stor att kvaliteten blir lidande. Underskatta inte den egna insatsen då ni sätter en tidplan. Jobb med sidor, struktur, innehåll, internutbildning etc tar tid. Vi på Limepark (och säkert många leverantörer med oss) har valt en väg där vi inte lämnar offert på projekt där vi inte är säkra på att kunna leverera något bra enligt önskad tidplan. Med en för tight tidplan riskerar ni således att utelämna flera leverantörer vilket ger er ett sämre urval efter genomförd upphandling.
Kräv att designleverantören verkligen kan systemet
Om ni tar hjälp av annan byrå (än de som ska bygga webbplatsen i Sitevision) vid framtagning av design, se till att de, ni eller någon annan inblandad part kan systemet för att även kunna få in systemtekniska aspekter till designen. Det blir extra viktigt då ni ämnar bygga en responsiv webbplats (med följsam design) - något som fungerar alldeles utmärkt i Sitevision. I dessa fall är det viktigt att designern har förståelse för hur formen kan anpassas för olika lägen samt att hela designern är konsekvent uppbyggd i ett gridsystem.
Var tydlig vid kravställande om integration av externa system
Om ni önskar integrera ett externt system, kolla då upp vilka alternativ som finns och beskriv det i ert förfrågningsunderlag. Tillhandahåller systemtillverkaren ett API? Har ni möjligheter att påverka/förändra källapplikationen? Frågor som gör att leverantören ges flera tillvägagångssätt att välja på och därmed ökar chansen till att ni genomför den mest effektiva lösningen.
Håll nere projektgruppens storlek eller se till att den är tydligt styrd
Ju fler kockar, desto sämre soppa heter det och ofta kan en för stor projektgrupp med otydlig styrning göra att förarbetet går trögt, fastnar vid oväsentligheter och spretar åt olika håll. Ta gärna in synpunkter från många då fler ögon ser mer, men se till att det i slutändan är en mindre grupp som tar besluten och prioriterar bland alla åsikterna. Utse en huvudsaklig kontaktperson för kontakt mot leverantören så risken för olika budskap minimeras.
Utred de tekniska förutsättningarna
Ska ni bygga en ny webbplats eller konvertera en befintlig till nytt utseende? Har ni då vägt för- och nackdelarna med de båda alternativen? Vilken version av Sitevision kräver era önskemål? Har ni då rätt driftmiljö? Kan ni uppgradera? Finns det speciallösningar som behöver byggas om i samband med en uppgradering? Är det läge att byta driftmiljö? Behöver ni en testmiljö? Ju fler frågor av denna typ ni kan svara på innan projektet sätter igång på allvar, ju smidigare kommer allt att flyta på när det väl är dags för genomförandet.
Våga ta hjälp
Tyvärr är det ju så att beställaren kanske inte sitter på den kompetens som krävs för att ställa rätt krav och göra rätt förarbete. Detta är så klart inte är konstigt då det kanske inte ingår i den normala arbetsbeskrivningen. Då är det bra att veta att det finns möjligheten att ta in de som faktiskt kan det i ett tidigare skede av projektet. “Så klart att han säger så”, tänker ni kanske nu. I egenskap av konsult vill jag väl maximera vad vi - och andra leverantörer kan debitera i ett projekt? Faktum är dock att många projekts slutsumma skulle bli mindre om slutleverantören var med som bollplank/partner i ett tidigare skede av projektet för att skutan ska hålla rätt kurs redan från början. I annat fall riskerar de dyra tidsbovarna att inträda i en fas av projektet där man som minst vill ha dem. Dessa gestaltas då i form av tillkommande kostnader för nya förutsättningar, extra möten, upprivna beslut, förändringar i redan färdiga designer, funktioner som inte kan realiseras, försenade projekt etc. Saker som varken kund eller leverantör uppskattar.
Fler borde också våga ta kontakt med andra som genomfört liknande projekt för att dra nytta av deras erfarenheter. En kommun kan exempelvis vinna mycket på att ta kontakt med andra kommuner som nyss drivit liknande projekt. Min erfarenhet är att många mer än gärna delar med sig av sin kunskap och kanske kan det även vara början till spännande samarbete framöver? Vi hjälper gärna till med kontaktingångar.
Min förhoppning är att att så många som möjligt till sist ska inse hur ett gediget förarbete kan leda till roliga, effektiva projekt där sedan tiden läggs på det som faktiskt spelar någon roll.
*Meningslös (?) kuriosa
Alexander Graham Bell patenterade telefonen år 1876 men den ska egentligen ha uppfunnits av italienamerikanen Antonio Meucci som konstruerade den första telefonen omkring 1849. Han skulle i brist på pengar dock inte ha kunnat betala för den patentansökan han lämnade in 1871. Patentet upphörde i januari 1993 och i juni 2002 erkände amerikanska representanthuset Meucci som uppfinnare av telefonen.