I arbetet förekom det förändringar av olika slag och de blev mer eller mindre en naturlig ingrediens i projektledarnas vardag. Förändringarna var av olika slag. Vissa var förväntade och de hade avsatt tid för att hantera dem. Med förväntade förändringar menar jag förändringar som kanske kommer som en överraskning när de får reda på dem men när de väl sker hade de haft en viss tid på sig att förbereda för dem. Andra förändringar var mer oväntade och kom som en överraskning och måste hanteras på ett i förväg okänt sätt.
Väntade förändringar
Förändringsbegäran
En ständigt återkommande aktivitet var hantering av förändringsbegäran. När en kund hittade en brist och rapporterade detta till företaget skrevs en CR (förändringsbegäran, Change Request) på huvudprojektnivå. Denna CR kopierades (”klonades”) sedan till delprojektnivå som analyserade sin del och de olika teamen bedömde hur mycket arbete de får om förändringen skulle implementeras, införas i det aktuella projektet. Informationen diskuterades sedan på möten som hölls varje måndag på subprojektnivå där de rekommenderade var och hur förändringen skulle genomföras. I denna rekommendation togs hänsyn främst till teamens arbetsbörda och övrig planering.
Dagen efter diskuterades de olika subprojektens rekommendationer på projektnivå och här försökte de, i sin rekommendation, också ta hänsyn till hur förändringarna påverkade systemet och i vilken version av produkten de hörde hemma strategiskt.
På onsdagarna planerades sedan förändringarna in med hänsyn till rekommendationerna, både från projektnivå och från subprojektnivå. Tanken var att
om förändringen medförde extrajobb utöver den tid som var planerat i projektet skulle beslutet om implementering av förändringen också medföra ett beslut om mer tid till projektet. Ett annat alternativ kunde vara att en annan funktionalitet som var planerad i den aktuella versionen, flyttades till en senare version i syfte att spara tid och därmed ge utrymme för implementering av den nya funktionen. Tyvärr hade det visat sig att detta inte alltid fungerade. Ibland planerades ny funktionalitet in utan att mer tid gavs vilket gjorde situationen svår att hantera på teamnivå. Om situationen blev ohållbar fick de diskutera förändringsbegäran ännu en gång och se om de kunde få ett annat beslut eller åtminstone mer tid för implementering. Efter onsdagens beslut gick Diana igenom vilka beslut som fattats och skickade informationen vidare till de team som skulle implementera de olika förändringarna.
Dianas arbete med CR bestod alltså av att, i det speciella verktyget för hantering av CR, notera när en begäran kom in och att sedan följa analysen av denna och övervaka utvecklingen, via analyser och beslut, till det att förändringen blev genomförd. Uppgiften var att under tiden arbeta för att i största möjliga mån verka för att förändringarna fick minsta möjliga påverkan på projektet och därmed att försöka skjuta förändringarna så långt fram i tiden att det fanns större möjlighet att planera in dem.
Ibland fick detta sätt att hantera CR oanade effekter. Under en period rekommenderade Diana att lägga ett antal förändringar i en version som förväntades att tidsmässigt ligga två versioner efter den som då producerades. Under studieveckan planerades dock denna version in så den kom att ligga samtidigt med den efterföljande vilken medförde att det arbete som man förväntade skulle hamna ungefär en och en halv till två månader bort, istället kom att hamna en halv till en månad bort.
Under studieveckan bestod Dianas arbete dessutom av att i de olika teamen instruera om hur CR hanterades i projektet och hur teamens arbete med dessa skulle ske.
Revidering av starttid
Ibland var det inte helt klart vad ett projekt skulle innehålla utan detta diskuterades och kunde förändras ganska sent i processen liksom när arbetet med projektet skulle starta och på vilken grund det skulle utvecklas.
Under ett subprojektmöte diskuterades när produktion av version Delta 0, inkrement Delta skulle starta, se figur 16. Några av designteamen hade en del rättningar att göra i tidigare versioner men väntade annars på att starta produktionen. För att starta behövdes signalfiler som ännu inte kommit från Kina. Som versionerna var planerade skulle både Delta 0 och Gamma 11 följa efter Gamma 10 där Delta 0 skulle få ny funktionalitet medan Gamma 11 skulle komma att innehålla rättningar
och förändringar i den funktionalitet som fanns i Gamma 10. Eftersom många av de ändringar som skulle göras i Gamma 11 också borde in i Delta 1 kom ett förslag upp att bygga Delta 0 på Gamma 11 istället för på Gamma 10. Vid mötet beslutas att de ska undersöka effekterna av detta och att diskutera vidare senare i veckan.
Figur 16. Grafisk bild över de planerade sambanden mellan de olika versionerna.
På morgonmötet dagen efter var inte Caesar närvarande men hade hälsat att om man måste starta produktionen av Delta 0 nu så måste det ske med Gamma 10 som bas. David meddelade att han skulle undersöka med sina team om de kunde vänta några dagar till samt att det för designs del medförde stora effektivitetsvinster att använda Gamma 11 som bas för Delta 0. På projektmötet senare under dagen meddelade samtliga team att de hade jobb för tillfället och att de därför kunde vänta några dagar till.
Under torsdagens förmiddag beslutades på ett planeringsmöte på projektnivå (nivån under huvudprojektet) att Gamma 11 skulle användas som bas för Delta 0, figur 17. förberedelser startades med konfigurering av verktygen. Senare under dagen när man under en fikapaus diskuterade det beslut som fattats, fick jag kommentaren, från en av personerna som satt med på onsdagens projektmöte, att ”Det måste du notera; Projektledarens historia påverkar agerandet”. Han syftade på att David med sin designbakgrund kunde agera starkt för att vinna fördelar för designprojektet.
Figur 17. Grafisk bild av sambanden efter det nya beslutet
Tidigareläggning av produktversion
Under ett subprojektmöte ett par veckor senare meddelade Caesar att han fått frågan om möjligheten att leverera Gamma 12 istället för Gamma 10, figur 18. Första reaktionen från projektledarna var ganska negativ eftersom mycket fokus låg på
produktion av Delta 0 och att stressa fram Gamma 12 skulle innebära stor risk för försening av denna. Efter en stunds diskussion enades de om att det kunde vara möjligt förutsatt att produktionen av Gamma 10 avbröts och om alla nya CR som skulle komma för Gamma 12 placerades i en version Gamma 13 som ännu inte var planerad samt om några andra tveksamheter löstes på ett för delprojekten positivt sätt. Caesar lovade att kontrollera och förhandla om detta och att återkomma om vad det slutliga beslutet blev.
Figur 18. Sambanden mellan de olika versionerna. Den streckade linjen visar den föreslagna placeringen av Gamma 12.
Omorganisation
Strax innan de inledande observationerna hade David genomfört en omorganisation inom delprojektet för att bättre kunna möta de krav som ställdes i kommande inkrement. I samband med detta hade några av teamen förändrats och några personer hade fått byta team. Detta ledde till att David behövde samtala med några av medlemmarna för att övertyga dem om att detta var en bra lösning och att förändringen skulle vara till nytta för dem i längden. Argumentationen var ibland häftig och någon uttryckte sitt missnöje med att behöva flytta till ett så trist team. David, Diana och projektsponsorn höll också ett möte med en av teamledarna för att diskutera hur det teamet skulle arbeta. Det aktuella teamet var det som genomgått störst förändring och därför behövdes en grundlig genomgång av krav och förväntningar.
I samband med omorganisationen hade de också diskuterat en förändring av hur de skulle hantera felrapporter. Denna förändring var det många som var negativa till. De som tidigare hade provat att arbeta efter denna modell var mycket nöjda och berörda personer utanför delprojektet hade inget att invända. David försökte därför att övertyga de mest negativa personerna att åtminstone prova under en period. Detta lyckades och de kom överens om att göra så under det kommande inkrementet.
–
Enligt Diana så var projekten ganska ”svajiga”. De satte inte ut målet för att sedan gå raka vägen dit utan förändringar skedde hela tiden. Det kunde till exempel handla om att ett datum flyttades eller att en annan version av produkten skulle utvecklas samtidigt. För att hantera dessa förändringar behövde projektet till viss del planeras om och det var denna omplanering som tog tid.
…ibland kan man känna som all ens tid går till planering och omplanering…
Arbetet med att planera om projektet var inte isolerat från det andra arbetet utan samtidigt pågick projektet som vanligt och krävde sitt engagemang.
[Det finns] en massa annat jobb som ska göras också som rullar på, typ CR-hantering och information och… allt vad det nu kan vara. Det är dom perioderna som blir stressiga. Vi är väl som på gång med det nu lite grann […]. Nu kanske det inte är så vansinnigt stora förändringar men det är ändå… det rör om lite grann.
Bilden av den föränderliga miljön förstärks av att mycket av de normala uppgifterna för Diana handlade om hantering av förändringsbegäran (CR). Vid planeringen av projektet fanns det en schablonmässigt beräknad tid avsatt för att i teamen och projektledningen ska kunna hantera dessa förändringar.
Risk att förlora jobb
En förändring av lite ovanligare slag handlade om att SoftCorp skulle förlora jobb. I samband med att den andra omgången av observationer inleddes bad David mig vid ett tillfälle att stänga dörren. I och med att dörren nästan alltid stod öppen till rummet började jag att ana att det han nu skulle berätta var av känslig natur. Jag kunde dock inte föreställa mig att jag skulle bli den sjunde inom organisationens väggar som fick veta att det var dramatiska förändringar på gång. Förändringar som hittills bara delprojektledarna och linjecheferna hade blivit informerade om.
Anledningen till förändringarna var att InnCorp efter omstruktureringar fått 30 personer som blivit övertaliga inom ett närliggande område och dessa skulle nu få nya uppgifter. De flesta av dessa personer hamnade på olika team hos InnCorp men det ledde också till att InnCorp nu ville ta över produkterna från ett av teamen vid
SoftCorp. InnCorps plan var sannolikt att så småningom ta över arbetet från flera team men nu var det aktuella teamets produkter intressanta. En trolig anledning till att det just var dessa produkter som togs först var att InnCorp inte visste så mycket om dem och att de var strategiskt viktiga. Produkterna var dessutom mycket komplexa.
Informationen om transfer av produkterna till InnCorp hade kommit fram under de senaste veckorna och osäkerheten var stor om när och hur de andra skulle informeras och oron för framtiden var påtaglig. Under dagen diskuterade David och Denise situationen med varandra och David ringde till Caesar för att informera sig om hur många hos InnCorp som var informerade om planerna. Vid fikat på eftermiddagen pratade David med Johan och sa att nu var det dags att informera innan ryktet skulle spridas i och med att ”alla” hos InnCorp var informerade.
Avdelningschefen Johan och enhetschefen Karl hade kommit till samma slutsats och tänkte informera dagen efter. David kontaktade därför Karl och de beslutade att först informera teamledarna för det berörda teamet eftersom det i första hand var det teamet som utvecklade de produkter som skulle föras över. Teamledarna skulle informeras på förmiddagen och övriga på eftermiddagen i samband med ett ordinarie möte. Både Karl, Johan och David verkade nervösa över detta. Innan han skulle gå hem ställde sig David vid stolen, tittade på mig och sa ”vad tror du om imorgon?” Jag svarade något om att det kan bli tufft och han sa att ’man bör presentera det på ett sätt som inte är alltför dystert och att det skulle ges rätt proportioner, men vad är det? Hur gör man det? Det är inte lätt när det inte finns något klart vad vi ska göra istället.’
När han sedan gick hem var det fortfarande med funderingar om ’hur gör man detta?’. ’Hur tas detta emot av teamen’? En annan fråga var om det skulle räcka med detta team. Karl och Johan trodde det men InnCorps plan var att flytta över flera produkter så småningom, vilket skulle leda till att fler team försvann. Antalet medarbetartjänster som de köpte från SoftCorp var i alla fall planerat att successivt trappas ner och minskas fram till årsskiftet. Vid årets slut var det tänkt att antalet personer hos SoftCorp som arbetade för InnCorp skulle ha halverats.
Det fanns också en oro hos projektledare och linjeledning för att de skulle hantera detta på ett sätt som skadade relationen mellan medarbetarna och ledningen. Om informationen kom fram bakvägen kunde ledningen hamna i en situation där de blev anklagade för att ”mörka” och att undanhålla information.
Dagen efter träffade David, tillsammans med Denise, Karl och Jonas (ännu en avdelningschef), teamledarna för teamet som skulle flytta och berättade om planerna. Teamledarna tog emot informationen med jämnmod och teamledarna funderade en del på hur det skulle tas emot av teamen och vad som skulle hända när produkterna blev flyttade. David poängterade att teamledarnas uppgift nu var att försöka ta hand om teamet och se till att allt inte cirkulerade omkring detta utan att det också skulle
Under eftermiddagen, när inte David var närvarande, informerade Karl samtliga anställda om planerna att flytta produkterna och enligt Denise kunde man ana en viss oro för framtiden hos de anställda. Trots detta var det ganska lugnt. Karl gick också runt dagen efter meddelandet för att ”känna efter stämningen” och för att svara på frågor som kommit upp efter att de fått fundera vidare på informationen.
I samtal med Stefan, projektledaren i transferprojektet som skulle flytta produkterna, och med Caesar kom David överens om att överföringen av produkterna inte skulle påbörjas förrän pågående projekt var slutfört. Det riskerade annars att skapa oro och att ta för mycket tid av teamet och därmed att försena leveransen. Detta fick under inga omständigheter ske.
Ungefär en vecka senare började funderingarna komma om vad som hände i transferprojektet och hur InnCorp tänkte sig det hela. Ännu hade ingen diskuterat med David om hur det skulle gå till och snart var det dags att starta flytten. Hur skulle han planera? Stefan kom till SoftCorp för att få lite information om produkterna och han träffade David mycket kort och det enda David fick ut av det mötet var vilka datum som det var tänkt att produkterna skulle vara flyttade. Det var i och för sig viktig information men inte så mycket som David behövde. Han ville i det här läget ha information om hur det var tänkt att flytten skulle gå till och om hur Stefan ville att SoftCorp skulle förbereda för transfer men detta fick vänta ännu en tid.
Ytterligare en knapp vecka senare ringde Stefan och frågade om några designer skulle kunna få prova på att rätta några av de fel som skulle rättas så att de kunde få känna på designen och ”rota i koden”. De hade nu gått en veckas utbildning i det programmeringsspråk som behövs för de nya produkterna. Eftersom detta skulle ta extra tid för designerna som arbetade med produkterna tyckte David att det var olämpligt och att de istället skulle analysera felen och föreslå åtgärder (ge ändringsförslag i koden). Då kunde teamet fixa ändringen och kommentera förslaget. Detta skulle spara tid. David bad sedan Stefan att berätta hur han hade tänkt att flytten av produkterna skulle gå till och de beslutade att de skulle träffas när David besökte InnCorp under följande vecka.
I förberedelsen inför denna träff mötte David och Denise teamet som skulle lämna ifrån sig produkterna och David berättade hur han hade tänkt sig det hela och bad dem att kommentera.
I ett senare samtal med linjechefen Johan framkom det att han hade sett planerade datum för flytten som ”är betydligt mer aggressiva än vad som sagts tidigare”. Johan
nämnde också att Stefan kommenterat att David varit alltför protektionistisk26 vilket
ledde till att David kontaktade Stefan för att förtydliga och förklara varför han svarat
som han gjort på frågan om de nya skulle få prova att rätta felrapporter.
När jag någon månad senare bad David kommentera denna händelse svarade han så här i ett e-brev.
Jag kontaktade Stefan pga att ge min syn på transfern och skapa en gemensam syn. Detta med ”protektionistisk” var nog mest pga att Stefan ej hade kommunicerat så mycket med mig angående komplexiteten i dessa produkter och därav inte, enligt mig, kunde ha en realistisk och trolig strategi för tidiga transferaktiviteter. De fick möjlighet att prova att analysera och komma med förslag på en ”C” felrapport27 och de kunde inte lösa den. När våra designer kollade på denna så fann vi lösningen inom ca 30 minuter. Så efter detta så vart det ännu tydligare vad jag menade med att de ej skulle vara inne och göra designlösningar förrän de hade bättre insikt i produkterna.[personnamn utbytta av författaren]
När Stefan och David slutligen satt ner och pratade en förmiddag kom de överens om hur flytten skulle gå till, i stort enligt Davids förslag, och hur arbetet skulle planeras tidsmässigt.
När de personer som skulle ta över produkterna någon vecka senare kom till SoftCorp skötte teamet och några personer från Systemprojektet det mesta. Teamet hade ställt i ordning arbetsplatserna och lagt godis och reklampennor på bordet och förberett presentationer av produkterna så att det skulle vara lättare att komma in i hur de fungerade. Över lag så fungerade det överlämnande teamet bra och de verkade inte nedslås av att bli av med produkterna. Visst blev det en oro och funderingar för framtiden men i arbetstakten eller i inställningen till jobbet märktes inte mycket. Teamet lyckades för ovanlighetens skull dessutom att leverera tidigare än planerat, något som inte hänt under överskådlig tid. Detta kommenterades också flera gånger av David och Denise både inför teamet och inför linjecheferna som var mycket nöjda med teamets arbete, och deras sätt att hantera situationen.
–
Efter ett halvår fanns det inte så mycket kvar av oron för de förlorade produkterna. Produkten var mer komplicerad att flytta och mer komplex än vad InnCorp hade förutsett varför endast nyproduktionen dittills blivit flyttad men resten skulle
flyttas inom kort. Istället för de flyttade produkterna hade SoftCorp då fått ett par andra produkter som flyttats över från InnCorp. Det innebar att av den planerade neddragningen från 20 personer till 14 blev det inget. Istället hade det blivit möjligt att anställa fler personer och nu jobbade 27 personer hos SoftCorp i projektet.
Omprioritering
Det var inte ovanligt att projekten omprioriterades i förhållande till varandra. Ett sådant tillfälle handlade om en planerad presentation av en produkt som skulle visas följande vecka. Det var InnCorps försäljningsorganisation från Nordamerika som skulle komma med en av sina kunder. Tanken var att man skulle visa produkten praktiskt, hur den fungerade. Problemet var att produkten inte var helt färdigtestad och man befarade att det skulle kunna dyka upp fel som skulle kunna förstöra möjligheterna att visa produkten. Ett meddelande gick därför ut i början av veckan att alla felrapporter som gällde den aktuella produkten skulle prioriteras före allt annat och att övertid kunde beordras fritt, bara produkten blev klar. Meddelandet innehöll också en uppmaning om att planera för beredskap i helgen för att kunna