Fallstudie 3: Att leva här och nu i projekt

För ett par år sedan ansvarade jag för ett team – vi kan säga att jag var teamledare – om cirka 10 – 15 personer där en liten del, i princip en person, arbetade med mjukvara.

Resten av gruppen arbetade med andra typer av teknikfrågor långt från mjukvaran.

Jag la viss del av min tid på projektet men mycket av mitt fokus var på de underleverantörer vi hade och de arbete teamet gjorde tillsammans med dem.

För mig var programmeringsarbetet inte 5% av mitt fokus, något som förstärktes av att våra funktioner sedan länge var färdiga. Vi förvaltade det vi gjort.

Projektet, där vi var en del, var mycket omfattande och mjukvarudelen var inget undantag.

Det fanns i storleksordningen 10 – 15 team i projektet och mjukvaruverksamheten omfattade flera hundra personer.

Vi var organiserade i en klassiskt pyramid med en huvudprojektledare i toppen, delprojektledare, teamledare och ingenjörer.

En gång i veckan – på fredagar – hade vi ett omfattande systemtest/regressionstest av mjukvaran och under en period hade vi stabilitets- och integrationsproblem i princip varje vecka.

Att mjukvara ”går sönder” och att det blir allt svårare att testa en programvara är knappast något önskvärt, därför skapade problemen i sig oro hos vårt management.

Samtidigt fanns det ibland goda skäl till varför testerna inte fungerade, man hade exempelvis väldigt tajta tidplaner som inte alla iblandade alltid kunde hålla, vilket gjorde att vissa leveranser av mjukvara, som berodde av andras uppdateringar, ibland hamnade helt fel.

Så det fanns oro och frustration, något som gjorde att högsta projektledningen var starka i sin tro om att ”alla” skulle vara med i processen.

Vårt teams funktion var ganska enkel, men absolut central för att systemet överhuvud taget skulle gå att prova och anses funktionellt på något vis.

Den var dessutom den första funktionen ut av den karaktären i nästan all provning.

På så vis blev den en sorts mjukvaruvariant  av kanariefågeln. När det inte gick att göra det vår funktion skulle göra så var det kris på riktigt!

En intressant ”faktor” i det här sammanhanget var att veckoprovningen egentligen inte utfördes på uppdrag av någon som kunde agera på resultatet i teknisk mening, utan den som hade blivit testteamets ”speaking partner” var huvudprojektledaren i projektet.

Den huvudprojektledaren fick en summarisk sammanställning – vanligtvis på måndag morgon –  av hur provningen gått och där lyftes stora avvikelser fram.

Typiskt konstaterades kort då att vår funktion ej gått att använda och röda lampan i vår projektledares huvud tändes. Det här var något hon var tvungen att agera på, i det följde hon en tydligt uttalad policy: ansvaret för fel och felrapporter låg på funktionsägaren att hantera, även om det var tjänster eller komponenter i underliggande system som inte fungerat.

I huvudprojektledarens värld var det alltså jag som var den att kontakta. Det var jag som hade ett problem. Vecka efter vecka.

Nu började råttan på repet övningen. Huvudprojektledaren ringde delprojektledaren. Denne var helt ovetandes om provningen och dess utfall. Därför ringde delprojektledaren mig. Tiden gick.

När man väl fått tag på mig svarade jag att jag inget visste, men att jag skulle försöka reda ut vad som hänt och vad som gjordes åt saken.

När jag hunnit prata mig samman med min mjukvaruingenjör – det kunde ta lite tid innan det hände – så var nästan alltid resultatet att ”jo vi såg att en tjänst inte fungerat som tänkt och den grupp som implementerat tjänsten felsöker nu problemet”.

Nu var det dags för mig att motionera. Jag undrade vem som arbetade med att lösa problemet och fick svaret att det nog var ingenjör X.

Jag kontaktade X som undrade varför jag störde. Hen meddelade att frågan diskuterats på teamets morgonmöte – nu hade det gått lång tid sedan felet förs upptäcktes – och att teamledaren i ingenjör X team hade tagit frågan vidare till projektledningen för vidare diskussion.

Jag ringde X teamledare som inte svarade ….

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å.

Det här var knappast roligt, effektivt eller meningsfullt.

Vad borde vi gjort annorlunda?

Välkommen till Projektledarbloggen!

Jag som skriver här heter Anders Gustafsson och jag har ett stort intresse för ledarskap och projektledarhantverket. Jag har alltid varit mer intresserad av komplexa funktioner och övergripande frågeställningar i produktutveckling än jag varit för detaljer. Den bilden har förstärkts när jag alltmer börjat intressera mig för människorna runt om mig och hur jag påverkar dem.

Min utbildningsbakgrund är en Civilingenjörsutbildning på Y-linjen i Linköping, doktorandstudier - som aldrig avslutades - och på senare år har jag läst ledarskap och psykologi på universitetsnivå.

Du hittar mer om mig om du följer länken till LinkedIn precis här nedanför.

Idag jobbar jag som projektledare hos en teknikkonsult i Stockholmsregionen och där jobbar jag, som jag gjort i många år, med produktutveckling.

Lämna en kommentar