Det här är del två av en tidigare fallstudie som lite kort kan sammanfattas så här!

Vecka ut och vecka in skulle jag lösa ett problem som uppstått i ett sammanhang som jag inte var delaktig i. Som diskuterades där jag inte närvarade. Som löstes av personer långt från mig som jag inte ens visste namnet på.  Ofta var problemet redan avhandlat vid testtillfället då felet visade sig, eller timmarna efter. Vanligtvis fanns det ingen konflikt kopplat till rättningen – och fanns det det i form av exempelvis prioriteringar så fördes de diskussionerna direkt med huvudprojektledaren – och inget ”problem” fanns att lösa för mig på projektledarnivå.

Hur kunde ett fel i samband med ett systemtest leda till att så många människor, som inte hade något att bidra med, blev så djupt inblandade?

Jag tror svaret har sin förklaring i projektledarens syn på den organism som projektet utgör och hur den skulle fungera.

Projektledaren strävade hela tiden efter genomföra aktiviteter i en projektstruktur. För att det skulle fungera så krävdes ärenden, rapporter och formella bärare av information. I någon sorts tro om att dessa formella bärare representerade verkligheten så kunde ärenden flyttas runt ”off-line” i ärendesystem och mailboxar.

Kopplat till den synen på hur arbete skulle göras fanns också åsikten om att projektledare/teamledare längre ner i projektorganisationen skulle vara de allvetande, och är det inte de så bidrar arbetet i formella strukturer till att de blir inblandade i allt och till sist vet allt. Vilket vår huvudprojektledare förutsatte.

Ett alternativt förhållningssätt – som jag, och många andra, använt oss av med framgång i många sammanhang – hade varit att vår huvudprojektledare fokuserade projektet mot den så viktiga systemtesten. Förslagsvis hade hon då gjort så här:

  1. I samband med testavslut – antingen i direkt anslutning till provet fredag eftermiddag – eller på måndag morgon så hade hon samlat alla viktiga aktörer i samma rum för ett kort möte.
  2. Där hade felen som hittats diskuterats och huvudprojektledaren hade utsett ansvarig för de allvarliga fel och brister som hittats utifrån felens karaktär. I samband med det hade en kort diskussion förts där alla hade blivit briefade om felet. Samtidig hade oro kring exempelvis stöd från andra grupper i felsökningen och önskad drivningsform hanterats.

I det här har projektledaren gjort sig till mottagare av testresultaten och aktivt säkerställt att utfallen hanteras. I ett ledarskap som verkade i relevanta forum, med rätt takt som matchade det faktiska arbetet. Det gäller att smida när järnet är varmt, inte värma smidet för att sedan ta med det till nästa veckas möte klockan nio!

Erfarenhetsmässigt är det klokt att stödja det mottagandet med någon form av koordinerande roll som stödjer projektledaren i ordning och reda. Själva arbetet som behöver göras drivs i projektstrukturen och följs naturligt upp i de forum som projektet redan har så detta förhållningssätt ger inget merarbete, snarare tvärtom då relevant information byts samlat vid ett tillfälle.

Viktiga händelser är viktiga av en anledning. Där vill vi som ledare ha fokus och snabba svarstider. Då tar vi motsvarande ledaransvar. Att använda viktiga händelser som verktyg för att exercera ordervägar eller verktyg är galet. De har sin naturliga plats, men inget egenvärde.

Det här är inget svårt att förstå, den som sett skillnaden i de två arbetssätten förstår ganska direkt skillnaden och nyttan med ledare som närvarar i verksamheten på rätt sätt. Men det är något som trots det kan vara väldigt svårt att få acceptans för i vissa sammanhang.

Varför tror du?