---

På Blue lägger vi mycket tid på att tänka på projektledning. Det är avgörande för vad vi gör och framgången för det vi levererar till våra kunder. Utan en solid förståelse för projektledning, hur kan vi då bygga projektledningsprogramvara?

Varje gång vi påbörjar ett nytt projekt, oavsett om det handlar om en ny funktion, en uppgradering av backend-teknik, en marknadsföringskampanj eller en rekryteringsinsats, börjar vi med att analysera själva projektet och hur det drivs. Så, med en stor mängd erfarenhet och insikter har vi beslutat att börja formaliserar några första principer för projektledning.

Även om det är vanligt (och acceptabelt) att navigera ett projekt med en mer informell, personlig magkänsla, är det knappast en skalbar metod — och inte utan sina nackdelar.

Ett Projekt

Låt oss börja med att definiera ett projekt.

Ett projekt är en tillfällig strävan med en definierad start och slut för att producera en unik produkt, tjänst eller resultat. Så här tänker de flesta på projekt. Men det finns också några andra, mer formella egenskaper hos projekt som är viktiga att överväga:

• Ett projekt har begränsade resurser (tid, pengar, människor);
• Ett projekt genomförs för att uppnå specifika mål;
• Ett projekt har ett definierat omfång (så det finns tydligt saker som det inte kommer att göra);
• Ett projekt är föremål för osäkerhet och risker.

Nu när vi har en bättre förståelse för vad ett projekt är, kan vi gå vidare till de första principerna — de grundläggande byggstenarna som ett projekt behöver för att vara framgångsrikt. Dessa inkluderar:

• En projektledare;
• Ett mål;
• En lista över saker som ska göras — detta kallas ofta en plan;
• Någon som är tilldelad att göra varje sak;
• Tidslinjer för varje sak;
• En kommunikationsstrategi med en regelbunden takt av uppdateringar och möten, och en plan för var information kommer att lagras.

Vi har funnit att dessa saker vanligtvis gäller för alla projekt och, om de görs bra, tar bort 99% av alla problem inom projekten.

En Projektledare

Det första som ett projekt behöver är någon som ansvarar för att framgångsrikt slutföra det. Detta kan verka som ett uppenbart uttalande, men det är värt att betona.

Denna person är projektledaren. De är ansvariga för att säkerställa att projektets mål uppfylls och att projektet slutförs i tid, inom budget och enligt de krav på kvalitet som ställs. Ofta blir många av oss de facto projektledare utan att vara utbildade projektledare. Om det är du, då har du tur, vi skrev en guide för det!

Det är värt att överväga vad en projektledare bör och inte bör göra. Trots allt har de mycket ansvar, och de måste ta detta ansvar på allvar.

Ofta kan projektledning ta en betydande del av projektbudgeten — vanligtvis mellan 2% och 10% av den, beroende på hur riskabelt projektet är. Ju mer risk, desto mer projektledning krävs för att säkerställa att saker hålls på rätt spår och att projektet inte misslyckas.

Eftersom de är en ledare bör projektledaren fokusera på hur man uppnår mål genom andra människor. De behöver säkerställa att projektteamet är effektivt och att de arbetar tillsammans harmoniskt mot det gemensamma målet. Projektledaren är den som måste se till att alla gör sitt jobb och att de gör det bra.

Projektledaren är också ansvarig för att kommunicera med projektets intressenter och hålla dem uppdaterade om dess framsteg.

Precis som vi diskuterade i Prioritering för Ledare, bör projektledare ständigt fokusera på begränsningspunkten. Om det tar för lång tid att få intressenter att godkänna något, då behöver de vara hyperfokuserade på att få det åtagandet. De behöver ständigt fråga sig själva, “Vad hindrar oss från att slutföra projektmålen, och hur kan jag lösa problemet så snabbt som möjligt?”

På vissa sätt är projektledning synonymt med kommunikation. Att skriva ner detaljerade idéer är en värdefull färdighet för en projektledare, eftersom det drastiskt minskar antalet möten som krävs — teammedlemmar kan självbetjäna den information som behövs.

Ett Mål

En annan grundläggande byggsten i ett projekt är att projektet behöver ett klart och mätbart mål. När projektet är avslutat bör det vara trivialt att titta på resultaten och veta om projektet uppnådde sina mål eller misslyckades.

Målen bör publiceras så att varje teammedlem har tillgång till dem. Detta är viktigt eftersom det innebär att beslutsfattande kan distribueras och decentraliseras, eftersom varje teammedlem kan titta på sin lilla del av arbetet och koppla den till projektets övergripande mål. Då kan de lyfta frågor om det finns en felaktig anpassning eller ändra sin strategi i sitt lilla område av projektet för att bäst tjäna de större målen.

Målen för ett projekt bör vara SMART:

• Specifika. Projekt har ofta övergripande mål som låter mer som mission- eller visionsuttalanden. Ett exempel på ett dåligt mål är “förbättra kundsupport”. Detta är inte tillräckligt specifikt. Något som “Vi siktar på att svara 90% av kunderna inom 30 minuter senast i Q4” är mycket mer specifikt.
• Mätbara. När du sätter specifika mål löser du vanligtvis mätproblemet samtidigt eftersom det då är lätt att bedöma om målet har uppnåtts.
• Uppnåeliga. Mål är bara meningsfulla om de kan uppnås. Men detta är inte en ursäkt för att skapa lätta mål. Ett bra mål bör ha ett inslag av utmaning — tillräckligt utmanande för att kunna nås, men inte omöjligt eller mycket osannolikt.
• Relevanta. Detta kan låta självklart, men du kommer att bli förvånad över hur ofta detta händer. Projektmålen bör kunna uppnås genom att genomföra projektet. Du kan inte sätta mål som inte kan kontrolleras av projektteamet som gör det specifika arbetet i projektet. Till exempel kan team som arbetar inom ett företags tillverkningsavdelning inte påverka kundernas upplevelse av att handla i butik.
• Tidsbundna. Bra mål behöver ha någon typ av tidsram kopplad till sig. Detta kan vara svårt, särskilt med moderna mjukvaruprojekt där arbetet som ska göras inte alltid är klart, så tidslinjer kan vara extremt svåra att uppskatta. Ibland kan du vara fel med flera gånger, och det är ingen specifik persons fel. Det sagt, att ha tidslinjer säkerställer att projektets övergripande omfattning hålls inom vissa gränser. Om du har en månad på dig att lösa ett problem jämfört med ett år, kommer du att komma fram till mycket olika lösningar.

Målen måste upprepas till alla teammedlemmar om och om igen: de bör (bildligt talat) vara sjuka av att projektledaren ständigt diskuterar målen. Några realtids (eller så nära realtid som möjligt) instrumentpaneler som spårar framsteg kan också vara ovärderliga för att säkerställa att alla är inriktade på målen och vet hur projektet fortskrider.

En Lista över Saker att Göra

Vi rekommenderar starkt att kalla en plan “en lista över saker att göra” istället, eftersom det avmystifierar planeringsprocessen.

Planer är ofta gissningar, men de är fortfarande värdefulla. Detta beror på att själva planeringsprocessen hjälper till att belysa vad vi vet och vad vi ännu inte vet.

Misslyckas med att planera, planera för att misslyckas.

Essensen av en plan är att få en detaljerad lista över alla steg för att gå från projektets början till dess framgångsrika slutförande. Vissa åtgärder kommer att kräva att tidigare steg slutförs, och så kan du hamna med en serie länkade uppgifter, ofta kallade beroenden. Andra åtgärder kan göras parallellt och blockerar inte varandra.

Projektledaren bör alltid fokusera på de viktigaste åtgärderna som blockerar andra åtgärder, eftersom detta definierar vad som kallas projektets kritiska väg. Det vill säga, den minimi mängd tid som projektet kan slutföras om alla beroenden är uppradade från början till slut.

Att arbeta med planen från båda ändar av projektet kan hjälpa enormt i att bygga en effektiv plan. Detta innebär att du börjar från början och går till slutet, men sedan börjar du också vid slutet och arbetar dig bakåt för att förstå vad som krävs för att avsluta projektet och nå målen.

Denna sista del av att vända planeringsprocessen kommer vanligtvis att avslöja missade uppgifter.

Men planeringsprocessen är inte komplett förrän vi förstår vem som är ansvarig för varje uppgift och hur lång tid varje uppgift kommer att ta att slutföra.

Dessa punkter bör täckas samtidigt eftersom de är så nära kopplade. Du kan inte skapa uppskattningar för arbete utan att involvera experterna som känner till detaljerna för dessa uppgifter, och även då måste du hålla ett öga på dina resurser. En individ kan sällan arbeta effektivt med flera saker samtidigt, så du behöver förstå om projektplanen sannolikt kommer att ha flaskhalsar. Detta är där en person inte kan slutföra alla tilldelade uppgifter eftersom de helt enkelt inte har tillräckligt med tid tillgänglig.

Någon Tilldelad att Göra Varje Sak

Varje uppgift i ett projekt behöver ha en specifik individ som ges ansvar för att slutföra den uppgiften. Om du upptäcker att du behöver flera individer tilldelade samma uppgift, har du ofta inte gått tillräckligt detaljerat för att särskilja uppgifterna.

Till exempel, i många branscher kommer det att finnas design- och byggfaser; detta kan vara inom tillverkning, byggande eller till och med mjukvara. Du bör bryta ner detta så att du kan tilldela designerens specifika uppgifter och byggarens specifika uppgifter. Du kommer ofta att se en fram-och-tillbaka mellan de två disciplinerna, vilket du kan ta hänsyn till. Ett exempel kan se ut så här:

1. Designfas 1 av Designers
2. Genomförbarhetskontroll 1 av Byggare
3. Designfas 2 av Designers
4. Genomförbarhetskontroll 2 av Byggare
5. Granskning av Senior Intressent
6. Slutförande av Design av Designers
7. Slutkontroller av Byggare
8. Godkännande av Intressenter

Detta visar en realistisk upp-och-ned mellan de olika parterna involverade, istället för att ha en “Designfas” ensam tilldelad designteamet till slutförandet av designfasen.

Tidslinjer för Varje Sak

Detta kan vara den mest utmanande delen av att skapa en plan — hur mäter vi hur lång tid varje sak kommer att ta? Som diskuterats tidigare bör tidslinjer inte göras uppifrån och ner utan nedifrån och upp. Detta innebär att varje punkt uppskattas av den person som ska utföra arbetet (eller åtminstone en kunnig kollega) och att alla dessa uppskattningar läggs till och beräknas i en övergripande tidslinje.

Det sagt, det är hjälpsamt att ha en övergripande hög nivå tidslinje innan de detaljerade uppskattningarna görs, eftersom det att uppskatta hur lång tid något kommer att ta och besluta om den specifika metoden för att lösa uppgiften i grunden är samma sak.

Så om ett projekt har generösa hög nivå tidslinjer, kan individuella experter ta hänsyn till det i sina uppskattningar och försöka optimera lösningar för det långsiktiga istället för att skära hörn för att säkerställa att tidslinjerna hålls. Om projektet har en stressad tidslinje, vet varje expert att de kan behöva göra avvägningar.

En sak som ofta glöms bort under skapandet av projektplaner är att intressenterna kommer att behöva granska framsteg och bekräfta beslut som behöver beaktas. Det bästa sättet att göra detta är att titta på det tidigare projektet som inkluderar samma uppsättning intressenter och förstå vad en typisk svarstid för dem att ge feedback är.

En annan fara här är att om det finns månatliga styrgruppsmöten med nyckelintressenter, vad händer om en projektleverans inte kan lämnas in i tid för ett av dessa möten? Stannar projektet upp tills nästa månad när intressenterna träffas igen, eller kommer detta att hanteras och godkännas (eller skickas tillbaka med feedback) mellan de månatliga styrgrupperna?

En Kommunikationsstrategi

När sådana problem uppstår bekräftar de att tillvägagångssättet för kommunikation inom ett projekt är av yttersta vikt.

Vanligtvis är problemet inte att det finns en dålig strategi utan att det inte finns någon strategi alls. Så kommunikationskanaler öppnas på ett informellt och ad-hoc sätt, och “tillräckligt bra” blir standarden.

Problemet med detta är att saker inte alltid går enligt plan. Människor förändras, kunskap går förlorad, och när projektet blir större och fler och fler människor ansluter sig kan kommunikationsöverhuvudet snabbt explodera.

Så, tydligtvis är verktygen i sig inte så viktiga; det är bara ett faktum att när du skalar förbi ett icke-trivialt antal människor (säg, 10), blir teamwork allt svårare.

Det beror på att teamkommunikation inte skalar linjärt i förhållande till antalet personer i teamet.

Till exempel, om du har ett team på 2 personer, finns det en kommunikationstråd (mellan de två individerna). Släng in en annan person i mixen; nu har du tre kommunikationstrådar. Så, medan teamstorleken har ökat med 50%, har kommunikationstrådarna ökat med 300%.

Låt oss se hur detta växer:

• 2 teammedlemmar = 1 kommunikationstråd
• 3 teammedlemmar = 3 kommunikationstrådar
• 5 teammedlemmar = 10 kommunikationstrådar
• 8 teammedlemmar = 28 kommunikationstrådar
• 10 teammedlemmar = 45 kommunikationstrådar
• 15 teammedlemmar = 105 kommunikationstrådar
• 20 teammedlemmar = 190 kommunikationstrådar
• 30 teammedlemmar = 435 kommunikationstrådar
• 50 teammedlemmar = 1,225 kommunikationstrådar
• 100 teammedlemmar = 4,950 kommunikationstrådar

Detta kan uttryckas med följande ekvation:

n(n-1)/2

Där n är antalet personer som behöver vara involverade i projektet.

Som du kan se växer detta nummer exponentiellt när teamstorleken ökar. Om du har ett team på 10 personer, måste 45 potentiella kommunikationstrådar hanteras. Men om du har ett team på 50 personer, finns det 1,225 potentiella kommunikationstrådar — det är 27 gånger mer! Och om du har ett team på 100 personer, finns det 4,950 möjliga kommunikationstrådar — det är 110 gånger mer!

Det är viktigt att notera att detta inte bara är ett problem med större team utan med vilket team som helst där individer inte befinner sig på samma plats. Detta beror på att antalet möjliga kommunikationstrådar inte begränsas av den fysiska närheten mellan teammedlemmarna.

Till exempel, du har ett team på 10 personer, men de är alla belägna på olika delar av världen. I detta fall finns det fortfarande 45 potentiella kommunikationstrådar som behöver hanteras — även om teammedlemmarna inte är fysiskt nära varandra.

Och det kan bli värre. Den ovanstående beräkningen antar bara en metod för kommunikation. Om vi vill ta hänsyn till olika metoder för kommunikation, måste vi skriva om ekvationen på följande sätt:

n(n-1)/2

Där n är antalet kommunikationskanaler.

Låt oss återta antalet kommunikationstrådar ovan, men denna gång anta att n består av:

• E-post
• Gruppchatt
• Personlig chatt
• Kommentarer i ett projektledningssystem
• Samtal
• Anteckningar/Kommentarer i dokument

När vi sätter in siffrorna får vi:

• 2 teammedlemmar = 6 kommunikationstrådar
• 3 teammedlemmar = 18 kommunikationstrådar
• 5 teammedlemmar = 60 kommunikationstrådar
• 8 teammedlemmar = 168 kommunikationstrådar
• 10 teammedlemmar = 270 kommunikationstrådar
• 15 teammedlemmar = 630 kommunikationstrådar
• 20 teammedlemmar = 1,140 kommunikationstrådar
• 30 teammedlemmar = 2,610 kommunikationstrådar
• 50 teammedlemmar = 7,350 kommunikationstrådar
• 100 teammedlemmar = 29,700 kommunikationstrådar

Det är skrämmande hur snabbt antalet kommunikationstrådar växer — och om distansarbete mer lätt möjliggör större möten som inte skulle vara praktiska i verkliga livet, är det ett tveeggat svärd.

Så, kort sagt, en strategi är avgörande för att undvika den kommunikationsexplosion som kan inträffa även med ett relativt litet antal teammedlemmar.

Och medan idén om en “kommunikationsstrategi” kan låta komplex och storslagen, behöver den inte vara det. Det viktiga är att sätta upp några principer, ange viktiga kommunikationskanaler och kanske också berätta för folk vad de inte ska göra.

Några grundläggande principer att överväga:

• Håll information öppen. Anta att allt behöver vara lätt att hitta och dela månader/år från nu. Se till att alla i projektteamet har tillgång till all nödvändig information, och var noga med att namnge filer och dokument med detta i åtanke.
• Lägg vikt vid tydlighet. Föreställ dig att någon ny går med i projektteamet. Dokumentera information tydligt och koncist för att säkerställa att de lätt kan förstå viktiga beslut.
• Håll mötesprotokoll. Se till att alla viktiga möten dokumenteras och är lätt att hitta.

När det gäller kommunikationskanaler, ju färre, desto bättre. Vi skulle föreslå att minska det till följande:

• En projektledningsprogramvara för att ha uppgiftspecifika diskussioner.
• Möten (personligen eller på distans) med mötesprotokoll och någonstans att hitta alla projektmötesprotokoll på ett ställe.
• Dokument: detta kan vara kommentarer och diskussioner inom Google Docs eller specifika verktyg (dvs. Figma för UX-design) som tillåter kommentarer.

Det är också acceptabelt att lägga till gruppchatt till denna lista — men då måste det hanteras noggrant eftersom det kan bli ett enormt möte hela dagen (och varje dag!) utan ett klart mål eller agenda.

Projektledaren behöver tydligt sätta dessa regler och vara ett lysande exempel på hur man samarbetar medan man ibland använder en käpp (metaforiskt, inte bokstavligt!) för att få projektteammedlemmar att kommunicera korrekt.

Avslutande Tankar

Oavsett ens expertisnivå är det alltid värdefullt att ta ett steg tillbaka och se ett ämne eller en process på grundläggande nivå. Så, genom att dyka djupt in i ämnet projektledning, har vi identifierat de viktigaste första principerna som krävs för att framgångsrikt genomföra ett projekt.

Varje projekt bör ha en projektledare: de säkerställer att projektet har tydliga mål, som bryts ner i uppgifter som ska slutföras för att nå det slutliga målet. Projektledaren behöver sedan tilldela en teammedlem till varje uppgift. Tillsammans kan teamet identifiera tidslinjer för varje individuell uppgift och för hela projektet.

Det är ofta de till synes självklara sakerna som kan orsaka problem, snarare än avancerade ämnen, som tenderar att få mer uppmärksamhet — till exempel kommunikation. Detta är anledningen till att det bör finnas en väldefinierad kommunikationsstrategi både inom projektteamet och externt, med intressenterna.

Projektledning är ett komplext ämne, så detta är på intet sätt en uttömmande guide. Det finns fortfarande några faktorer att överväga som vi inte har täckt i denna första översikt, såsom budgetar, metoder för att lösa konflikter mellan alternativ och hur långt man ska ta delegation inom ett projekt.