Hvorfor prosjektoppstarter svikter dem som blir med senere

Versjonen der vi samler alle kjente interessenter, blir enige om en ledestjerne, meisler tilnærmingen vår inn i stein og deretter setter av sted sammen, med antakelsen om at den kinetiske energien vi skapte den dagen, alene vil bære prosjektet fra start til slutt.

Realiteten er at endring er uunngåelig, og de fleste teamenes tilnærming til prosjektoppstarter er faktisk ødelagt. 

Og det kommer til å bli svært viktig i den KI-drevne økonomien med arbeidere som bidrar fraksjonert, som vi er på vei inn i.

Hvorfor en god oppstart ikke garanterer et godt prosjekt

Jeg pleide å tro at evnen min til å lede gode prosjektoppstarter var mitt urettferdige fortrinn som prosjektleder. Når jeg startet opp prosjektene mine, stormet teamene ut av startblokkene med klarhet og fremdrift i stedet for forvirring og flere ubesvarte spørsmål.

Faktisk kom folk bort til meg etter et oppstartsmøte og ba om å få låne agendaen eller presentasjonen min, slik at de kunne bruke den i sine egne prosjekter. Det var noe jeg var stolt av.

Men så skjedde det noe som endret hele måten jeg tenker på oppstarter på.

I ett av prosjektene mine ble sentrale medlemmer av teamet mitt revet bort og fordelt på andre prosjekter — alt uten tid til ordentlig kunnskapsoverføring. De dyktige personene som trådte inn, var også svært kompetente, men de følte at de startet med et handikap og levde i skyggen av det som allerede hadde skjedd. De tok forbehold i hver samtale med «men jeg var ikke her da prosjektet startet» eller «jeg prøver bare å komme ajour her, ikke la ideene mine spore av planene deres.»

For de nye teammedlemmene handlet det ikke om at de manglet informasjonen, myndigheten eller engang ideene. Det handlet om at de ikke følte at de hadde eierskap.

Og uten dette eierskapet forsvant piffen. Oppdraget var ikke deres eget. De følte seg som vikarer som satt fast med ansvaret — ofre for omstendighetene, med liten innflytelse eller kontroll.

Uheldigvis hadde jeg ikke innsett det ennå. 

Problemet med kunnskapsoverføring

På den tiden virket løsningen enkel: Bare få de nye personene opp i fart. Overfør kunnskapen til hjernene deres. Ikke sant?

Tross alt finnes det mengder av kortfattede prosjektbeskrivelser, omfangsbeskrivelser og kravdokumenter — for ikke å nevne oppstartspresentasjonen og resultatene fra visjonsøvelsene. 

Men selv når alle prosjektdokumentene dine er ryddige og organiserte, kan opplevelsen det nye teammedlemmet har av å sette seg inn i et fjell av løst strukturert informasjon, føles som å drive med rettsmedisinsk regnskapsføring med en pistol mot hodet.

Klart, nye teammedlemmer kan stille spørsmål, men de vet ikke hva de ikke vet. Og mesteparten av tiden føler de seg ennå ikke komfortable med å stille de «dumme» spørsmålene, av frykt for å få det fryktede svaret: «det sto i dokumentene, så du det ikke?»

Dette skapte en syklus der nykommerne forble fortapt lenger — noe som bare gjorde prosjektet vanskeligere å 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

Vedlikeholdsproblemet

På toppen av det hele innså jeg hver gang jeg introduserte et nytt teammedlem til prosjektet mitt, at små detaljer — pokker, noen ganger store detaljer — i de fantastiske dokumentene mine ikke var i tråd med prosjektets nåværende tilstand.

Siden oppstarten hadde hundretusenvis av mikrobeslutninger blitt tatt. Ikke de store som du fører inn i en beslutningslogg — de små som glipper gjennom sprekkene i dokumentasjonsoppdateringene.

Jeg oppdaget at jeg forklarte avvik, utdypet små nyanser og videreformidlet uformelle samtaler mellom teammedlemmer som vi aldri hadde tenkt på å dokumentere. 

Hastighetsproblemet

Kunne jeg ha begrenset alt dette ved å bruke et «faddersystem», der en ny person ble koblet sammen med en kollega på prosjektet? Tro meg, jeg prøvde. Men det fungerte heller ikke, fordi prosjektet ikke hadde råd til å ha et teammedlem som drev med støtte på deltid.

Vi jobbet allerede i et forrykende tempo, og vi hadde ikke råd til å sakke ned. Fristene nærmet seg, presset økte, synligheten ble større, og forventningen var at teamet skulle jobbe raskere når flere personer ble lagt til, ikke saktere.

Så i stedet for å senke tempoet fortsatte jeg som før: med versjonen der personer som kommer inn midt i prosjektet, blir sittende fast i at jeg hopper inn i en bil i bevegelse og stikker hånden inn i ilden.

Tilhørighetsproblemet

Men mens jeg fortsatte å kaste dokumenter og møteinvitasjoner i full fart etter personer som ble lagt til i prosjektet — og mens teamet tankeløst bladde gjennom oppgaver  fra oppgavelageret — ble én ting svært tydelig: Det handlet ikke om informasjon. Det handlet om tilhørighet. Og det er en følelsesmessig tilstand som ikke kan oppnås gjennom dokumentasjon alene. 

Jeg klarte ikke å få nye teammedlemmer til å føle at de hørte til bare ved å forsikre dem eller snakke mer til dem. Ingen fadderordning kom til å løse dette. Ingen møter med en fast agenda for "spør meg om hva som helst" kom til å ordne opp. Det måtte finnes trygge og alternative rom.

Folk finner tilhørighet på ulike måter i ulike sammenhenger: noen ønsker ro til å lese dokumentasjon før de snakker med teamet; noen ønsker en fadder; noen ønsker et trygt rom for å stille de "dumme" spørsmålene; og noen ønsker bare å forstå "hvorfor" bak oppdraget og sin egen rolle i det. 

Det er dette jeg burde ha investert tid og energi i å bygge: et rammeverk som lar teammedlemmer finne tilhørighet på sine egne premisser. 

Til syvende og sist investerte jeg for mye i oppstartseremonien, samtidig som jeg overlot dem som kom inn midt i prosjektet, til å klare seg selv.

Denne syklusen med utilstrekkelig innføring frustrerer ikke bare enkeltpersoner – den undergraver hele prosjekter. Når nykommere ikke kommer raskt nok inn i arbeidet, går beslutningene saktere, feilene blir flere, og moralen i teamet svekkes.

Og når endring er uunngåelig – når teammedlemmer kommer inn og går ut gjennom et prosjekts livssyklus – blir denne tilnærmingen uholdbar.

For de nye teammedlemmene handlet det ikke om at de manglet informasjon, myndighet eller til og med ideer. Det handlet om at de ikke følte at de hadde eierskap.

En annen måte å tenke på oppstarter: kontinuerlig innføring

Så hva er svaret? Hvis vi investerer for mye i oppstarter og for lite i endringshåndtering og innføring midt i prosjektet, hvordan kan vi rette opp dette?

Jeg hadde noen hypoteser, men jeg fikk også en aha-opplevelse fra en jeg har stor respekt for, som sa:

u0022Jeg gjentar alltid fokuspunktet omtrent i hvert møte fordi 'ledestjernen' alltid skifter. Det minner meg om hvordan vi trener kung fu … Det finnes et sentrumspunkt vi fokuserer på å kontrollere, og utenfor dette er alt kontekst for å komme tilbake til denne sannheten. Det er en samtale, der begge sider 'stiller spørsmål' og mottar svar i sanntid med alle sanser.u0022

Med andre ord: I stedet for å være avhengige av det store hurraet ved en oppstart kan vi bruke hver interaksjon til å forsterke kjernen i det som er viktig i prosjektet. Det er bygget inn i selve samarbeidet, i stedet for å være en stor fest som det er lett å føle at man har gått glipp av hvis man ikke var der.

Så her er det jeg har forsøkt å gjøre for hvert prosjekt siden: 

1. En praksis for lett og enkel dokumentasjon som er lett å oppdatere

Jeg har lagt bort de pene oppstartspresentasjonene mine og de svært gjennomarbeidede prosjektartefaktene (kortfattede beskrivelser, statusrapporter, møteagendaer, RAID-logger), og prioriterer i stedet å ha ting i et format som er enkelt å oppdatere og enkelt for menneskelige eller kunstige teammedlemmer å lese.

Deretter samarbeider jeg med prosjektteamene om å utpeke ansvarlige for oppdatering av dokumenter – akkurat slik vi ville gjort for risikoeiere. Det fordeler belastningen og gir teammedlemmene mulighet til å ta ansvar for at dokumentasjonen er korrekt.

For eksempel har vi enkle og kortfattede dokumenter i Notion eller Slite for teamroller og -ansvar, prosjektbeskrivelsen vår og kommunikasjonsplanene våre. Ingenting er låst inne i regneark eller PDF-filer.

2. Kontinuerlig innføring som en akseptert sannhet

Sammen med dokumentasjonen har jeg helt fra starten av avstemt forventningene med teamet om at teamene, målene og andre rammebetingelser rundt prosjektet kan endre seg på et øyeblikks varsel, og at vi må samle oss.

Med andre ord: I stedet for å håpe og be om at team og mål ikke skal endre seg, må vi anta at de vil endre seg.

Det betyr at så lite som mulig er låst i folks hoder eller henvist til et bestemt tidspunkt. Møter har transkripsjoner, foredragsholdernes notater er tilgjengelige i skriftlig form, de fleste prosjektsamtaler foregår i åpne kanaler, og beslutninger loggføres grundig. 

Dette bidrar til å sikre at personer som gikk glipp av prosjektets første dag, fortsatt har tilgang til informasjon hvis de trenger det. Det hjelper oss også med å skifte retning som en flokk sanglerker hvis noen av prosjektets mål eller omstendigheter endrer seg.  

3. AI som en sannhetskilde for alle nevrotyper

I tillegg konfigurerer teamene mine og jeg AI-chatboter eller søkbare kunnskapsbaser for prosjektet så tidlig i prosjektet som mulig. 

I mange tilfeller er det ikke så sofistikert som man kanskje drømmer om når det gjelder AI, men det gjør noe som er svært viktig for oss: Det skaper en relativt privat, trygg og  mindre politisert måte for teammedlemmer å få tilgang til prosjektinformasjon på – på sine egne premisser, på den måten de liker å lære på. 

Disse chatbotene får strukturerte og ustrukturerte prosjektdata helt fra starten av — briefer, SOW-er, statusrapporter, møtereferater og enkelte teamsamtaler. Og fordi dokumentasjonen er lett nok til at menneskelige teammedlemmer kan holde den oppdatert, er det relativt enkelt for en AI å holde oversikt over hva som har endret seg gjennom prosjektet — beslutninger som er tatt, budsjett som er lagt til, problemer som har oppstått, risikoer som har blitt realisert, eskaleringer som har funnet sted osv. 

Deretter kan alle teammedlemmer stille spørsmål til chatboten når som helst, i en kontekst der de ikke trenger å bekymre seg for å fremstå dumme, og uten å måtte avtale et møte med en autoritetsperson som allerede har dårlig tid.

Et teammedlem kan for eksempel spørre om ting som:

• “Hvordan støtter oppgaven min det overordnede prosjektmålet?”
• “Hvem er avhengig av at jeg fullfører leveransen min i tide?”
• “Hvor bør jeg lagre de endelige leveransene mine, og hva er navnekonvensjonen vår for filer?”

Dette kan være spørsmål de allerede vet svaret på, men som de kanskje ønsker bekreftelse på når de beveger seg mellom prosjekter og andre oppgaver. 

Til syvende og sist effektiviserer AI-chatboter prosessen med å få tilgang til informasjon, øker effektiviteten ved å fjerne behovet for omfattende opplæring eller konsultasjon med flere kilder, og forbedrer tilgjengeligheten gjennom et brukervennlig grensesnitt som kan nås fra alle enheter med internettforbindelse, døgnet rundt.

Men her er haken: AI har vært kjent for å ta feil.

Og hvis den tar feil, kan det få et prosjekt til å spore av svært raskt. Den overordnede konsekvensen ville være et ekstra trinn: Prøv å spørre chatboten, gransk svaret fordi det kan være feil, og bruk deretter magefølelsen til å avgjøre om du skal følge svaret du fikk og ikke spørre noen andre, eller finne en kollega å spørre — med andre ord: Når vi ikke stoler på AI, er vi tilbake til utgangspunktet.

Dataene må altså være tilstrekkelig ryddige til at de ikke er motstridende. Og menneskene på teamet må faktisk stole på at de er korrekte (forutsatt at vi ikke har matet systemet med feilinformasjon).

For å bidra til å sikre dette er prioriteten vår å sørge for så høy nøyaktighet som mulig, med sentrale teammedlemmer som ambassadører og kvalitetsansvarlige ved hjelp av noen få testtilfeller og stikkprøver som vi gjennomfører regelmessig. 

4. Rituell forsterkning av mål

Og for å knytte alt sammen har jeg forsøkt å ta noen av mine favoritelementer fra den tragisk nok «øyeblikksbaserte» prosjektoppstarten og flette dem inn i hverdagen. Ting som å gjenta og stadig utfordre produktvisjonen eller BHAG-en, slik at oppdraget er godt nok forstått til å kunne granskes, for å sikre at vi fortsatt bygger det riktige. 

Jeg prøver for eksempel å minne folk på de ønskede resultatene for prosjektet i starten av hvert teammøte. Noe sånt som «som en påminnelse skal dette prosjektet hjelpe kollektivpassasjerer med ulike funksjonsevner med å komme seg tryggere og mindre frustrert dit de skal».

Og hvis denne ledestjernen har endret seg, prøver jeg også å gjenta det på hvert møte eller i hver statusoppdatering: «Som en påminnelse startet dette som et initiativ for kollektivpassasjerer med funksjonsnedsettelser, men nå er det en mulighet til å løfte opplevelsen for alle kunder på tvers av flere kollektivnettverk.»

Det andre jeg gjør, er å bruke rollen min som generalist til å stille spørsmål som styrer beslutningene mot målet vårt. Hvis teamet for eksempel prøvde å velge mellom to tilnærminger, ville jeg spurt noe sånt som «hvilken av dem vil hjelpe oss med å fjerne mest mulig friksjon fra kundeopplevelsen?»

Når det gjelder ting som teamverdier og arbeidsmåter, velger jeg å avslutte møtene med en slik påminnelse: «Ikke glem å holde viktig kommunikasjon i den delte kanalen hvis den kan hjelpe andre med å gjøre jobben sin.»

Dette gjør ikke bare at de som blir med midt i prosjektet, føler mindre at de gikk glipp av noe i begynnelsen; det bidrar også til kontinuerlig å forsterke oppdraget overfor alle interessentene deres.

5. En kultur for tilhørighet

Men viktigst av alt prøver jeg å endre tankesettet mitt fra «kunnskapsoverføring» til «overføring av eierskap» ved å prioritere måter å hjelpe nye teammedlemmer eller interessenter med å føle at de «hører til» i prosjektet, og at de kan være hele seg selv i det.

Etter min mening finnes det ingen enkelt, bombesikker måte å gjøre dette på, men jeg er overbevist om at svaret ikke er å tilføre folk mer informasjon. Vi mennesker må bruke det menneskelige i oss til å håndtere de utpreget menneskelige tingene — følelser, ego, fellesskap og mening.

Når folk ikke har eierskap, er det mindre sannsynlig at de sier fra når noe føles feil, eller utfordrer en beslutning som kan sende prosjektet på villspor.

More Articles

• AI-gründer som bygger en autonom virksomhet, deler hvordan man bygger agentiske arbeidsflyter for prosjektleveranser og kundestøtte
• Senior IT-prosjektleder sier at prosjektledere må fokusere på den menneskelige samhandlingen algoritmer ikke kan berøre
• Prosjektleveranseekspert sier at AI avdekker ødelagte kunnskapssystemer i virksomheter
• Ekspert på innovasjon innen prosjektleveranser forklarer hvilke betingelser som kreves for vellykket AI-integrasjon
• Produktleder i oppstartsbedrift for AI-styring deler de agentbaserte arbeidsflytene han’ implementerer for å effektivisere leveransen

Hvorfor dette betyr mer nå

I dag ser jeg at problemet med introduksjon midt i prosjektet blir stadig større. Medlemmer av fellesskapet mitt driver prosjekter som er en svingdør av spesialister på deltid, frilansere og til og med heltidsansatte som flyttes smidig mellom prosjekter for å holde dem utnyttet.

Samtidig skaper KI-verktøy flytende forventninger blant prosjektets interessenter: Prosjekter forventes å gå raskere, håndtere endringer bedre og levere mer verdi ved å utnytte datainnsikt, automatisering og agentbasert beslutningstaking. 

Med andre ord er teamene mer ustabile, og tempoet øker. Det betyr at tilhørighetsgapet blir større når alt beveger seg raskere og endres oftere.

Og her er den virkelige risikoen: Vi vil ikke bare bygge feil ting raskere.

Når folk ikke har eierskap, er det mindre sannsynlig at de sier fra når noe føles feil, eller utfordrer en beslutning som kan sende prosjektet på villspor.

Derfor er kontinuerlig introduksjon ikke lenger valgfritt. Det er ikke noe som er kjekt å ha, eller en myk ferdighet. Det er en forretningsmessig nødvendighet. Hvis vi vil ha team som kan tilpasse seg og levere reell verdi i dette raskere og mer oppstykkede prosjektlandskapet – trenger vi mennesker som føler seg investert i visjonen, ikke bare informert om oppgavene.

Så, er oppstartsmøter døde?

Oppstartsmøter for prosjekter er definitivt ikke døde. Ikke for meg, og ikke for mange prosjektteam.

Personlig elsker jeg dem. Jeg mener at oppstartsmøter for prosjekter er samlinger som kan skape bånd mellom mennesker og gi rom for dialog på et avgjørende tidspunkt i prosjektets livssyklus. Jeg synes de er svært menneskelige. Så ja, jeg holder fortsatt oppstartsmøter, og du må rive denne vanen ut av mine kalde, døde hender.

Det jeg imidlertid gjør annerledes, er at jeg ikke stapper alle håpene og drømmene mine inn i oppstartsmøtene. Jeg investerer ikke like mye energi i å gjøre dem feilfrie, skinnende og iscenesatte. Jeg prøver ikke å gjøre dem til den altomfattende seremonien som får folk som ikke var der fra begynnelsen, til å føle seg som annenrangs borgere. Og jeg prøver definitivt ikke å gjøre dem til noe som låser oss til forventningen om én enkelt, urokkelig vei. 

For prosjekter går ikke i en rett linje. De er som en drage i vinden, som blir kastet hit og dit og må styres aktivt, uansett hva som skjer. Endringer er uunngåelige. Derfor er det dette vi bør investere energien vår i å forberede oss på.

Hva synes du?

Men jeg vil gjerne høre fra deg også: Er oppstartsmøter så problematiske som jeg har fått dem til å fremstå? Hvordan tenker du om introduksjon i prosjektene dine – særlig når teammedlemmer blir med underveis?