Kunsten å eskalere riktig når prosjektet butter

Å eskalere har fått en negativ klang, som om det var en måte å gå bak ryggen på noen. I virkeligheten er det en normal og nødvendig del av å styre et prosjekt. Eskalering betyr ganske enkelt å løfte et problem til et nivå som kan løse det, når det nåværende nivået ikke gjør det. Kunsten ligger i å gjøre det tidlig, saklig og uten å forgifte samarbeidet.

Eskaleringstrappen: fra team til avtale

Den første feilen er å hoppe rett til toppen. Den som sender e-post til daglig leder om en oversittet frist før prosjektlederen i det hele tatt har fått sjansen, svekker tilliten unødig. En gjennomtenkt eskalering følger en trapp, trinn for trinn.

Et typisk forløp ser slik ut:

1. Teamnivå. Ta opp problemet direkte med den eller de som kan rette det. De fleste saker blir løst her.
2. Prosjektleder. Kommer problemet igjen, eller påvirker det plan og budsjett, løftes det til den som har ansvaret for leveransen.
3. Styringsgruppe eller oppdragsansvarlig. Handler det om prioriteringer, ressurser eller penger som teamet ikke rår over, tas det til det nivået som gjør det.
4. Avtalenivå. Først når dialogen ikke strekker til, blir det som står i avtalen, aktuelt: ansvar, dagbøter og hvordan tvister skal løses.

Poenget med trappen er at hvert trinn får en reell sjanse til å løse problemet før neste trinn tas i bruk. Bli enige om den allerede ved prosjektstart, så slipper dere å improvisere når det først skurrer.

Dokumentasjonen som gjør deg saklig

En eskalering blir aldri sterkere enn grunnlaget bak den. Forskjellen mellom «det føles som om det går tregt» og «de tre siste sprintene har levert under plan, her er tallene» er enorm. Det første er en følelse som lett avfeies; det andre er vanskelig å bortforklare.

Du trenger ikke å bygge en rettssak, men løpende notater redder deg når det trengs. Hold orden på hva som er avtalt, hva som faktisk har skjedd, og hvilken konsekvens avviket har fått. Med møtereferater, en enkel beslutningslogg og lagret skriftlig kommunikasjon kommer du langt. Når grunnlaget finnes, kan du beskrive problemet saklig, og en saklig eskalering er betydelig vanskeligere å avfeie enn en frustrert.

Eskaler problemer, ikke legg skylden på personer

Her avgjøres det om eskaleringen bygger opp eller river ned. Et problem som løftes saklig, oppfattes som ansvarlighet. Det samme problemet fremført som en anklage mot en navngitt person får folk til å gå i forsvar, og da slutter de å lytte til selve saken.

Forskjellen ligger i hva du retter oppmerksomheten mot. Sammenlign «utvikleren slurver» med «vi har hatt gjentatte feil i den samme brukerflyten, hva skyldes det, og hvordan løser vi det?». Det første leter etter en syndebukk; det andre leter etter årsak og løsning. Hold fokus på problemet, konsekvensen og veien videre.

Et konkret eksempel: Leveransene har vært forsinket tre sprinter på rad. Veien som legger skylden på noen, er å sende e-post til øverste leder om at teamet ikke holder mål. Den konstruktive veien er først å ta det opp med prosjektlederen («vi ligger etter planen, hva skal til for å ta igjen etterslepet?») og, hvis det ikke hjelper, løfte det til styringsgruppen med tallene som grunnlag. Samme alvor, men den andre veien løser oftere problemet og bevarer et fungerende samarbeid.

Gi gjerne beskjed før du går oppover. Å si «hvis vi ikke kommer videre her, må jeg ta det opp i styringsgruppen» er ikke en trussel, men et ærlig forvarsel som gir motparten en siste sjanse til å rette opp. Ingen liker å bli overrumplet, og en eskalering med forvarsel oppleves som rettferdig.

Slik bygger du inn eskalering fra start

Det beste tidspunktet for å bli enige om eskalering er før noe har gått galt. Bestem hvem som er kontaktpunkt på hvert nivå, hvor ofte dere har oppfølgingsmøter, og hva som regnes som et avvik som er verdt å løfte. Da blir eskalering en rutine, ikke en krise.

Vi i Weapp ser at prosjektene som går best, er de der problemer løftes tidlig og saklig, lenge før de har rukket å vokse. Vil du ha en partner som bygger inn den åpenheten fra begynnelsen? Les mer om tjenestene våre eller ta kontakt med en kort beskrivelse av prosjektet.