Varför projektuppstarter misslyckas med dem som ansluter senare

Versionen där vi samlar alla kända intressenter, enas om en ledstjärna, hugger fast vårt angreppssätt i sten och sedan ger oss av tillsammans med antagandet att den rörelseenergi vi skapade den dagen på egen hand ska bära projektet från början till slut.

Verkligheten är att förändring är oundviklig, och de flesta teams arbetssätt för projektstarter är faktiskt trasiga. 

Och det kommer att börja spela stor roll i den AI-drivna ekonomi med fraktionerade arbetsroller som vi är på väg in i.

Varför en bra projektstart inte garanterar ett bra projekt

Jag brukade tro att min förmåga att leda bra projektstarter var min orättvisa fördel som PM. När jag startade mina projekt rusade teamen iväg med tydlighet och momentum i stället för förvirring och ännu fler obesvarade frågor.

Faktum är att människor brukade komma fram till mig efter ett uppstartsmöte och be att få låna min agenda eller presentation så att de kunde använda den i sina projekt. Det var något jag var stolt över.

Men sedan hände något som förändrade hela min syn på projektstarter.

I ett av mina projekt slets viktiga teammedlemmar bort och tilldelades andra projekt – utan tid för ordentlig kunskapsöverföring. De duktiga personer som klev in var också mycket kompetenta, men de kände att de började i underläge och levde i skuggan av det som redan hade hänt. De inledde varje samtal med förbehåll som ”men jag var inte här när projektet startade” eller ”jag håller fortfarande på att komma ikapp här, låt inte mina idéer få era planer att spåra ur”.

För de nya teammedlemmarna handlade det inte om att de saknade informationen, befogenheten eller ens idéerna. Det handlade om att de inte kände att de hade ägarskap.

Och utan det ägarskapet försvann kraften ur projektet. Uppdraget var inte deras eget. De kände sig som vikarierande lärare som tvingats ta ansvar för situationen – offer för sina omständigheter med liten möjlighet att påverka eller kontrollera något.

Tyvärr hade jag inte förstått det då. 

Problemet med kunskapsöverföring

På den tiden verkade lösningen enkel: få bara de nya personerna uppdaterade. För över kunskapen till deras hjärnor. Eller hur?

Det finns trots allt gott om briefar, omfångsbeskrivningar och kravdokument – för att inte tala om projektstartspresentationen och resultaten från visionsövningarna. 

Men även när alla projektdokument är prydliga och organiserade kan den nya teammedlemmens upplevelse av att sätta sig in i ett berg av löst strukturerad information kännas som att ägna sig åt kriminalteknisk bokföring med en pistol mot huvudet.

Visst kan nya teammedlemmar ställa frågor, men de vet inte vad de inte vet. Och för det mesta känner de sig ännu inte bekväma med att ställa de ”dumma” frågorna av rädsla för det fruktade svaret: ”det stod i dokumenten, såg du inte det?”

Det skapade en cykel där nykomlingarna förblev vilsna längre – vilket bara gjorde projektet svårare att styra.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Create Free Account

Have an account? Log In

Problemet med dokumenthygien

Och dessutom insåg jag varje gång jag introducerade en ny teammedlem i mitt projekt att små detaljer – ibland till och med stora detaljer – i våra fantastiska dokument inte längre stämde överens med projektets aktuella läge.

Sedan projektstarten hade hundratusentals mikrobeslut fattats. Inte de stora besluten som man för in i en beslutslogg – utan de små som slinker igenom sprickorna när dokumentationen uppdateras.

Jag fann mig själv med att förklara avvikelser, utveckla små nyanser och återberätta informella samtal mellan teammedlemmar som vi aldrig hade tänkt på att dokumentera. 

Hastighetsproblemet

Hade jag kunnat mildra allt detta genom att använda ett ”faddersystem” där en ny person parade ihop sig med en kollega i projektet? Tro mig, jag försökte. Men även det misslyckades, eftersom projektet inte hade råd att låta en teammedlem ge stöd på deltid.

Vi arbetade redan i ett rasande tempo och hade inte råd att sakta ner. Deadlines närmade sig, pressen ökade, synligheten blev större och förväntningen var att teamet skulle arbeta snabbare när fler personer tillkom, inte långsammare.

Så i stället för att sakta ner tempot fortsatte jag som vanligt: med den version där personer som ansluter mitt under projektet fastnar i att jag hoppar in i en bil i rörelse och sticker handen i elden.

Tillhörighetsproblemet

Men när jag fortsatte att febrilt kasta dokument och mötesinbjudningar på personer som lades till i projektet – samtidigt som teamet tanklöst bläddrade igenom uppgifter  från backloggen – blev något mycket tydligt: det handlade inte om information. Det handlade om tillhörighet. Och det är ett känslomässigt tillstånd som inte kan uppnås genom dokumentation enbart. 

Jag kunde inte få nya teammedlemmar att känna sig som en del av gruppen bara genom att lugna dem eller prata mer med dem. Inget kompissystem skulle lösa detta. Inga schemalagda möten av typen ”fråga mig vad som helst” skulle få saker och ting att falla på plats. Det behövdes trygga och alternativa utrymmen.

Människor hittar tillhörighet på olika sätt i olika sammanhang: vissa vill ha lugn och ro med dokumentation innan de pratar med teamet; vissa vill ha en kompis; vissa vill ha ett tryggt utrymme där de kan ställa de ”dumma” frågorna; och vissa vill helt enkelt förstå ”varför” bakom uppdraget och sin roll i det. 

Det är det jag borde ha lagt min tid och energi på att bygga: ett ramverk som låter teammedlemmar hitta tillhörighet på sina egna villkor. 

I slutändan investerade jag för mycket i uppstartsritualen och lämnade sedan de som anslöt mitt under projektet åt sitt öde.

Den här cykeln av otillräcklig introduktion frustrerar inte bara individer — den undergräver hela projektet. När nykomlingar inte snabbt kan komma in i arbetet saktar beslutsfattandet ner, misstagen blir fler och teamets moral försämras.

Och när förändring är oundviklig — när teammedlemmar byts ut under ett projekts hela livscykel — blir den här metoden ohållbar.

För de nya teammedlemmarna handlade det inte om att de saknade informationen, befogenheten eller ens idéerna. Det handlade om att de inte kände att de hade ägarskap.

Ett annat sätt att tänka på uppstarter: kontinuerlig introduktion

Så vad är då svaret? Om vi investerar för mycket i uppstarter och för lite i förändringshantering och introduktion mitt under projektet, hur kan vi korrigera det?

Jag hade mina hypoteser, men jag fick också en aha-upplevelse tack vare någon jag har stor respekt för, som sa:

”Jag upprepar alltid fokus nästan vid varje möte eftersom ’ledstjärnan’ hela tiden skiftar. Det påminner mig om hur vi tränar kung fu … Det finns en central punkt som vi fokuserar på att kontrollera, och utanför den är allt sammanhang för att återvända till den sanningen. Det är ett samtal där båda sidor ’ställer frågor’ och tar emot svar i realtid med alla sinnen.”

Med andra ord kan vi, i stället för att förlita oss på den stora uppstartsbravuren, använda varje interaktion för att förstärka kärnan i det som är viktigt i projektet. Det är inbyggt i själva samarbetet i stället för att vara en stor fest som det är lätt att känna att man har missat om man inte var där.

Så här är vad jag har försökt göra för varje projekt sedan dess: 

1. En policy för lätt och lättuppdaterad dokumentation

Jag har skrotat mina snygga presentationsbilder för uppstarter och mina välpolerade projektdokument (projektbeskrivningar, statusrapporter, mötesagendor, RAID-loggar), och prioriterar i stället att ha saker i ett format som är lätt att uppdatera och lätt för mänskliga eller AI-baserade teammedlemmar att läsa.

Sedan arbetar jag med projektteamen för att utse ansvariga för dokumentuppdateringar — precis som vi skulle göra för riskansvariga. Det fördelar arbetsbördan och ger teammedlemmarna möjlighet att driva på för korrekt dokumentation.

Som exempel har vi enkla och kortfattade dokument i Notion eller Slite för teamroller och ansvarsområden, vår projektbeskrivning och våra kommunikationsplaner för projektet. Ingenting är låst i kalkylblad eller PDF-filer.

2. Kontinuerlig introduktion som en accepterad realitet

Tillsammans med dokumentationen har jag ända från början hanterat förväntningarna med teamet genom att tydliggöra att teamen, målen och annat runt projektet kan förändras på ett ögonblick, och att vi då måste sluta upp.

Med andra ord: i stället för att hoppas och be att team och mål inte ska förändras, utgå från att de kommer att förändras.

Det innebär att så lite som möjligt ska vara låst i människors hjärnor eller hänvisat till ett specifikt ögonblick. Möten har transkriberingar, talarnas anteckningar finns tillgängliga i skriftlig form, de flesta projektsamtal förs i offentliga kanaler och beslut loggas noggrant. 

Det bidrar till att säkerställa att personer som missade projektets första dag fortfarande har tillgång till information om de behöver den. Det hjälper oss också att byta riktning som en flock sånglärkor om något av projektets mål eller omständigheter förändras.  

3. AI som sanningskälla för alla neurotyper

Tillsammans med det konfigurerar mina team och jag AI-chattbotar eller sökbara kunskapsbaser för projektet så tidigt som möjligt. 

I många fall är det inte lika sofistikerat som man kanske drömmer om när det gäller AI, men det gör något som är mycket viktigt för oss: det skapar ett relativt privat, tryggt och  mindre politiserat sätt för teammedlemmar att ta del av projektinformationen — på sina egna villkor och på det sätt de själva föredrar att lära sig. 

Dessa chattbotar matas med strukturerad och ostrukturerad projektdata redan från allra första början – projektunderlag, SOW:er, statusrapporter, mötesprotokoll och vissa teamsamtal. Och eftersom dokumentationen är tillräckligt lättviktig för att mänskliga teammedlemmar ska kunna hålla den uppdaterad, är det relativt enkelt för en AI att hålla reda på vad som har förändrats under projektets gång – beslut som har fattats, budget som har lagts till, problem som har uppstått, risker som har blivit verklighet, eskaleringar som har ägt rum, osv. 

Sedan skulle alla teammedlemmar när som helst kunna ställa frågor till den chattboten i ett sammanhang där de inte behöver vara rädda för att verka dumma och utan att behöva boka ett möte med en auktoritetsperson som redan har ont om tid.

En teammedlem kan till exempel ställa frågor som:

• ”Hur bidrar min uppgift till projektets övergripande mål?”
• ”Vem är beroende av att jag slutför min leverans i tid?”
• ”Var ska jag spara mina slutliga leveranser, och vilken namngivningsstandard har vi för filer?”

Det här kan vara frågor som de redan vet svaret på, men de kanske vill få det bekräftat när de växlar mellan projekt och andra uppgifter. 

I slutändan effektiviserar AI-chattbotar processen för att få tillgång till information, ökar effektiviteten genom att eliminera behovet av omfattande utbildning eller konsultation med flera källor och förbättrar tillgängligheten genom ett användarvänligt gränssnitt som kan nås från alla enheter med internetanslutning dygnet runt, alla dagar i veckan.

Men här är haken: AI har visat sig kunna ha fel.

Och om den har fel kan det snabbt få ett projekt ur kurs. Den övergripande konsekvensen skulle bli ett extra steg: prova att fråga chattboten, granska svaret eftersom det kan vara fel, och använd sedan magkänslan för att avgöra om du ska lita på svaret du fick utan att fråga någon annan, eller hitta en kollega att fråga – med andra ord, när vi inte litar på AI är vi tillbaka på ruta ett.

Så datan måste vara tillräckligt ren för att inte vara motsägelsefull. Och sedan måste människorna i teamet faktiskt lita på att den är korrekt (förutsatt att vi inte har matat in felaktig information).

För att bidra till detta är vår prioritet att säkerställa så hög noggrannhet som möjligt, där viktiga teammedlemmar fungerar som förespråkare för och granskare av kvalitet genom några testfall och stickprovskontroller som vi genomför regelbundet. 

4. Rituell förstärkning av mål

Och för att knyta ihop allt har jag försökt ta några av mina favoritelement från den tragiskt ”ögonblicksbaserade” projektuppstarten och väva in dem i det dagliga arbetet. Sådant som att upprepa och ständigt utmana produktvisionen eller BHAG så att uppdraget är tillräckligt väl förstått för att kunna granskas, så att vi kan säkerställa att vi fortfarande bygger rätt sak. 

Jag försöker till exempel påminna människor om projektets önskade resultat i början av varje teammöte. Något i stil med: "Som en påminnelse kommer det här projektet att hjälpa kollektivtrafikresenärer med olika funktionsförmågor att ta sig dit de ska på ett säkrare sätt och med mindre frustration."

Och om den ledstjärnan har förändrats försöker jag också formulera om den vid varje möte eller statusuppdatering: "Som en påminnelse började det här som ett initiativ för kollektivtrafikresenärer med funktionsnedsättning, men nu är det en möjlighet att förbättra upplevelsen för alla kunder i flera kollektivtrafiknät."

En annan sak jag gör är att använda min roll som generalist för att ställa frågor som styr besluten mot vårt mål. Om teamet till exempel försökte välja mellan två tillvägagångssätt skulle jag fråga något i stil med: "Vilket av dem hjälper oss att minska mest friktion i kundupplevelsen?"

När det gäller saker som teamvärderingar och arbetssätt väljer jag att avsluta mötena med en sådan påminnelse: "Glöm inte att hålla viktig kommunikation i den gemensamma kanalen om den kan hjälpa andra att utföra sitt arbete."

Det gör inte bara att personer som ansluter mitt i projektet känner mindre att de missade något i början, utan bidrar också till att kontinuerligt förstärka uppdraget hos alla era intressenter.

5. En kultur av tillhörighet

Men viktigast av allt försöker jag förändra mitt tankesätt från ”kunskapsöverföring” till ”överföring av ägarskap” genom att prioritera sätt att hjälpa nya teammedlemmar eller intressenter att känna att de ”hör hemma” i projektet och kan bidra med hela sig själva.

Enligt min mening finns det inget enda, idiotsäkert sätt att göra detta på, men jag är övertygad om att lösningen inte är att överösa människor med mer information. Vi människor måste använda vår mänsklighet för att hantera sådant som är genuint mänskligt – känslor, ego, gemenskap och mening.

När människor inte känner att de har ägarskap är det mindre sannolikt att de säger ifrån när något känns fel eller ifrågasätter ett beslut som kan få projektet att spåra ur.

More Articles

• Eisenhower-matrisen: Så prioriterar du uppgifter på ett smart sätt
• Så bemästrar du resurshantering i projektledning

Varför detta är ännu viktigare nu

I dag ser jag hur problemet med introduktion mitt i projekt blir allt större. Medlemmar i min community driver projekt som präglas av en ständig rotation av deltidspecialister, frilansare och till och med heltidsanställda som smidigt flyttas mellan projekt för att hållas sysselsatta.

Samtidigt skapar AI-verktyg mer rörliga förväntningar bland projektets intressenter: projekten förväntas gå snabbare, hantera förändringar bättre och skapa större värde genom att dra nytta av data-insikter, automatisering och agentbaserat beslutsfattande. 

Med andra ord är teamen mer föränderliga och tempot ökar. Det innebär att tillhörighetsgapet blir större när allt rör sig snabbare och förändras oftare.

Och här är den verkliga risken: vi vill inte bara bygga fel sak snabbare.

När människor inte känner att de har ägarskap är det mindre sannolikt att de säger ifrån när något känns fel eller ifrågasätter ett beslut som kan få projektet att spåra ur.

Det är därför kontinuerlig introduktion inte längre är valfritt. Det är inte något som är trevligt att ha eller en mjuk kompetens. Det är en affärsmässig nödvändighet. Om vi vill ha team som kan anpassa sig och skapa verkligt värde i detta snabbare och mer fragmenterade projektlandskap behöver vi människor som känner sig engagerade i visionen, inte bara informerade om uppgifterna.

Så, är projektstarterna döda?

Projektstarter är definitivt inte döda. Inte för mig och inte för många projektteam.

Personligen älskar jag dem. Jag tycker att projektstarter är sammankomster som kan skapa band mellan människor och erbjuda forum för dialog vid ett avgörande ögonblick i ett projekts livscykel. Jag tycker att de är väldigt mänskliga. Så ja, jag fortsätter att ha projektstarter, och ni får slita vanan ur mina kalla, döda händer.

Det jag däremot gör annorlunda är att jag inte längre försöker få med alla mina förhoppningar och drömmar i projektstarterna. Jag lägger inte lika mycket energi på att göra dem felfria, glänsande och uppvisningsinriktade. Jag strävar inte efter att göra dem till den alltavgörande ceremoni som får dem som inte var med från början att känna sig som andra klassens medborgare. Och jag försöker definitivt inte göra dem till något som låser fast oss i förväntningen på en enda orubblig väg. 

För projekt går inte i en rak linje. De är som en drake i vinden, som kastas hit och dit och måste styras aktivt oavsett vad som händer. Förändring är oundviklig. Därför är det den förberedelsen vi bör lägga vår energi på.

Vad tycker du?

Men jag vill också höra från dig: är projektstarter så problematiska som jag har fått dem att framstå? Hur tänker du kring introduktion i dina projekt, särskilt när teammedlemmar ansluter efter att projektet redan har startat?