Hvorfor projektopstarter svigter dem, der kommer med senere

Den version, hvor vi samler alle kendte interessenter, bliver enige om en ledestjerne, mejsler vores tilgang i sten og derefter sætter i gang sammen med en antagelse om, at den kinetiske energi, vi skabte den dag, alene vil bære projektet fra start til slut.

Virkeligheden er, at forandring er uundgåelig, og de fleste teams tilgang til projektopstartsmøder er faktisk ødelagt. 

Og det kommer til at få stor betydning i den AI-drevne økonomi med deltidsansatte og midlertidige medarbejdere, som vi er på vej ind i.

Hvorfor et godt opstartsmøde ikke garanterer et godt projekt

Jeg plejede at tro, at min evne til at lede gode projektopstartsmøder var min unfair fordel som PM. Når jeg satte mine projekter i gang, kom teams flyvende fra start med klarhed og momentum i stedet for forvirring og endnu flere ubesvarede spørgsmål.

Faktisk kom folk hen til mig efter et opstartsmøde og bad om at låne min dagsorden eller præsentation, så de kunne bruge den til deres egne projekter. Det var noget, jeg var stolt af.

Men så skete der noget, som ændrede hele min måde at tænke på opstartsmøder på.

På et af mine projekter blev centrale medlemmer af mit team revet væk og allokeret til andre projekter — helt uden tid til ordentlig vidensoverførsel. De dygtige mennesker, der trådte til, var også meget kompetente, men de følte, at de startede med et handicap og levede i skyggen af det, der allerede var sket. De tog forbehold i enhver samtale med sætninger som "men jeg var her ikke, da projektet startede" eller "jeg er bare ved at indhente det forsømte her, så lad ikke mine idéer få jer til at afvige fra jeres planer."

For de nye teammedlemmer handlede det ikke om, at de manglede information, bemyndigelse eller selv idéer. Det handlede om, at de ikke følte, at de havde ejerskab.

Og uden det ejerskab forsvandt vinden fra sejlene. Missionen var ikke deres egen. De følte sig som vikarer, der var fanget med ansvaret — ofre for deres omstændigheder med meget lidt indflydelse eller kontrol.

Desværre havde jeg ikke indset det endnu. 

Problemet med vidensoverførsel

På det tidspunkt virkede løsningen enkel: Få bare de nye mennesker op i fart. Overfør viden til deres hjerner. Ikke?

Der er trods alt masser af briefinger, omfangsbeskrivelser og kravdokumenter — for ikke at nævne præsentationen fra opstartsmødet og resultaterne fra visionsøvelser. 

Men selv når alle projektdokumenterne er ryddelige og organiserede, kan oplevelsen for det nye teammedlem af at skulle sætte sig ind i et bjerg af løst struktureret information føles som at lave retsmedicinsk regnskabsanalyse med en pistol for panden.

Selvfølgelig kan nye teammedlemmer stille spørgsmål, men de ved ikke, hvad de ikke ved. Og det meste af tiden føler de sig endnu ikke trygge ved at stille de "dumme" spørgsmål af frygt for at få det frygtede svar: "det stod i dokumenterne, så du det ikke?"

Det skabte en cyklus, hvor nytilkomne forblev fortabte i længere tid — hvilket kun gjorde projektet sværere at styre.

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.

Get Free Access

Have an account? Log In

Problemet med vedligeholdelse

Oveni det indså jeg hver gang, jeg onboardede et nyt teammedlem til mit projekt, at små detaljer — pokkers, nogle gange store detaljer — i vores ellers fantastiske dokumenter ikke stemte overens med projektets aktuelle status.

Siden opstartsmødet var der blevet truffet hundredtusindvis af mikrobeslutninger. Ikke de store beslutninger, som man fører i en beslutningslog — men de små, der smutter gennem sprækkerne i dokumentationsopdateringerne.

Jeg fandt mig selv i gang med at forklare uoverensstemmelser, uddybe små nuancer og viderebringe uformelle samtaler mellem teammedlemmer, som vi aldrig havde tænkt på at registrere. 

Hastighedsproblemet

Kunne jeg have afbødet alt dette ved at bruge et "makker-system", hvor en ny kollega blev sat sammen med en ligestillet på projektet? Tro mig, jeg prøvede. Men det faldt også til jorden, fordi projektet ikke havde råd til at have et teammedlem til at yde support på deltid.

Vi arbejdede allerede i et hæsblæsende tempo, og vi havde ikke råd til at sætte farten ned. Deadlines nærmede sig, presset steg, synligheden øgedes, og forventningen var, at teamet skulle arbejde hurtigere, efterhånden som flere mennesker blev tilføjet — ikke langsommere.

Så i stedet for at sænke tempoet fortsatte jeg som hidtil: med den version, hvor folk, der kommer med midt i projektet, sidder fast i at springe ind i en bil i bevægelse og stikke hånden ind i ilden.

Problemet med at høre til

Men efterhånden som jeg fortsatte med febrilsk at kaste dokumenter og mødeinvitationer efter de mennesker, der blev føjet til projektet — og efterhånden som teamet tankeløst bladrede gennem opgaver  fra backloggen — blev én ting meget tydelig: Det handlede ikke om information. Det handlede om at høre til. Og det er en følelsesmæssig tilstand, der ikke kan opnås gennem dokumentation alene. 

Jeg kunne ikke få nye teammedlemmer til at føle, at de hørte til, bare ved at berolige dem eller tale mere til dem. Intet makkersystem ville løse dette. Ingen møder med en fastlagt “spørg mig om hvad som helst”-dagsorden ville få tingene til at glide lettere. Der var brug for trygge og alternative rum.

Folk finder tilhørsforhold på forskellige måder i forskellige sammenhænge: Nogle ønsker ro til at læse dokumentation, før de taler med teamet; nogle ønsker en makker; nogle ønsker et trygt rum til at stille de “dumme” spørgsmål; og nogle ønsker bare at forstå “hvorfor” bag missionen og deres rolle i den. 

Det var det, jeg burde have investeret min tid og energi i at opbygge: en ramme, der lader teammedlemmer finde tilhørsforhold på deres egne præmisser. 

I sidste ende investerede jeg for meget i opstartsceremonien og lod derefter dem, der kom med midt i projektet, klare sig selv.

Denne cyklus med utilstrækkelig onboarding frustrerer ikke kun enkeltpersoner — den underminerer hele projekter. Når nytilkomne ikke hurtigt kan komme op i fart, bliver beslutninger forsinkede, fejlene bliver flere, og teamets moral lider.

Og når forandring er uundgåelig — når teammedlemmer skifter ind og ud gennem et projekts levetid — bliver denne tilgang uholdbar.

For de nye teammedlemmer handlede det ikke om, at de manglede informationen eller autoriteten eller sågar idéerne. Det handlede om, at de ikke følte, at de havde ejerskab.

En anden måde at tænke på opstartsmøder: Kontinuerlig onboarding

Så hvad er svaret? Hvis vi overinvesterer i opstartsmøder og underinvesterer i håndtering af forandringer og onboarding midt i projektet, hvordan kan vi så rette op på det?

Jeg havde mine hypoteser, men jeg fik også et aha-øjeblik fra en person, jeg har stor respekt for, som sagde:

"Jeg gentager altid fokuspunktet næsten ved hvert møde, fordi 'den ledende stjerne' hele tiden flytter sig. Det minder mig om, hvordan vi træner kung fu … Der er et centralt punkt, som vi fokuserer på at kontrollere, og uden for det er alt sammen kontekst for at vende tilbage til den sandhed. Det er en samtale, hvor begge sider 'stiller spørgsmål' og modtager svar i realtid med alle sanser."

Med andre ord kan vi i stedet for at stole på den store festlige opstart bruge enhver interaktion til at understrege essensen af det, der er vigtigt i projektet. Det er indbygget i selve samarbejdet i stedet for at være en stor fest, som det er let at føle, man er gået glip af, hvis man ikke var der.

Så her er, hvad jeg har forsøgt at gøre for hvert projekt siden: 

1. En politik for let og nemt opdaterbar dokumentation

Jeg har droppet mine flotte opstartspræsentationer og meget gennemarbejdede projektartefakter (briefs, statusrapporter, mødedagsordener, RAID-logge) og prioriterer i stedet at have tingene i et format, der er nemt at opdatere og nemt for menneskelige eller kunstige teammedlemmer at læse.

Derefter arbejder jeg sammen med projektteams om at udpege ansvarlige for opdatering af dokumenter — ligesom vi ville gøre med risikoejere. Det fordeler arbejdsbyrden og giver teammedlemmer mulighed for at være fortalere for præcis dokumentation.

Som eksempel har vi enkle, kortfattede dokumenter i Notion eller Slite om teamroller og -ansvar, vores projektbrief og vores kommunikationsplaner for projektet. Intet er låst fast i regneark eller PDF'er.

2. Kontinuerlig onboarding som en accepteret sandhed

Sammen med dokumentationen har jeg fra starten af afstemt forventningerne med teamet om, at teamene, målene og det øvrige omkringliggende i projektet kan ændre sig med et øjebliks varsel, og at vi bliver nødt til at samle os.

Med andre ord: I stedet for at håbe og bede til, at teams og mål ikke ændrer sig, skal vi antage, at de vil ændre sig.

Det betyder, at så lidt som muligt er fastlåst i folks hukommelse eller henlagt til et bestemt tidspunkt. Møder har udskrifter, talernes noter er tilgængelige i skriftlig form, de fleste projektsamtaler foregår i offentlige kanaler, og beslutninger bliver omhyggeligt logget. 

Det er med til at sikre, at personer, der gik glip af projektets første dag, stadig har adgang til oplysninger, hvis de har brug for dem. Og det hjælper os også med at skifte retning som en flok lærker, hvis nogle af projektets mål eller omstændigheder ændrer sig.  

3. AI som sandhedskilde for alle neurotyper

Samtidig konfigurerer mine teams og jeg AI-chatbots eller forespørgselsbare projektvidensbaser så tidligt i projektet som muligt. 

I mange tilfælde er det ikke så sofistikeret, som man kunne drømme om, når det gælder AI, men det gør noget virkelig vigtigt for os: Det skaber en relativt privat, tryg og  mindre politiseret måde, hvorpå teammedlemmer kan tilgå projektinformation — på deres egne præmisser og på den måde, de bedst kan lide at lære på. 

Disse chatbots fodres med strukturerede og ustrukturerede projektdata helt fra begyndelsen — briefinger, SOW'er, statusrapporter, mødereferater og nogle teamsamtaler. Og fordi dokumentationen er tilpas enkel til, at de menneskelige teammedlemmer kan holde den opdateret, er det relativt nemt for en AI at holde øje med, hvad der har ændret sig i løbet af projektet — beslutninger, der er truffet, budget, der er blevet tilføjet, problemer, der er opstået, risici, der er blevet realiseret, eskaleringer, der har fundet sted osv. 

Derefter ville alle teammedlemmer til enhver tid kunne stille spørgsmål til chatbotten i en situation, hvor de ikke behøver at bekymre sig om at virke dumme, og uden at skulle indkalde til et møde med en autoritet, der allerede har meget lidt tid.

Et teammedlem kan for eksempel spørge:

• “Hvordan understøtter min opgave det overordnede projektmål?”
• “Hvem er afhængig af, at jeg afleverer mit resultat til tiden?”
• “Hvor skal jeg gemme mine endelige leverancer, og hvad er vores navngivningskonvention for filer?”

Det kan være spørgsmål, som de godt kender svaret på, men som de gerne vil have bekræftet, når de skifter mellem projekter og andre opgaver. 

I sidste ende strømliner AI-chatbots processen med at få adgang til information, øger effektiviteten ved at fjerne behovet for omfattende oplæring eller konsultation med flere forskellige kilder og forbedrer tilgængeligheden gennem en brugervenlig grænseflade, der kan tilgås fra enhver enhed med internetforbindelse døgnet rundt.

Men her er hagen: AI har vist sig at kunne tage fejl.

Og hvis den tager fejl, kan det meget hurtigt bringe et projekt ud på et sidespor. Den overordnede konsekvens ville være et ekstra trin: Prøv at spørge chatbotten, gransk svaret, fordi det kan være forkert, og brug derefter din mavefornemmelse til at beslutte, om du vil følge det svar, du har fået, uden at spørge nogen, eller finde en kollega at spørge — med andre ord: Når vi ikke stoler på AI, er vi tilbage ved udgangspunktet.

Dataene skal altså være tilstrækkeligt rene til ikke at være selvmodsigende. Og derefter skal menneskene på teamet faktisk stole på, at de er korrekte (forudsat at vi ikke har fodret systemet med misinformation).

For at bidrage til at sikre det er vores prioritet at opnå så høj nøjagtighed som muligt, hvor centrale teammedlemmer fungerer som fortalere for og dommere over kvaliteten ved hjælp af nogle få testcases og stikprøver, som vi gennemfører regelmæssigt. 

4. Rituel forstærkning af mål

Og for at binde det hele sammen har jeg forsøgt at tage nogle af mine yndlingselementer fra den tragisk nok “øjebliksbundne” projektopstart og væve dem ind i hverdagen. Det gælder ting som at gentage og konstant udfordre produktvisionen eller BHAG, så missionen er tilstrækkeligt vel forstået til at kunne granskes, så vi kan sikre os, at vi stadig bygger det rigtige. 

Jeg forsøger for eksempel at minde folk om projektets ønskede resultater i begyndelsen af hvert teammøde. Noget i stil med: "Som en påmindelse vil dette projekt hjælpe passagerer i den kollektive trafik med forskellige funktionsniveauer med at komme mere sikkert og mindre frustreret frem til deres destination."

Og hvis den ledestjerne har ændret sig, forsøger jeg også at formulere det igen på hvert møde eller i hver statusopdatering: "Som en påmindelse begyndte dette som et initiativ for passagerer med handicap i den kollektive trafik, men nu er det en mulighed for at forbedre oplevelsen for alle kunder på tværs af flere transportnetværk."

Det andet, jeg gør, er at bruge min rolle som generalist til at stille spørgsmål, der styrer beslutningerne i retning af vores mål. Hvis teamet for eksempel forsøgte at vælge mellem to tilgange, ville jeg spørge noget i stil med: "Hvilken af dem vil hjælpe os med at fjerne mest mulig friktion fra kundeoplevelsen?"

Når det gælder ting som teamværdier og arbejdsmetoder, vælger jeg at afslutte møderne med en påmindelse om dem: "Glem ikke at holde vigtig kommunikation i den fælles kanal, hvis den kan hjælpe andre med at udføre deres arbejde."

Det får ikke kun dem, der kommer med midt i projektet, til at føle, at de er gået glip af mindre fra begyndelsen; det hjælper også med løbende at forstærke missionen hos alle jeres interessenter.

5. En kultur præget af tilhørsforhold

Men vigtigst af alt forsøger jeg at ændre min tankegang fra "vidensoverførsel" til "overførsel af ejerskab" ved at prioritere måder, hvorpå nye teammedlemmer eller interessenter kan føle, at de "hører til" i projektet og kan bidrage med hele sig selv.

Efter min mening findes der ingen enkelt, skudsikker måde at gøre dette på, men jeg tror fuldt og fast på, at svaret ikke er at hælde mere information på folk. Vi mennesker er nødt til at bruge vores menneskelighed til at håndtere de ting, der i bund og grund er menneskelige — følelser, ego, fællesskab og formål.

Når folk ikke har ejerskab, er de mindre tilbøjelige til at sige fra, når noget føles forkert, eller udfordre en beslutning, der måske sender projektet ud på et sidespor.

More Articles

• AI-stifter, der bygger en autonom virksomhed, deler, hvordan man skaber agentbaserede arbejdsgange til projektleverancer og kundesupport
• Senior IT-projektleder siger, at projektledere skal fokusere på de menneskelige interaktioner, som algoritmer ikke kan berøre
• Ekspert i projektleverancer siger, at AI afslører ødelagte videnssystemer i virksomheder
• Ekspert i projektleverancer gennemgår betingelserne for en vellykket integration af AI
• Produktleder hos AI-starthup deler de agentiske arbejdsgange, han implementerer for at strømline leveringen

Derfor er det vigtigere nu

I dag oplever jeg, at problemet med introduktion midt i projektet bliver større og større. Medlemmer af mit fællesskab driver projekter, hvor der konstant skiftes ud mellem deltidspecialister, freelancere og endda bare FTE'er, som flyttes fleksibelt mellem projekter for at holde dem beskæftiget.

Samtidig skaber AI-værktøjer flydende forventninger blandt projektets interessenter: Projekter forventes at bevæge sig hurtigere, håndtere forandringer bedre og skabe mere værdi ved at udnytte datadrevet indsigt, automatisering og agentbaseret beslutningstagning. 

Med andre ord er teamene mere omskiftelige, og tempoet accelererer. Det betyder, at tilhørsforholdskløften bliver større, når alting bevæger sig hurtigere og ændrer sig oftere.

Og her er den virkelige risiko: Vi ønsker ikke bare at bygge det forkerte hurtigere.

Når folk ikke har ejerskab, er de mindre tilbøjelige til at sige fra, når noget føles forkert, eller udfordre en beslutning, der måske sender projektet ud på et sidespor.

Derfor er løbende introduktion ikke længere valgfri. Det er ikke bare rart at have eller en blød kompetence. Det er en forretningsmæssig nødvendighed. Hvis vi ønsker teams, der kan tilpasse sig og skabe reel værdi i dette hurtigere og mere fragmenterede projektlandskab, har vi brug for mennesker, der føler sig investeret i visionen – ikke bare informeret om opgaverne.

Er projektopstarter så døde?

Projektopstarter er bestemt ikke døde. Hverken for mig eller for mange projektteams.

Personligt elsker jeg dem. Jeg synes, at projektopstarter er samlinger, der kan skabe bånd mellem mennesker og tilbyde fora for dialog på et afgørende tidspunkt i et projekts livscyklus. Jeg synes, de er meget menneskelige. Så ja, jeg holder stadig projektopstarter, og I bliver nødt til at vriste den vane ud af mine kolde, døde hænder.

Det, jeg gør anderledes, er dog, at jeg ikke længere propper alle mine håb og drømme ind i mine projektopstarter. Jeg bruger ikke længere så meget energi på at gøre projektopstarter fejlfri, skinnende og iscenesatte. Jeg stræber ikke efter at gøre dem til den altoverskyggende ceremoni, der får folk, som ikke var med fra begyndelsen, til at føle sig som andenrangsborgere. Og jeg forsøger bestemt ikke at gøre dem til noget, der låser os fast i forventningen om én enkelt, urokkelig vej. 

For projekter følger ikke en lige linje. De er som en drage i vinden, der bliver puffet rundt og aktivt må styres, uanset hvad der sker. Forandring er uundgåelig. Derfor er det dét, vi bør investere vores energi i at forberede os på.

Hvad synes du?

Men jeg vil også gerne høre fra dig: Er projektopstarter så problematiske, som jeg har fået dem til at lyde? Hvordan tænker du om introduktion på dine projekter – især når teammedlemmer kommer med midt i forløbet?