Så projektleder du bygget av en företagswebbplats (med Rich Butkevic från Project Zendo)

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett datorprogram. Ursäkta eventuella stavfel eftersom boten inte har rätt 100 % av tiden.

Ben Aston

Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Välkommen till DPM-podden. Oavsett om du är en erfaren projektledare, digital producent eller något helt annat – kanske hamnade du bara på något sätt med ansvaret för att leda projekt – ska du veta att du i dag, i dina hörlurar, får sällskap av tusentals andra i samma situation som gör sitt bästa för att starta, planera och leverera bättre projekt.

Vi på thedigitalprojectmanager.com finns här för att hjälpa dig att bli mer självsäker och skicklig som projektledare, och vi vill koppla samman dig med andra som också leder och driver projekt. Om du verkligen vill utvecklas och ta ditt arbete som projektledare till nästa nivå kan du läsa mer om vår DPM-skola och registrera dig för vårt proffsmedlemskap för att få tillgång till alla våra utvalda resurser.

Slutligen: medan du lyssnar på programmet får du gärna prenumerera och gå med i vår e-postlista på thedigitalprojectmanager.com för att hålla dig uppdaterad om allt som händer. Om du någon gång har byggt en företagswebbplats vet du mycket väl att det är otroligt svårt att få det rätt. Delvis beror det på att det inte görs särskilt ofta, men det handlar om mer än så: otydliga mål, en luddig brief, en härva av intressenter och stora mängder politik.

Allt detta gör det otroligt svårt att över huvud taget färdigställa en företagswebbplats – än mindre göra det på rätt sätt. Lägg till tekniska utmaningar, så kan ett skinande nytt webbplatsprojekt snabbt förvandlas till en fullständig katastrof. I dagens poddavsnitt ska vi därför förklara hur du kan bygga företagswebbplatser på rätt sätt. Fortsätt lyssna för att få veta hur du kan planera, leda och styra dina kommande projekt för företagswebbplatser och få dem rätt från början.

Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Välkommen till DPM-podden. Oavsett om du är en erfaren projektledare, digital producent eller något helt annat – kanske hamnade du bara på något sätt med ansvaret för att leda projekt – ska du veta att du i dag, i dina hörlurar, får sällskap av tusentals andra i samma situation som gör sitt bästa för att starta, planera och leverera bättre projekt. Vi på thedigitalprojectmanager.com finns här för att hjälpa dig att bli mer självsäker och skicklig som projektledare, och vi vill koppla samman dig med andra som också leder och driver projekt.

Om du verkligen vill utvecklas och ta ditt arbete som projektledare till nästa nivå kan du läsa mer om vår DPM-skola och registrera dig för vårt proffsmedlemskap för att få tillgång till alla våra utvalda resurser. Slutligen: medan du lyssnar på programmet får du gärna prenumerera och gå med i vår e-postlista på thedigitalprojectmanager.com för att hålla dig uppdaterad om allt som händer.

Den här podden presenteras av Clarizen, ledande inom programvara för projekt- och portföljhantering i företag. Besök clarizen.com för mer information. I dag har jag sällskap av Rich Butkevic-

Rich Butkevic

Perfekt.

Ben Aston

Uttalade jag det rätt?

Rich Butkevic

Du uttalade det perfekt.

Ben Aston

Där ser man, jag övade. Rich är konsult inom projektledning och skriver bloggen projectzendo.com. Gå gärna in och läs den. Han håller också workshops i projektledning över hela Texas, så besök artofpmo.com om du är intresserad. Vi återkommer till det om en stund. Rich har faktiskt en unik kombination av ledande roller inom projekt- och produktledning, kvalitetssäkring, verksamhetsanalys, marknadsföring och utbildning. Han använder agila metoder och Scrum och har alla de bokstäver och certifieringar man rimligen kan önska sig: PMP, Certified Scrum Master, IBM Rational Unified Process samt certifieringar inom Amazon och e-marknadsföring. Han har allt.

Hej Rich, och tack för att du är med oss i dag.

Rich Butkevic

Hej Ben, tack för att jag fick komma. Det uppskattar jag.

Ben Aston

Jag vill börja med att gå igenom alla de kvalifikationer och bokstäver du har efter ditt namn. Vissa säger ungefär: ”Jag bryr mig egentligen inte om certifieringar.” Du har uppenbarligen valt motsatt väg och skaffat nästan alla som finns. Handlar det om en särskild passion för lärande? Vad fick dig att vilja certifiera dig inom allt?

Rich Butkevic

Jag vet inte om det gäller allt, men jag har en passion för att lära mig. Det är helt enkelt något jag tycker om. Jag tror att en certifiering inom projektledning – eller egentligen inom vilket område som helst – visar att man tar yrket på allvar och håller sig uppdaterad. Förutom PMP-certifieringen skaffade jag de andra certifieringarna mer eller mindre efter behov i olika projekt.

Om jag till exempel arbetade i ett projekt som använde Amazon Web Services ville jag verkligen sätta mig in i tekniken för att kunna göra ett bättre jobb som projektledare. När jag gjorde det upptäckte jag att jag tyckte om det och ville lära mig mer. Om jag ändå skulle lära mig mer var det trevligt att ha ett mål att arbeta mot. Därför gjorde jag det till mitt mål att ta en certifiering, och ungefär så fick jag dem [ohörbart 00:05:30].

Ben Aston

Berätta hur du började arbeta med projektledning. Du är uppenbarligen tekniskt inriktad. Jag känner inte till många projektledare som har en teknisk certifiering som AWS-

Rich Butkevic

Absolut.

Ben Aston

Hur började du och hur kom du in på projektledning?

Rich Butkevic

Under studietiden arbetade jag som teknisk supportperson och svarade i telefon precis när bredbandet började komma. Jag fick alltså en tidig teknisk start under en ganska spännande period. Direkt efter universitetsexamen blev jag verksamhetsanalytiker på ett stort telekommunikationsföretag i Chicago, där jag bodde då. Därefter gick jag över till kvalitetssäkring, började leda kvalitetssäkring och gick sedan in i projektledning på det företaget. Jag tog min certifiering, och sedan fortsatte saker därifrån.

Ben Aston

Du gick alltså från teknisk support och kvalitetssäkring till projektledning. Du lärde dig säkert många saker under din första dag som projektledare. Vad skulle du säga till ditt yngre jag nu, med den kunskap du har i dag?

Rich Butkevic

Jag tror att det viktigaste är att förstå att det inte handlar om verktyget. Många projektledare blir väldigt fokuserade på att känna till alla detaljer och funktioner i det projektledningsverktyg de använder. Enligt min mening är verktyget bara ett sätt att effektivisera, automatisera och stödja en process som du egentligen bör kunna genomföra med penna och papper.

Om du inte känner dig bekväm med att leda ett projekt med inget annat än en penna och anteckningsbok betyder det inte att det är så du faktiskt ska arbeta. Men att vara en bra projektledare handlar inte om att vara den som kan mest om Microsoft Project eller något annat projektledningsverktyg. Det handlar om mycket mer än så – framför allt om mjuka färdigheter och om att förstå vad du försöker åstadkomma som projektledare, snarare än att vara expert på programvaran.

Ben Aston

Ja, verkligen. Men på tal om verktyg – jag tycker om verktyg.

Rich Butkevic

Ja, jag också.

Ben Aston

Vad finns i din verktygslåda som projektledare, utöver pennan och anteckningsblocket du nämnde?

Rich Butkevic

Det som gjort störst skillnad i min verktygslåda, utöver det projektledningsverktyg vi faktiskt använder, är någon form av samarbetsverktyg. Jag tycker mycket om Slack. Det är enkelt och lätt för människor att använda, och det gör stor skillnad jämfört med att försöka hantera saker genom en mängd e-postmeddelanden och Excel-dokument som ligger utspridda på gemensamma företagsdiskar där ingen hittar dem.

Jag gillar Slack, men precis som med projektledningsverktyget är själva konceptet och idén viktigare än vilket specifikt verktyg du väljer.

Ben Aston

Använder du några integrationer med Slack som är särskilt användbara för att underlätta samarbetet och göra det lättare att använda de mjuka färdigheterna?

Rich Butkevic

Inget särskilt kommer spontant till mig, förutom vissa integrationer för tidsregistrering som jag ibland använder som konsult. Företagen jag arbetar för har vanligtvis vissa standarder vi måste följa. Programvaran för tidsplanering som integreras med Slack kan därför variera. Det är bra att ha den integrerad på något sätt, men det som verkligen varit värdefullt för mig i Slack är att förstå kortkommandona. Det har gjort enorm skillnad.

Ben Aston

Vilket är ditt favoritkortkommando?

Rich Butkevic

Oj. Nu sätter du mig på prov. Jag vet inte. Det känns som om jag kan dem instinktivt, som om fingrarna kan dem-

Ben Aston

Det gör du säkert.

Rich Butkevic

Men hjärnan kan dem inte.

Ben Aston

Du kan inte citera dem, men du vet hur du ska röra händerna.

Rich Butkevic

Ja. Det är lite som mitt telefonnummer. Ibland har jag svårt att säga vilket mitt telefonnummer är, men jag har inga problem med att slå det eftersom jag måste.

Ben Aston

Ja, det var roligt. Men om vi återgår till din poäng: det handlar inte om verktygen, och nu har vi börjat prata om verktyg. Låt oss återgå till huvudpoängen – att bra projektledning inte handlar om verktygen. Berätta mer om vad du har upptäckt är själva konsten i projektledning och hur du använder de mjuka färdigheterna för att leverera bättre projekt.

Rich Butkevic

När jag talar om mjuka färdigheter är kommunikation och liknande självklart viktigt. Men ett bättre sätt att uttrycka det är kanske att förstå på en konceptuell nivå vad en projektledare ska göra och hur ett projekt åtminstone idealiskt ska genomföras. Då kan du fokusera på det väsentliga och undvika sådant som bara slösar tid.

Under ett projekt finns några stora områden som du bör fokusera på. Sedan finns det uppgifter under dessa områden som du måste eller bör göra. Du behöver identifiera dina krav och säkerställa att både verksamheten och, om det gäller ett IT- eller webbplatsprojekt, det tekniska teamet har en gemensam förståelse för kraven och vad de innebär. Du behöver se till att testning genomförs och att defekter hanteras på något sätt. Det handlar om de mer övergripande områden som ofta representeras som sammanfattningsuppgifter i en projektplan: att förstå det större målet och varför du gör sakerna.

Jag brukar säga att om du inte kan skriva en tweet om varför du fyller i ett dokument eller varför du gör det du gör, bör du stanna upp och klargöra varför. Om du inte vet varför du gör något kan du ofta inte göra det bra – och du kanske inte behöver göra det alls.

Ben Aston

Låt oss gå in på ämnet att leda byggen av företagswebbplatser. Vi publicerade nyligen ett inlägg om hur projekt för företagswebbplatser går fel – en fusklapp för projektledare. Läs det på thedigitalprojectmanager.com om du inte redan har gjort det. Verkligheten är att det är svårt. Projekt för företagswebbplatser är verkligen krävande. Därför anlitar företag byråer och konsulter och behöver extern hjälp, oavsett om det handlar om en större uppdatering, en migrering till molnet, införandet av ett nytt CMS eller integration med digitala marknadsföringsverktyg.

Sådana projekt genomförs normalt inte särskilt ofta. Ett stort webbplatsprojekt görs kanske vart tredje till femte år, vilket ofta innebär att personerna som deltar inte är särskilt erfarna. De kanske bara har lett ett sådant projekt en eller två gånger under sin karriär.

Det är utmanande. Som jag nämnde i början finns många intressenter, otydliga briefar, politik och tekniska utmaningar. Om du inte har läst Richs artikel bör du göra det. Jag vill prata om processen och hur vi kan effektivisera den, med utgångspunkt i det Rich nyss sade om att förstå vilka saker som måste hända för att projektet ska lyckas. Men låt oss börja med varför detta är så svårt. Kan du dela med dig av ett exempel eller en skräckhistoria om när det har gått fel för dig? Sedan kan jag göra detsamma.

Rich Butkevic

När det gäller saker som gått fel var en av de viktigaste lärdomarna jag tog med mig tidigt i karriären att lita på men verifiera. Många gånger sade projektresurser att de hade slutfört en uppgift, när de egentligen menade att de planerade att slutföra den eller att den låg på deras att-göra-lista. Sedan dök andra saker upp och uppgiften glömdes bort eller sopades under mattan. Vissa sådana saker blir tyvärr inte synliga förrän du går till produktion.

Det var en av de största lärdomarna jag fick tidigt. Om vi återgår till det jag sade om Slack har ett bra samarbete i stora team, särskilt i stora projekt eller projekt där resurserna är geografiskt utspridda, varit avgörande för mig. Ju större ett projekt är, desto mindre kan du förlita dig på att en eller två personer ska göra heroiska insatser och rädda allt i slutet.

I ett projekt för en företagswebbplats kan en konsult som jag besöka olika företag några gånger om året och arbeta med sådana projekt. Jag har förmodligen arbetat med ett par dussin projekt av den typen. Men en system- eller nätverksadministratör på ett företag som varit där i 15 år kanske bara har gjort något liknande en gång, eller högst två gånger, under det årtionde eller den och en halv decennium som personen arbetat där.

Även om det kan verka rutinmässigt för många är det därför inte alls rutinmässigt för många personer i företaget.

Ben Aston

Jag kan berätta om en gång när det gick fel. För några år sedan arbetade jag med ett projekt för en företagswebbplats. Utmaningen handlade egentligen om samsyn kring briefen. Det visade sig – och detta handlar verkligen om intressenthantering – att personen som fått i uppdrag att leda projektet internt inte hade samlat in alla insikter från sitt team.

Personen hade skrivit en brief men inte fått den godkänd, eller så hade den godkänts utan att granskas ordentligt. Vi gick vidare, designade webbplatsen och byggde den. Strax innan lansering upptäckte vi att det fanns ytterligare ett godkännandesteg i projektets styrningsstruktur som vi inte alls hade känt till under projektets gång.

Då fick vi höra: ”Grundaren och vd:n måste godkänna den innan vi går live.” Vi svarade: ”Ni nämnde aldrig det tidigare.” Det visade sig att grundaren och vd:n var den verkliga chefen. Personen hade mycket tydliga uppfattningar om vad som skulle och inte skulle finnas med, och de var grundläggande för hela projektet.

Vi fick ett svårt samtal där vi behövde säga: ”Jag beklagar, men detta fanns inte i briefen. Ni har godkänt allt genom hela projektet, och nu är grundaren och vd:n inte nöjd. Därför är ingen annan nöjd heller.” Vi behövde utfärda en omfattande ändringsbegäran. Kunden blev upprörd över att behöva betala mer, och relationen försämrades.

Det var delvis vårt ansvar eftersom vi inte hade drivit frågan om styrningsstrukturen tillräckligt hårt i början. Vi borde ha tagit projektet långsammare och sett till att det godkändes hela vägen upp i organisationen.

Rich Butkevic

Det kan vara mycket svårt, särskilt i ett större företag där du kanske har ett dussin identifierade intressenter. Alla de intressenterna har en chef, och de cheferna har ofta i sin tur en chef. När en tillräckligt högt placerad chef ser en webbplatsändring som personen inte gillar kan besluten som fattats tidigare åsidosättas.

Ben Aston

En lärdom för mig var att förklara konsekvenserna. Jag säger numera: ”Låt oss kartlägga intressenterna och skapa en RACI-matris utifrån projektets olika milstolpar. Om den här personen är den som ska godkänna allt, men vi senare upptäcker att någon annan måste fatta det slutliga beslutet, kommer det att påverka kostnader och tidsplan. Säg det nu, annars får vi konsekvenser senare.”

Det handlar om att vara mycket tydlig. Ofta är det marknadsavdelningen som ansvarar för projektet och sedan tilldelar det till en junior marknadsförare. Den personen tänker: ”Jag kopplar bara in min chef.” Då bör man säga: ”Vi behöver nog involvera några fler personer här.”

Men hur ser processen ut på en övergripande nivå? Hur går vi från att en företagskund säger ”Jag behöver en ny företagswebbplats” till ”Nu är den klar”?

Rich Butkevic

Jag vill på den högsta nivån först säkerställa att vi identifierar projektets eller webbplatsens faktiska mål. Ibland handlar det om en fusion eller ett förvärv där två webbplatser ska integreras. Ibland handlar det om en redesign eller omprofilering. Ibland inför man ett nytt innehålls-hanteringssystem. Målen styr många av de efterföljande uppgifterna i projektet.

När målen är identifierade går jag gärna vidare till användarberättelser. Det är något som många design- och webbplatsprojekt förbiser. De flesta företag riktar sig inte till alla människor. De kan vanligtvis identifiera några olika kundtyper eller kundprofiler. Det kan vara personer som ska köpa något, personer som söker information eller befintliga kunder som vill göra en ny beställning.

Var och en av dessa användartyper har olika mål på webbplatsen. De söker olika information, har olika kunskapsnivåer och tar olika vägar genom webbplatsen. Det slutliga målet för användaren och företaget varierar beroende på användarprofilen.

Ben Aston

Bra.

Rich Butkevic

Att skriva ner varför de besöker webbplatsen och vad de hoppas kunna göra hjälper till att styra nästa del av projektet: att utforma webbplatsens hierarki och struktur. Du vill begränsa antalet klick som krävs för att nå en viss plats. Det är inte bra att begrava det användaren söker tjugo sidor ner på webbplatsen, eftersom personen aldrig hittar det eller blir frustrerad. Det är dåligt av många skäl, bland annat ur sökmotoroptimeringssynpunkt.

När hierarkin är fastställd tittar vi på innehållet och hur det ska hanteras. På en mindre webbplats med färre än 50 sidor är det inte lika stort problem. Men vid en redesign eller ett CMS-byte för en webbplats på företagsnivå kan det finnas tusentals webbsidor. Då måste man veta vilket innehåll som ska behållas, uppdateras, tas bort eller slås samman. Det är en omfattande uppgift, och här kan verktyg verkligen hjälpa till. Du vill inte ha två eller tre tusen Word-dokument utspridda i en mapp någonstans.

Ben Aston

Ja.

Rich Butkevic

Först efter detta börjar jag verkligen fokusera på de tekniska delarna. De är ganska statiska. Det finns skillnader mellan företag när det gäller infrastruktur, CMS och liknande, men du kan få alla tekniska delar perfekta. Om du inte först har tänkt igenom de andra delarna, når målen och organiserar webbplatsen på ett användarvänligt sätt spelar tekniken ingen roll.

Ben Aston

För dig handlar det alltså om att tidigt definiera briefen och webbplatsens mål, identifiera viktiga personas eller arketyper och skapa informationsarkitekturen så att användarna kan använda webbplatsen effektivt. Sedan kommer designfasen med wireframes och designkomponenter. Brukar du köra det som ett parallellt arbetsflöde? För den som lyssnar och tänker att upptäckt, planering och design före utvecklingen kommer att ta lång tid – vilka knep har du för att köra saker parallellt, snabba upp processen och ändå göra rätt?

Rich Butkevic

Jag försöker undvika alltför många knep eftersom planeringen har så stor betydelse för hur snabbt projektet går senare. Om du inte har tid att göra det rätt från början kommer du inte heller att ha tid att göra om det. Med det sagt kan mycket göras parallellt, och egentligen bör allt göras parallellt i någon utsträckning.

När du arbetar med webbplatsens övergripande mål känner du i ett befintligt företag vanligtvis redan till vilka kunderna är och vilka typer av personer som kommer att besöka webbplatsen. Du kan börja arbeta med användarberättelser och samtidigt göra anteckningar om webbplatsens struktur. Vid en redesign är det ofta klokt att använda den befintliga strukturen som utgångspunkt och se var den kan förbättras.

Det kan också finnas ett innehållsteam där olika avdelningar går igenom sina texter och bestämmer vad som ska slås samman, tas bort eller uppdateras. Allt detta kan genomföras parallellt.

När det gäller agila och iterativa arbetssätt hjälper de framför allt till med intressenthanteringen. Du vill så snabbt som möjligt få fram något som intressenterna och beslutsfattaren kan se med egna ögon. Många ledare vill inte vara involverade i projektets dagliga arbete, och det är ofta rimligt. Men om du bokar ett tillfälle där de kan se framstegen och webbplatsen på en skärm kommer de att delta. Då får du värdefull återkoppling.

Ju tidigare du får den återkopplingen, desto bättre. Du vill inte fatta ett designbeslut som påverkar resten av webbplatsen och sedan upptäcka i slutet att en person på ledningsnivå inte ville ha det så. Ibland är ett mer stegindelat arbetssätt bättre, men enligt min erfarenhet är det oftast inte det.

Ben Aston

Användartestning kan också vara mycket hjälpsamt. I ett projekt för en företagswebbplats identifierar vi personas tidigt: Vem bygger vi för? I företagsprojekt blandas detta snabbt ihop med frågan om att tillfredsställa en chefs ego. Det kan vara ett outtalat mål, men på något sätt måste även det formaliseras.

Poängen med personas är att vi kan skapa samsyn med kunden kring varför projektet genomförs och vilket målet är. På många företagswebbplatser finns någon som säger: ”På startsidan är det viktigaste att berätta om det fantastiska som vår vd just gjorde.” Då kan man fråga: ”Varför behöver alla veta det när ni är ett bredbandsföretag?”

Rich Butkevic

Absolut.

Ben Aston

För någon kan det ändå vara viktigast, eftersom personen kanske får en befordran eller löneökning om vd:n framstår i god dager. Det finns uttalade och outtalade mål. Personas hjälper oss att styra besluten om varför vi placerar saker där vi placerar dem.

Nästa steg är användartestning. Vi kan säga: ”Här är våra personas. Låt oss testa det vi har skapat med dem.” Vi ger dem konkreta uppgifter, till exempel: ”Du vill skaffa ett nytt bredbandspaket. Hur gör du?” Sedan visar vi webbplatsen, informationsarkitekturen och wireframes och ber dem hitta rätt paket.

Om de säger: ”Jag ser den stora informationen om vd:n och att personen har arbetat i 15 år, men jag hittar inte hur jag konfigurerar mitt bredbandspaket”, har vi något konkret att gå tillbaka till företaget med. Då kan vi föreslå att bannern på startsidan ska handla om bredbandskonfiguratorn i stället för vd:n.

Rich Butkevic

Det är ett bra exempel, och sådant händer hela tiden. Vid användartestning är det viktigt att de personer du tar in verkligen representerar de kundprofiler du identifierade tidigare. Om du säljer hemförsäkring ska du inte testa med personer som inte äger en bostad eller med tonåringar. De som deltar måste vara bra representanter för webbplatsens faktiska användare.

Många företag använder sina egna medarbetare i användartester, vilket oftast är en dålig idé. Personer som arbetar på företaget känner verksamheten, målen och branschens jargong mycket bättre. Du vill inte genomföra tester som verkar lyckade för att sedan upptäcka att allmänheten inte förstår vad bredband betyder. Då klickar de kanske aldrig på länken och går i stället till en konkurrent som använder uttrycket höghastighetsinternet.

Ben Aston

Nu har vi talat länge om upptäckt, planering och design. Låt oss prata om själva bygget. Du har mycket erfarenhet av de tekniska delarna i att leda en företagswebbplats. Att designa webbplatser och få dem att uppfylla målen vi satte i början är svårt. Designen är avgörande om vi vill öka konverteringar och nå våra nyckeltal. Men det finns ett avstånd mellan att designen är rätt och att webbplatsen fungerar tekniskt som den ska.

Vilka är dina bästa råd för att leda byggprocessen i ett projekt för en företagswebbplats? Vad bör en projektledare som gör detta för första gången tänka på när ett team av utvecklare ska ledas?

Rich Butkevic

Det viktigaste är att komma ihåg att utvecklarna oftast inte har särskilt stor erfarenhet inom just det här området, eller åtminstone inte av migreringen. De kan ha erfarenhet av att hantera webbplatsen när den väl är igång, men inte av alla tekniska detaljer kring en migrering.

En sak är HTTPS-omdirigering. Nästan alla webbplatser, särskilt företagswebbplatser, ska vara säkra så att trafiken krypteras. Du måste säkerställa att en begäran som kommer via HTTP, eller utan HTTPS, skickas till den säkra versionen av sidan. Detta blir ofta fel på många olika sätt.

URL:en måste skrivas om korrekt. Annars kan sökmotorer uppfatta att det finns två versioner av webbplatsen: en HTTP-version och en HTTPS-version. Det kan skapa problem med duplicerat innehåll. Analysverktyg kan också spåra de två versionerna separat, vilket gör det svårt att koppla ihop konverteringar och andra händelser.

En annan sak gäller lanseringen när DNS ska uppdateras. DNS är systemet som översätter ett webbplatsnamn, som Google, till en IP-adress så att webbplatsen kan hittas på internet. Det kan visa sig att personen som ska göra DNS-uppdateringen inte har åtkomst till domänregistratorn.

Åtkomsten är ofta strikt begränsad eftersom den som har tillgång till företagets rotdomän måste hållas ansvarig. Men du måste säkerställa att rätt personer har den åtkomst de behöver. Projektledningen måste också förstå att en DNS-ändring behöver tid för att spridas till servrar över hela internet.

Det jag försöker undvika är att gå live och skicka ett e-postmeddelande till intressenterna där vi säger: ”Hurra, vi har gjort alla uppdateringar!” för att sedan få mängder av svar som säger: ”Det fungerar inte för mig.” Ofta kommer det att fungera om 15 minuter; ändringen har bara inte spridits ännu. Det minskar onödig panik på lanseringsdagen.

Ben Aston

Det finns många viktiga råd inför lanseringen som måste tänkas igenom långt i förväg. Vi kan vara så uppslukade av utvecklingen att vi två veckor före lansering tänker att vi har gott om tid. Dagen före upptäcker vi kanske att ingen vet inloggningsuppgifterna och att personen som känner till dem har åkt på semester.

Det är bra råd för den som ska lansera en företagswebbplats. Men jag vill återgå till utvecklingsprocessen. Efter designprocessen måste webbplatsen byggas på något sätt.

Rich Butkevic

Absolut.

Ben Aston

Hur leder man utvecklare om man inte är teknisk? En projektledare kan vara mycket bra på att leda processen för användarupplevelse och design men mindre bra på att leda utvecklare. Hur gör man när utvecklarna skriver kod och säger att arbetet är klart, men egentligen menar att de planerar att göra det?

Rich Butkevic

Det är här ett iterativt arbetssätt blir särskilt användbart. Du får möjlighet att se något som fungerar eller inte fungerar i en demonstration på skärmen. Det är min första rekommendation eftersom du snabbt kan upptäcka problem och se om utvecklingen går framåt som den ska.

Det andra är att inte ha stora mellanrum mellan möten och uppdateringar. Jag vill inte ha möten bara för mötenas skull, men ett fem minuter långt dagligt eller varannan dag ståmöte kan vara mycket hjälpsamt. Det är vanligt i Scrum men inte exklusivt för Scrum. Oavsett utvecklingsmodell bör du hålla saker aktuella, följa upp ofta och lösa problem snabbt.

Ben Aston

Momentum är viktigt. Vi måste fortsätta ha demonstrationer och bygga något som går att se. I slutet av veckan vill vi kunna se något som fungerar och utvärdera det. En utvecklare kanske säger att bara navigeringsfältet är byggt. Då tittar vi på det och upptäcker kanske att det fungerar på datorn men inte på mobilen. Då kan vi åtgärda problemet tidigt.

Regelbundna sprintdemonstrationer, visning av pågående arbete och dagliga avstämningar hjälper oss att undvika utvecklingens dimma – situationen där utvecklarna försvinner iväg i sex veckor och vi sedan upptäcker att allt inte blev rätt.

För den som bara lyssnar med ett halvt öra i bilen: vi har pratat om upptäckt, planering, design, utveckling och lansering. Det är mycket att komma ihåg. Vilken är den enklaste lärdomen för den som ska leda eller redan leder ett projekt för en företagswebbplats? Hur ser vi till att projekten lyckas och hålls under kontroll, särskilt när det gäller budget och tidsplan?

Rich Butkevic

Det är en kombination av mycket av det vi redan har talat om. Ha ett bra samarbete och använd gärna ett verktyg som underlättar det. Dagliga ståmöten är viktiga och hjälper till att upptäcka många problem tidigt. Ju kortare återkopplingsslingan är, desto bättre.

I ett agilt arbetssätt bryts återkopplingen ner i exempelvis tvåveckorsperioder där du visar något verkligt. Det kan sedan brytas ner ytterligare i dagliga ståmöten där du får uppdateringar och återkoppling. Med Slack eller ett annat samarbetsverktyg behöver ingen vänta till nästa dag eller två veckor senare med att ta upp ett problem.

Det viktigaste rådet är att du före lansering genomsöker webbplatsen efter brutna länkar. Det identifierar många problem som människor annars missar. Det är enkelt och jag ser sällan att det görs. Som projektledare brukar jag veckan före lansering genomsöka webbplatsen för att hitta brutna länkar. Det kan avslöja problem med kodningen, webbplatsens organisation eller tekniska lösningar.

Ben Aston

Har du några tips om vad man kan använda för att genomsöka webbplatsen?

Rich Butkevic

Inte direkt. De fungerar ungefär på samma sätt. Jag skulle söka på internet efter något som kontrollerar länkar.

Ben Aston

Något i stil med en sådan kontroll.

Rich Butkevic

Det beror på om du bygger en helt ny webbplats eller gör en redesign och på om verktyget måste kunna köras internt i nätverket eller utanför det. Det finns vissa detaljer, men de är mindre viktiga. Oavsett hur du gör bör du se till att det blir gjort eftersom det ger stor effekt.

Ben Aston

Tack så mycket för att du var med, Rich. Det mest värdefulla vi har pratat om är den tidiga delen av projektet: att få briefen rätt och definiera mål och syften tydligt från början. Allt annat bygger vidare på det. En annan viktig del är vad som händer efter lanseringen. Om vi har hållit målen i fokus under hela projektet blir det enklare att utvärdera resultatet, avkastningen och värdet. Att börja rätt är mycket viktigt.

Rich Butkevic

Tack, Ben. Det har varit fantastiskt att vara här med dig.

Ben Aston

Det har varit fantastiskt att ha dig med. Vad tycker du? Vilka knep, tips och metoder använder du när du bygger webbplatser? Vad har fungerat och vad har inte fungerat? Om du har misslyckanden eller framgångar får du gärna berätta i kommentarerna. Om du vill lära dig mer och utvecklas i ditt arbete kan du gå med i vår gemenskap genom DPM-medlemskapet.

Där hittar du alla möjliga bra resurser, bland annat projektplaner för stora webbplatsbyggen med olika metoder, sprintar eller ett mer vattenfallsbaserat arbetssätt. Besök thedigitalprojectmanager.com/membership.

Du får tillgång till vårt Slack-team, mallar, workshops, rådgivningstider, e-böcker och mycket mer. Om du tyckte om det du hörde i dag får du gärna prenumerera, ta några minuter och lämna en ärlig recension. Tack för att du lyssnade. Vi hörs nästa gång.