Nr 4 december Framgångsrikt förändringsarbete sid 6. Varför är processförbättring så svårt? sid 14. Sju fallgropar att undvika Sid 21

Transkript

1 ntimeger INSIKT I TID T E M A : K R A F T E R I F Ö R Ä N D R I N G S A R B E T E Nr 4 december 2003 Framgångsrikt förändringsarbete sid 6 Varför är processförbättring så svårt? sid 14 Sju fallgropar att undvika Sid 21

2 Innehåll OnTime ska ge insikt i tid OnTime är en branschtidning som tar upp olika aspekter och nyheter inom området utveckling av inbyggda realtidssystem. OnTime ska ge möjlighet att ställa olika perspektiv mot varandra, och samtidigt visa helheten i teknikoch samhällsutveckling. Redaktion Ansvarig utgivare Christer Hoberg, vd Redaktionsråd Göran Carlzon, Erichs Communications Anders Magnusson, Göteborg Per-Ola Malm, Malmö Håkan Nilsson, Stockholm Magnus Ohlsson, Malmö Michael Petersson, Linköping Redaktör Eva Holmquist, Jönköping eva.holmquist@combitechsystems.com Nätvariant av OnTime Ledare...3 Förbättring, ett resultat av krafter i samverkan...4 Framgångsrikt förändringsarbete...6 Trovärdighet och åtagande...11 Varför är processförbättring så svårt?...14 Ny utvecklingsmiljö infördes i helikopterprojekt...18 Sju fallgropar att undvika i jakten på bästa praxis...21 Vårt område är inbyggda system.vi kommer aldrig att gå utanför detta område och måste därför behärska inbyggda system bättre än någon annan.våra uppdragsgivare kallar in oss när de står inför sin tuffaste uppgift: bryta ny mark, gå in på främmande teknikområden eller skapa nytt liv i ett projekt som gått snett. Vår affärsidé bygger på att tillföra våra uppdragsgivare nytt kunnande och effektivare metoder inom systemutveckling i kombination med överföring av den erfarenhetsbaserade, tysta kunskapen. För detta har vi utvecklat en metodik som gör att vi successivt för över vårt kunnande till uppdragsgivarens organisation.vi blir därmed så småningom överflödiga inom det dagliga jobbet, vilket som sagt är en del av vår affärsidé vår plats är först och främst inom de delar av projektet där de nya vägvalen är många och svåra. Jönköping (lokalkontor:växjö, Karlskrona, Ulricehamn) Box Jönköping Tel Fax Malmö (lokalkontor: Helsingborg) Box Malmö Tel Fax Göteborg (lokalkontor:trollhättan) Mölndalsvägen 30C Göteborg Tel Fax Stockholm (lokalkontor: Uppsala) Box Stockholm Tel Fax Linköping (lokalkontor: Örebro,Västerås) Teknikringen 9 SE Linköping Tel Fax München Leopoldstr. 236 DE München,TYSKLAND Tel Fax E-post info@combitechsystems.com Hemsida Produktion Erichs Communications AB, Linköping Grafisk design PO.Annonsbyrå AB Tryck NRS-Tryckeri 2 Nr 4 december 2003

3 LEDARE Förändring, förbättring eller verksamhetsutveckling Vad vi än kallar det, så finns det många olika förhållningssätt inför utmaningen att förändra. Det sätt vi hanterar förändring på röjer något om hur vi ser på vår verksamhet och människorna som är i den. Våra organisationer utsätts hela tiden för tryck; yttre marknadstryck genom en ständigt föränderlig omvärld och inre tryck genom människors egen strävan att arbeta effektivt. Utvecklingen av verksamheten får egentligen aldrig stanna upp den blir aldrig helt färdig eftersom förutsättningarna ständigt ändras. kollegor på grannavdelningarna A och B också och avdelning C har faktiskt redan börjat, men gör det på sitt eget sätt. Vi tycker att vi borde samordna det hela så att det blir en gemensam förändring. Förresten vore det bra om inte bara vi på Division X gör detta; vi borde dra med oss Division Y i en gemensam ansträngning det blir ju mycket mer effektivt. Om vi bildar en grupp som Jodå, det är sant, om det alls kommer igång något efter att det blivit så stort. Initiativet brukar självdö. Försök istället att lyckas helt med något i liten skala. Ofta är det de enkla små greppen som kan ge snabb förbättring inte de egna speciallösningarna. En kollega yttrade: Varför startar ett förändringsarbete? Hur vi än uttrycker det bättre processer, bättre att driva projekt, högre produktkvalitet, kortare ledtider, lägre kostnad så vill vi egentligen få ett bättre resultat ur verksamheten. Förbättringar måste således kopplas till företagets affärsmål (är de kända av alla i företaget?). Förändringsinitiativ som saknar denna koppling bör undersökas närmare Vi behöver nya processer och instruktioner Detta är det vanligaste lösningsförslaget. Men jag har ännu inte sett någon verksamhet där dokument faktiskt styr hur man arbetar. Om det vore sant så skulle det räcka med att ge ut en ny instruktion så förändras alla människors arbetssätt. Förändring går på större djup det handlar om att få människor att arbeta effektivare. Utveckling av människors förmåga bör vara i fokus. Man är inte klar då det finns en plan Vi underskattar ofta omfattningen av ett lyckat förändringsarbete. Kraftigt. Att definiera förändringen och ta fram en plan går relativt fort och kostar inte så mycket. Att sedan genomföra den, så att den till slut utgör det enda sättet man vet att arbeta på kostar mycket mer. Om vi inte lyckas realisera förändringen så skapas en frustration som gör organisationen större skada än om vi aldrig startat! Vi vill ta ett helhetsgrepp Vi har identifierat ett behov av att förändra vår testmetodik här på avdelningen. Men det här behovet har våra Krångliga verktyg? Det är som att använda en wokpanna det gör man några gånger i början när den är ny. Det är stekpannan man använder oftast. Säg till när ni är klara Detta är viktigt för oss men projekten är oerhört pressade just nu. Antalet upptäckta fel tenderar att bli allt större i slutet av projekten produktkvaliteten måste upp. Om ni kan hjälpa oss att ta fram en process för dokumentation, granskningar och test så vet vi att det skulle hjälpa. Men ni får absolut inte störa folk i projekten vi är i ett alltför kritiskt läge just nu! Realisering av en förändring är krävande. Då vardagsarbetets akuta ärenden tränger på är det lätt att tappa fokus. En av våra lärdomar är att vi faktiskt inte kan förändra något åt någon annan. Det går bara inte. Förändring måste ske inifrån, men gärna med hjälp av någon utifrån. Någon som inte är hemmablind, utan kan se verksamheten utifrån. Någon som kan ägna sig helt åt att hjälpa folk att komma igång med att använda det nya. Filosofer och författare beskylls ofta för olika uttalanden. Således påstås Aristoteles ha sagt följande (och det spelar nästan ingen roll om han faktiskt sagt det eller inte): Du blir bra på vad du gör, därför är framgång inte en företeelse utan en vana. Göran Backlund Affärsenhetschef på Combitech Systems Nr 4 december

4 AV HÅKAN NILSSON Förbättring, ett resultat av krafter i samverkan Produktutvecklingen har de senaste åren blivit mer och mer komplex, inte bara tekniskt sett utan även när det gäller behoven av att kommunicera och hantera olika situationer människor emellan. Marknadens önskemål om rätt produkt vid rätt tillfälle till rätt pris gör att vi i varje del och vid varje tillfälle måste överväga om vi gör rätt saker. Det finns ett antal fundamentala förutsättningar för att lyckas med produktutveckling där man ska vara väl medveten om att en verksamhet präglad av ordning och reda samt medarbetare som känner delaktighet i utvecklingsarbetet är avgörande för huruvida det tänkta resultatet kommer att uppnås eller inte. Trots att det idag måste ses som en självklarhet så upplever många företag ändå att de har brister i produktkvalitet, att projekten blir försenade och att resultatet i slutändan inte blir vad slutkunden förväntar sig. I sådana här situationer är det vanligt att initiera någon sorts förbättringsarbete. Många är vi som otaliga gånger sett och hört om förbättringsprojekt som har misslyckats på grund av olika anledningar. Det kan vara avsaknad av samsyn på vad som ska åstadkommas, lågt engagemang eller att de ändringar som gjorts ej i slutändan påverkat slutprodukten i den riktning det var tänkt. Det stannar vid stora ord och planer Det är ganska enkelt att göra analyser, sätta upp mål och tala om framtida vinster men det är lika känt att i många fall stannar hela ansatsen vid stora ord och planer. Det finns förstås en massa orsaker till detta. Det finns även det som ibland glöms bort, nämligen givna förutsättningar och begränsningar i möjligheten att ta in förbättringar i verksamheten. Här, som i så många andra fall, lämpar sig 80/20-regeln för estimering av arbetsinsatsen, 20 procent för analys, planering och strukturering, 80 procent för själva införandet i verksamheten. Från verksamheten X Nu har vi spenderat så här mycket tid och pengar på att analysera, strukturera och dokumentera. Skönt, nu är vi klara bara att börja använda. Var på webben finns det? Ofta talas det om hur viktigt det är att ha koll på helheten. Undrar om det så ofta är självklart vad som menas med just helheten. Det finns en dimension i helhetstänkandet som ofta glöms bort, nämligen samverkan genom modeller (strategier, planer, processer mm), verksamheten/förmågan (människorna och dess samverkan med maskiner) och det presterade resultatet (produkten). Det är lätt att förledas till att tro att verksamhetsförbättringar i huvudsak berör människor och beskrivningar. Det finns flera exempel på utvecklingsorganisationer där förändringar i produkten åstadkommit stora fördelar i själva verksamheten. En bra arkitektur som är enkel att förstå och som har tydliga gränssnitt speglar sig gärna i organisationen. Därför är det viktigt att ta med modellen, verksamhetens förmåga och produkten i sin helhetssyn. Ta ut siktet från början Som i de flesta fall där syftet är att med hjälp av olika tekniker få ut en större kraft eller högre fart i slutändan än vad man tillför gäller det att alla i systemet ingående delar fungerar såväl enskilt som tillsammans. Sagt av Roger Nilsson, Volvo Ocean Raceseglare och navigatör: Det hjälper inte om vi seglar 5 knop fortare än alla andra om vi seglar åt fel håll. Allt arbete som bedrivs i en organisation bör vara kopplat till företagets övergripande strategier och affärsmål, det är inte minst viktigt när vi talar om att bedriva förbättringsarbete. Det måste i varje mått och steg som tas vara väl synligt hur detta på kort eller längre sikt stöttar företaget i dess strategier och affärsmål. När detta synsätt väl är på plats blir det naturligt att alla förbättringsinitiativ stöds av och inkluderar ledningens engagemang. Sagt av projektledare: Är inte de här förbättringsaktiviteterna viktiga för ledningen så är de inte viktiga för projektet. Ska skapa problem att inte agera Vad är det som driver ett förbättringsinitiativ? Det korta svaret är ganska enkelt i sin uttrycksform, det måste göra ont att inte göra någon förbättring. Det måste vara klart hur det eller de initiativ som startas är kopplade till verksamhetens affärsmål samt beskrivet vad konsekvensen av ett misslyckat införande skulle bli. Detta i sin tur ger varje någorlunda medveten medarbetare anledning att engagera sig i det som pågår. Oavsett vad som i en organisation indike- 4 Nr 4 december 2003

5 rar problem eller förbättringspotential är det rekommendabelt att tillsammans med nyckelpersoner inom organisationen analysera förmågan, modellen och produkten dels som enskilda företeelser, dels ur samverkanshänseende. Det här är ett arbete som kräver olika former av expertis men har visat sig vara väl värt investeringen. Med andra ord kan ett förbättringsprojekt innefatta enskilda delar eller samverkan. Det gäller människornas förmåga, det gäller de beskrivningar som finns i modellen och det gäller produkten. Engagemang från ledningen viktigt Vad är det då som är de centrala delarna i ett förbättringsarbete? Ja, som i de allra flesta sammanhang handlar det om att etablera ett ansvarigt arbetslag som är mäktigt uppgiften. Detta innebär att det bör bestå av personer med förtroende i verksamheten som har förmågan att kommunicera. För att det sedan ska lyckas är det viktigt att i organisationen bygga en kultur som främjar nytänkande och förändringar. En engagerad ledning är ett krav som ej går att tulla på i sådana här sammanhang, engagemang då i form av både ord och handling vilket inte visat sig vara så enkelt i alla sammanhang. Det bör finnas en representant från ledningen involverad i varje förbättringsinitiativ som pågår. Detta brukar ge en idé om hur många och långa initiativ som kan vara igång samtidigt. Vidare måste varje medarbetare känna att det är viktigt för honom eller henne att engagera sig. Vad får denne ut på kort respektive lång sikt och hur kan man veta att någon lyssnar? Ja, detta är sånt som måste tas om hand för att få en skara engagerade medarbetare. Viktigt arbeta med information Nåväl, engagemang är bra men det kommer förstås inte att omfatta alla på företaget, förmodligen ganska få i ett inledande skede. Hur gör vi då för att skapa en förståelse för och kunskap om vad det är som händer? Det är oerhört viktigt att informera. Det är lika viktigt att informera om det tillvägagångssätt man tänker använda i samband med förbättringsinitiativet som om vad målet med densamma är och inte minst vilka problem man kommer att undvika genom att investera i detta. Det gäller alltså att säkerställa förståelse och kunskap, att utbilda olika människor inom det de förväntas hantera. Detta kan ha ett spektra på allt från entimmas informationsmöten till veckolånga kurser. Av erfarenhet vet man att det kanske allra starkaste sättet att nå framgång i förändring är att jobba med mentorer på alla nivåer i verksamheten, från högsta ledningen till samtliga medarbetare. Det svåra här är att identifiera och stödja det behov som gäller för varje grupp vid det specifika tillfället. Detta kommer nämligen att variera kraftigt över tiden. Målsättningen med mentorskapet är att den mottagande organisationen ska öka sin kunskap i sådan grad att de själva kan agera mentorer inom en snar framtid. Viktigt i alla typer av förändring är att visa dels på snabba, dels på kontinuerliga resultat, resultat som är tillgängliga för verksamheten på ett enkelt och tilltalande sätt. Det gäller även att i verksamheten skapa en kultur där det ses som en möjlighet att få kommentera och påverka de resultat som presenteras från pågående förbättringsinitiativ. Motsatsen, där man ser det som något de andra gjort och inte direkt bryr sig om, är tyvärr allt för vanlig. Praktiska råd i arbetet Vad vill jag då avsluta denna introduktion med? En förhoppning om att det inte behöver vara så besvärligt, eländigt och komplicerat att lyckas med förbättringsarbete som det ibland tycks framställas. Det gäller som i de flesta fall att låta det sunda förnuftet råda och inte göra det till något i stil med att ta ner månen. Några avslutande råd baserade på egen erfarenhet: Se alltid till så att de mål som sätts upp är realistiska och förankrade i verksamheten. Placera ansvaret på rätt nivå, ledningsgrupp och experter. I det fall det handlar om processutveckling är det viktigt att det görs i samverkan med ett projekt och att projektdeltagarna är involverade. Jobba med för verksamheten etablerad praxis och förfina efter hand. Ge stöd för projekten att anpassa arbetssätt efter behov. Etablera en struktur för fungerande erfarenhetsåtermatning och etablera ett fåtal odiskutabla mätningar. Välkommen in i en föränderlig värld. Håkan Nilsson jobbar som affärsenhetschef och konsult på Combitech Systems, i huvudsak med uppdrag rörande verksamhetsförbättring. Han har jobbat 11 år med utveckling och införande av nya arbetssätt och rutiner, både som konsult och anställd samt några år som projektledare. Håkan har varit drivande och involverad i ett antal övergripande förbättringsprogram inom såväl större som mindre organisationer. Håkan är certifierad RUP-konsult och instruktör och har erfarenhet från arbete med olika mognadsmodeller. Nr 4 december

6 AV JOHN P. KOTTER Framgångsrikt förändringsarbete Copyright Leader to Leader Institute. Publicerad med tillstånd av John Wiley & Sons, Inc. Ursprungligen publicerad på engelska i Leader to Leader nr 10, 1998, med namnet Winning at Change. Inget företag vare sig stort eller litet, lokalt eller globalt är i dag immunt mot förändringar. För att möta nya tekniska, konkurrensrelaterade och demografiska utmaningar strävar chefer inom alla sektorer efter att förändra sina företags sätt att arbeta i grunden. Detta förändringsarbete har bedrivits under många namn Total Quality Management, omställning, omstrukturering, fusioner och förvärv samt företagsakuter. Trots detta visar de flesta undersökningar att få av dessa satsningar når sina mål. Färre än 15 av de minst 100 företag som jag har studerat har lyckats göra om sig själva. De närmare omständigheterna varierar från fall till fall, men jag har funnit att förändringsprocessen inbegriper åtta kritiska steg (se ruta, sid 10). Om bara ett enda av dessa steg missköts kan det underminera en i övrigt genomtänkt vision, men det är särskilt fyra misstag som ligger bakom de flesta misslyckandena. 1. Skriva PM i stället för att slå larm. Åtminstone hälften av alla misslyckade förändringsförsök snubblar på det första kritiska steget, nämligen att frammana en känsla av allvar. Alltför ofta lanserar chefer sina initiativ genom att kalla till möten eller skicka runt konsultrapporter, varefter de tror att alla ska ge sitt oreserverade stöd. Det fungerar inte på det sättet. För att öka graden av allvar föreslår jag att du samlar en nyckelgrupp till brainstorming under en hel arbetsdag. Börja med att identifiera alla tänkbara faktorer som bidrar till att ni känner er tillfreds med er själva. Lägger ni manken till kan ni säkert hitta 25 till 50 punkter. Ansträng er sedan lika hårt för att bemöta var och en av dessa. Ta slutligen fram en handlingsplan för att genomföra idéerna. Om du tar dig an alla 25 eller 50 fronterna samtidigt ökar dina chanser avsevärt att skapa en känsla av allvar och få upp den nödvändiga farten. Det krävs dock vanligtvis mycket mer för att skapa en känsla av allvar än vad cheferna räknar med. De slarvar sig igenom detta första kritiska steg och förstår sedan ingenting när processen går i stå ett halvår senare. 2. För mycket prat utan att något blir sagt. De flesta chefer underkommunicerar sina förändringsvisioner med en faktor 10. Och deras metoder för att förmedla budskapet är de som övertygar minst högtravande tal och PM. En fungerande förändringsvision ska inte bara omfatta nya strategier och strukturer, utan även ett nytt samkört uppträdande från högsta ledningens sida. Att visa ledarskap genom att föregå med gott exempel innebär just det att ägna dramatiskt mycket mer tid åt kunderna, skära ned slösaktigt beteende på direktionsnivå och kanske lägga ned omhuldade projekt som inte håller måttet. Människor följer sina chefer särskilt sina närmaste chefer med stort intresse. Det behövs inte mycket inkonsekvent agerande från en chefs sida för att det ska föda cynism och frustration hos de underlydande. 3. Utropa sig som segrare innan slaget är över. När ett projekt är klart eller ett första delmål nått, kan det vara frestande att gratulera alla inblandade och utropa början på en ny era. Det är viktigt att fira delsegrar, men det kan sluta i katastrof om du lurar dig själv och andra om svårigheterna och tidsåtgången i samband med organisatoriska förändringar. Jag mötte nyligen en duglig och intelligent ledningsgrupp som har börjat se uppmuntrande resultat från ett krävande initiativ. De befinner sig bara sex månader in i vad som troligen är en process på tre års sikt, men börjar redan tala om avsluta det här på några månader. Rena struntpratet. De är långt ifrån där de borde vara och riskerar att förlora alla framgångar de har uppnått. Människor betraktar genomförandet av minsta delmoment som en seger i sig. Problemet är att resultatet av en förändringsvision inte är direkt proportionellt mot den nedlagda arbetsinsatsen. Det innebär att du när du klarat av en tredjedel av förändringsprocessen sannolikt inte kommer att se en tredjedel av det möjliga resultatet, utan kanske bara en tiondel. Och om du alltför tidigt låter nöja dig med alltför litet, kommer du troligen att mista allt. Att fira delsegrar är ett utmärkt sätt att markera framåtskridande och hålla engagemanget vid liv men glöm inte allt arbete som fortfarande återstår. 4. Leta efter skyldiga på fel ställen. Uppfattningen att stora företag vimlar av motsträviga mellanchefer som motsätter sig alla förändringar är inte bara orättvis utan även osann. I professionella tjänsteföretag, liksom i de flesta företag med högutbildade medarbetare, är människor på alla nivåer engagerade i förändringsprocessen. Ofta är det mellancheferna som uppmärksammar de högre cheferna på olika frågor. Faktum är att jag har funnit att de största hindren mot förändring inte är mellancheferna utan vanligtvis de som sitter en eller två nivåer under den högsta chefen, dvs. vice vd, direktörer, höga chefer och andra som inte har lyckats nå ända upp och som kanske har mest att förlora på en förändring. Det är därför det är avgörande att bygga upp allianser som representerar samtliga nivåer i företaget. Människor hör ofta högsta chefen ge en förändring sitt helhjärtade stöd och utlova nya spännande möjligheter. De flesta på mellannivå vill gärna tro på det, men alltför ofta ger deras chefer dem ingen anledning att göra det. Dessa vanliga misstag antyder att förändringsansvariga har tre viktiga uppgifter: hantera flera tidslinjer, bygga upp allianser samt formulera en vision. Arbeta med flera tidslinjer För att skapa en känsla av allvar och undvika att ta ut segern i förskott måste chefer lära sig att hantera en avgörande strategisk resurs tiden. Att agera snabbt och samtidigt se förändringen som en långsiktig process verkar som något av en paradox. Framgångsrika 6 Nr 4 december 2003

7 chefer sticker inte under stol med att meningsfulla förändringar kan ta år att genomföra. Samtidigt möjliggör de vinster på kort sikt och påminner hela tiden medarbetarna om nödvändigheten med förändringarna just därför att de tar så lång tid. När till exempel Konosuke Matsushita grundade sitt forskningsinstitut Matsushita Institute of Government and Management för människor som vill arbeta i offentlig tjänst, förklarade han att hans vision var att hjälpa japansk politik bli mindre korrumperad och göra den mer visionär. När en skeptisk reporter frågade hur lång tid detta skulle ta svarade han: Enligt mitt förmenande omkring 400 år, vilket är skälet till att vi måste börja redan idag. De bästa chefer jag har stött på balanserar kortsiktiga resultat med en långsiktig vision. (När vi talar om organisatoriska förändringar anser jag kort sikt vara sex till tolv månader.) De engagerar ledning, investerare, anställda och andra intressenter i den spännande processen att leverera resultat på både kort och lång sikt. De arbetar helt enkelt med flera tidslinjer. Resultat och vision kan ritas upp i en matris som har fyra dimensioner (se figur 1). Dåliga resultat och en svag vision betyder säkra problem för alla företag. Goda kortsiktiga resultat och en svag vision tillfredsställer många företag för ett tag. En kraftfull vision som ger få resultat överges vanligtvis. Bara goda kortsiktiga resultat och en effektiv, samordnad vision erbjuder hög sannolikhet för uthållig framgång. En del chefer tror inte att tiden räcker till för långsiktiga förändringar och fokuserar därför bara på kvartals- eller årsresultatet. Ändå tillträder många sina höga chefsbefattningar vid 50 års ålder eller tidigare och har därmed möjlighet att leda de förändringar som krävs för ett långsiktigt ledarskap. Jack Welch gick till exempel i spetsen för åtminstone tre genomgripande förändringsvisioner inom General Electric. Självfallet hade han förmånen att få börja tidigt och behålla sitt jobb under lång tid, men han hade också kvar Nr 4 december

8 jobbet just för att han gjorde den organisatoriska förändringen till en ständigt pågående flerstegsprocess. Att omdana ett företag är det definitiva testet på verkligt ledarskap, men en förståelse av förändringsprocessen är nödvändig för många aspekter av chefsjobbet. I dagens affärsvärld är det särskilt två saker som krävs förmåga att bygga upp allianser och att formulera en vision. Höga Resultat Kortvarig framgång Uthållig framgång Bygga upp allianser I dagens inte så hierarkiska men mer komplexa företag måste cheferna få stöd från anställda, samarbetspartners, investerare och myndigheter för en rad olika initiativ. Eftersom de sannolikt kommer att möta motstånd från oväntat håll är det nödvändigt att bygga upp starka allianser. Det finns tre avgörande faktorer bakom sådana allianser. Engagera rätt talanger. Att bygga upp en allians innebär mer än att bara vända sig till den som nu råkar vara chef för en avdelning, ett företag eller någon annan enhet. Det innebär att samla den nödvändiga kompetensen, erfarenheten och även personkemin. En allians mellan 20 människor som är bra chefer, men inte så effektiva som ledare, kan sannolikt inte genomföra några meningsfulla förändringar eller något annat heller. Du börjar inte nödvändigtvis med vd eller koncernchefen som din partner. Det kan vara vice vd som har något att bidra med och som dessutom kan bistå dig med den nödvändiga kontakten med linjeorganisationen. Den mest effektiva partnern har vanligtvis stor befogenhet, bred erfarenhet, hög trovärdighet och verklig ledarskapsförmåga. Utvidga alliansen strategiskt. En effektiv allians behöver precis som en bra styrelse en mångfald olika åsikter och röster. Så snart en kärngrupp har utkristalliserats blir frågan hur alliansens arbetsområde och sammansättning ska kunna breddas. Det innebär ofta att arbeta med människor utanför den egna organisationen till och med vid interna förändring- Låga Stagnation Figur 1. Svag ar. Cheferna behöver inte bara vända sig utanför det egna företaget, de måste också veta vart de ska vända sig och hur de bygger allianser. Det kan bland annat innebära att tillskriva andra framgångarna, men själv ta på sig skulden för misslyckanden. Det innebär att visa äkta omsorg om enskilda personer, men samtidigt vara realistisk i fråga om resultat och att inse att bästa sättet att få resultat är genom allierade. Arbeta som ett team, inte bara en samling enskilda personer. Chefer säger sig ofta ha ett team när de egentligen har en kommitté eller en liten hierarki. Ju mer du stärker teamkänslan, desto framgångsrikare blir alliansen och desto bättre blir den på att nå uppställda mål. Inte minst under de påfrestningar som förändringar medför måste företagets chefer på alla nivåer ha reserver av energi, kunnande och, viktigast av allt, förtroende att ösa ur. Personalproblem, som ofta lurar under ytan i ett team, ignoreras allt för lätt när allt verkar vara frid och fröjd, men visar sig med full kraft i tider av förändring. Förändringens tryck gör det nödvändigt med ett starkt team. Misslyckad vision Vision Stark Bortom de traditionella teambyggande institutionerna och evenemangen byggs verkliga team genom att utföra verkligt arbete tillsammans, dela en vision och arbeta mot ett gemensamt mål. Formulera en vision En vision om framtiden är mer emotionell än rationell. Att föregå med gott exempel är avgörande för att förmedla en vision. Men hur formulerar man egentligen en vision? Eftersom den avser framtiden utgår många från att formulerandet av en vision liknar en långsiktig planeringsprocess: designa, organisera, implementera. Jag har aldrig sett det fungera på det sättet. Att definiera en vision om framtiden låter sig inte göras enligt en tidtabell eller ett flödesdiagram. Det är en mer emotionell än rationell process. Det krävs tålamod med rörighet, otydlighet och bakslag, samt en förståelse för det halva steg tillbaka som vanligtvis följer på varje steg framåt. De dagliga kraven tvingar ofrånkomligen 8 Nr 4 december 2003

9 människor att gå i olika riktningar. Konflikter är oundvikliga. Att dela en gemensam vision eliminerar inte spänningarna mellan t.ex. försäljnings- och produktionsenheterna, men det hjälper människor göra lämpliga kompromisser. Alternativet är att gräva ned sig i ställningskrig av typen jag vinner, du förlorar som kan lamslå ett helt företag. Cheferna måste därför förmedla en vision om framtiden som är tydlig i sin avsikt, tilltalande för intressenterna och ambitiös men ändå möjlig att uppnå. Effektiva visioner är tillräckligt fokuserade för att vägleda beslutsfattandet, men ändå tillräckligt flexibla för att möjliggöra enskilda initiativ och nya omständigheter. Ett exempel är följande snävt definierade, men effektiva förändringsvision som formulerades av styrgruppen på ett företag i finansbranschen: Vi ska sänka våra kostnader med 30 procent och minska svarstiderna för kunderna med 40 procent. När detta är genomfört, om cirka tre år, kommer vi att ha... nöjdare kunder, ökad försäljningstillväxt, tryggare jobb och den enorma stolthet som det ligger i att verkligen ha lyckats. Särdrag hos effektiva chefer Det finns chefer på alla nivåer i ett företag. Längst ned i hierarkin har de självfallet allt mindre ansvar. Deras visioner kan verka mer grundläggande och de kanske bara har ett par underlydande som ska motiveras. Men de utövar samma ledarskapsroll som deras motsvarigheter högre upp. De är mästare i att se saker på ett nytt sätt och utmana det bestående. De är handlingskraftiga och verkar kunna gå rakt igenom, eller runt, hinder. Jag har funnit att människor som utövar stort ledarskap också har ett kall eller är djupt intresserade av ett område som är relaterat till deras yrkesbana. En chef för ett läkemedelsföretag kan till exempel brinna för att minska lidandet i världen. Han eller hon kan ha sett en förälder eller nära anhörig lida och kan drivas av djupt liggande känslor, inte bara intellektet. Sådana chefer fångar även upp engagemanget hos andra och länkar detta till företagets mål. De synliggör vikten av allas dagliga arbete i förhållande till det övergripande målet. Stora chefer fortsätter att ta risker Det mest utmärkande särdraget hos stora chefer, framför allt de som är bra på att leda förändringar, är deras sökande efter kunskap. De visar en exceptionell beredvillighet att pressa sig till osäkerhetens gräns, till och med när de har uppnått en hel del. De fortsätter att ta risker, till och med när det inte finns något uppenbart skäl för dem att göra det. De är öppna för människor och idéer, till och med när de har kommit till en punkt i livet när de mot bakgrund av sina framgångar skulle kunna hävda att de redan vet allt. Ofta drivs de av mål eller ideal som är större än vad enskilda personer kan uppnå och denna drivkraft sporrar dem till fortsatt kunskapsinhämtning. Chefer lägger ned oerhörd talang, energi Nr 4 december

10 Åtta steg för att förändra ditt företag 1. Skapa en känsla av allvar Analysera marknad och konkurrensförhållanden Identifiera och diskutera kriser, potentiella kriser och viktigare möjligheter 2. Bygga upp en kraftfull och beslutsam allians Samla en grupp med tillräcklig befogenhet för att leda förändringsarbetet Få gruppen att fungera som ett team 3. Formulera en vision Formulera en vision som vägleder förändringsarbetet Ta fram strategier för att uppnå visionen 4. Förmedla visionen Ta vara på varje tänkbar möjlighet för att förmedla företagets nya vision och strategier Lär ut nya beteenden genom att låta alliansen föregå med gott exempel 5. Ge andra befogenhet att agera i enlighet med visionen Eliminera hinder för förändringen Ändra system eller strukturer som allvarligt underminerar visionen Uppmuntra risktagande och okonventionella idéer, aktiviteter och åtgärder 6. Planera för och möjliggör vinster på kort sikt Planera för synbara resultatförbättringar Genomför dessa förbättringar Erkänn och belöna medarbetare som bidrar till förändringarna 7. Konsolidera förbättringarna och förändra ännu mer Utnyttja den ökade trovärdigheten för att förändra system, strukturer och principer som inte stämmer med visionen Anställ, befordra och utveckla medarbetare som kan implementera visionen Blås nytt liv i processen med nya projekt, teman och förespråkare av förändringar 8. Institutionalisera nya arbetssätt Understryk kopplingen mellan de nya arbetssätten och företagets framgångar Ta fram procedurer som säkerställer ledarskapets utveckling och fortlevnad och omsorg på sitt förändringsarbete, ändå är det få som får resultat de hoppades på. Det finns goda skäl till varför så få företag har lyckats omvandla sig själva. Dagens chefer saknar helt enkelt erfarenhet från storskaliga förändringar. För trettio år sedan var det få företag som övervägde radikala förändringar, så det finns få praktiska erfarenheter att överföra till en ny generation chefer. De goda nyheterna är att andelen tveklöst kommer att öka. De förändringar som genomförs rutinmässigt av dagens företag som producerar allt bättre produkter, snabbare och till lägre kostnader var otänkbara för 30 år sedan. Under nästa decennium kommer tusentals chefer att leda smått fantastiska förändringar. Det är inte bara en helt säker förutsägelse det är en social och ekonomisk nödvändighet. Alla företag behöver ett effektivt ledarskap, men ingenstans är detta behov större än i företag som försöker förändra sig själva. Drivkraften bakom förändringar Företag förändras för att de måste samt av en rad andra skäl. Den största drivkraften till förändringar i företag tenderar dock att vara en ny chef på en nyckelposition. Inom företagen återfinns de förändringsansvariga på allt från mellannivå till den högsta ledningen. Det handlar ofta om en ny chef på divisionsnivå eller en ny avdelningschef, någon med nya perspektiv som inser att stillastående inte är acceptabelt. Det finns visserligen inte någon entydig förklaring till alla förändringar, men det finns ett tydligt mönster bakom misslyckandena. Oftast handlar det om en chef som försöker snabba på ett kritiskt steg i förändringsprocessen. Självfallet finns det utrymme för flexibilitet i de åtta stegen bakom en lyckad förändring men utrymmet är inte stort. När chefer t.ex. säger att de ska ge sina medarbetare befogenhet att agera mer självständigt, men att de inte tänker ägna någon större möda åt att förändra företaget i grunden, kommer de så gott som säkert att misslyckas. Förändring handlar till 80 procent om ledarskap fastställa riktning, samordna, motivera och inspirera människor och till 20 procent om administration planera, budgetera, organisera och lösa problem. I de flesta förändringsförsök som jag har studerat de senaste 20 åren råder tyvärr det omvända förhållandet. Våra handelshögskolor och branschinstitut fortsätter att producera bra administratörer. Vad vi dessutom behöver göra är att utveckla duktiga chefer. John P. Kotter innehar Konosuke Matsushita-professuren i ledarskap vid Harvard Business School och är en ofta anlitad talare vid ledarskapskonferenser över hela världen. Han har skrivit sex böcker som alla har nått stora upplagor. 10 Nr 4 december 2003

11 AV WATTS S. HUMPHREY Trovärdighet och åtagande Copyright Watts S. Humphrey. Publicerad med tillstånd av Watts S. Humphrey. Ursprungligen publicerad på engelska på med namnet Credibility and Commitment. Bill hade arbetat som mjukvaruansvarig i något mer än en månad. Han var nu chef för ett mycket stort mjukvaruprojekt och alla hans 12 toppchefer fanns på plats i rummet. Denna utvecklingsgrupp hade aldrig hållit en tidsgräns tidigare, men nu behövde företaget verkligen deras produkt snabbt. Bill hade framgångsrikt lett flera tidigare projekt och hade nu valts ut för att reda upp i det här projektet. Vincent, företagets vice vd, hade kallat till mötet med Bill och dennes närmaste programmeringsansvariga. Vincent ägnade de första 20 minuterna åt att skälla ut alla. Företaget var redo att leverera hårdvaran, men mjukvaran var inte klar. Gruppen hade lovat att leverera för månader sedan och hade missat varenda deadline. Nu var det ingen som trodde på dem. Vincent krävde en leveransplan inom två veckor. När Vincent slutade prata riktades alla blickar mot Bill. Det var dags att stå upp för sin sak eller stänga butiken. Bill visste att det inte var möjligt att få fram en projektplan på två veckor. Hundratals människor arbetade med projektet och det skulle ta en vecka att bara tala om för alla vad de skulle göra. Bill visste att en tidtabell utan en plan inte skulle vara något annat än en gissning, och att gissa var det sista han ville göra just nu. De nya datumen skulle då inte vara ett dugg bättre än något av de tidigare och det skulle bara vara en tidsfråga innan Bill slängdes ut tillsammans med alla de övriga misslyckade programmeringscheferna. Bill visste inte hur Vincent skulle reagera, men han visste att om han inte tog ställning nu så skulle han aldrig få ett bättre tillfälle. Han tänkte att eftersom han just hade fått jobbet så skulle de inte sparka honom så här snart. Vi skulle kunna gissa och ge dig ett svar idag, men om du vill ha ett datum som verkligen håller måste vi ta fram en plan och det tar 60 dagar, sa Bill till Vincent. Vincent såg överraskad ut. Han såg sig omkring i rummet och frågade de övriga cheferna vad de trodde. Alla som fick frågan svarade: Visst, det tar 60 dagar att ta fram en plan. Till sist instämde Vincent och gav projektet de 60 dagar som behövdes för att ta fram en plan och en tidtabell. Efter mötet hyllades Bill som en hjälte. För första gången hade deras chef stått emot ledningen och gett dem tid att ta fram en riktig plan. Bill fick aldrig reda på om Vincent hade iscensatt mötet för att testa honom, men det spelade ingen roll effekten var fantastisk. Cheferna var nu fast beslutna att ta fram en plan på 60 dagar och de avsåg verkligen att ta fram en som de faktiskt skulle kunna hålla. Och de lyckades också ta fram planen på 60 dagar. Med tillräckligt med tid att ta fram en genomtänkt plan kunde cheferna nu jämföra det nya resultatet med vad de hade åstadkommit tidigare. Genom att använda historiska data kunde de vara mycket mer realistiska. Tidtabellen blev längre än vad någon egentligen ville och flera av nyckelfunktionerna spreds ut över flera releaser. Vad som överraskade alla var att med en realistisk tidtabell kunde de nu koncentrera sig på arbetet istället för att försvara sig. De fann att de hann med sina stoppdatum och att de också kunde lita på att kollegorna hann med sina. Som ett resultat av detta levererade de den första releasen före utsatt tid och missade inte ett enda leveransdatum under de följande två och ett halvt åren. Skillnaden mellan en gissning och ett åtagande Det finns en grundläggande skillnad mellan en gissning och ett åtagande. Även om de båda pekar på samma datum finns det ingen substans bakom gissningen. I fallet med ett åtagande har programmerarna noga tänkt igenom arbetet och hur de ska utföra det. De har jämfört den nya uppgiften med data från tidigare arbeten och har förbundit sig själva till planen. De har noga tagit fram planen och tänker verkligen leverera produkten när de säger att de ska göra det. Det är en fråga om personlig heder. I fallet med en gissning finns det inte någon som har något ansvar. Chefen har bara trollat fram datumet ur en hatt. Trots att det Nr 4 december

12 kan vara ett sannolikt datum, och chefen offentligt förbinder sig för det, har ingen av programmerarna tänkt igenom själva arbetet. De har inte planerat hur de ska arbeta och deras heder står inte på spel. Viktigast av allt är att det bara är chefen som äger datumet. Programmerarnas inställning kan bäst sammanfattas med vad en missnöjd programmerare en gång sa: Det är hans datum och jag kan bara önska honom lycka till. Den främsta regeln i samband med planering är att om du inte arbetar tillräckligt hårt för att ta fram ett leveransdatum så arbetar du inte heller tillräckligt hårt för att infria det. Att tro på magi För att se vad planering kan åstadkomma kan vi ta följande hypotetiska exempel. Du är ansvarig för utvecklingen av ett stort program och du har tilldelats ett utvecklingsteam som ska göra jobbet. Ledningen kräver dock att du först tar fram en plan och tidtabell för arbetet. Låt oss anta att du tar fram planen med hjälp av ett magiskt planeringsverktyg. Det talar om för dig hur lång tid utvecklingsarbetet kommer att ta och hur stor slutprodukten kommer att bli. Allt du behöver göra är att mata in alla kravdata och, voilà, ut kommer storleken på den slutliga produkten och tiden, i manmånader, som själva programmeringen tar. Det finns dock en begränsning. Verktyget talar bara om bästa möjliga storlek och utvecklingstid. Det utgår från att du har världens bästa utvecklingsteam och att de kommer att ta fram det absolut bästa systemet. Det antar också att inget går fel, att du får alla resurser du behöver när du behöver dem och att dina medarbetare kommer att bygga precis rätt system första gången. Även om du skulle kunna få tag i ett sådant magiskt verktyg skulle du fortfarande behöva fundera ut hur denna idealiska produkt skiljer sig från den som ditt team kommer att ta fram. Du måste sedan beräkna hur mycket längre tid ditt team behöver för att utföra arbetet. Vidare behöver du fundera på vad som kan gå fel, hur mycket tid varje missöde kommer att ta och vilken beredskap som behövs för kravändringar, bemanningsfrågor, testning, omarbetning, semestrar, sjukfrånvaro, möten m.m. Det innebär att ett magiskt planeringsverktyg egentligen inte skulle vara till särskilt stor hjälp. Även om det kan tala om för dig om det begärda datumet är bättre än världsrekordet, kan det inte tala om för dig när du realistiskt kan förvänta dig att bli klar. Det betyder att sökandet efter magiska planeringsverktyg, modeller eller metoder är slöseri med tid. Till och med när de fungerar som de ska, ger de bara teoretiska siffror som inte representerar verkligheten för det aktuella teamet eller projektet. Vad återstår? Vad som återstår är behovet att ta fram en plan. Det kräver en detaljerad studie av det aktuella projektet. Du kan därefter bedöma den sannolika storleken på produkten och göra jämförelser med tidigare projekt. Med en uppskattning av arbetet som ska göras kan du fördela uppgifter, bedöma hur mycket tid varje uppgift sannolikt tar och ta fram en tidtabell för arbetet. När planen sedan är klar kan du förhandla fram ett realistiskt åtagande. Vad menas med ett åtagande? Ett åtagande är en överenskommelse om att göra något. Låt oss till exempel anta att herr A samtycker till att utveckla en mjukvaruprodukt åt fru B till ett visst datum. Det är ett åtagande. Åtagandets kvalitet beror på hur ansvarsfull herr A är när han presenterar datumet och hur realistisk fru B är när hon talar om vad hon vill ha. För att ett åtagande ska vara meningsfullt måste personen som gör åtagandet också vara inställd på att hålla överenskommelsen. Det innebär att när herr A åtar sig att vara klar med utvecklingsarbetet ett visst datum måste han verkligen mena det. För att göra detta på ett ansvarsfullt sätt måste han tänka igenom arbetet, uppskatta den inbegripna arbetsmängden och sedan bestämma ett slutdatum. Åtagandets olika delar utgörs då av: en person som vill ha en arbetsuppgift utförd en annan person som tar på sig att utföra arbetet ett pris och ett datum för arbetet som båda är överens om. Även om det ofta finns kontraktsmässiga och tekniska specifikationer för arbetet, utgör åtagandets främsta delar en överenskommelse om en arbetsspecifikation, en tidtabell och ett pris. Förhandling kring åtagandet I det enklaste fallet är ett åtagande en överenskommelse mellan två parter om att göra något som är viktigt för dem båda. Ingen av parterna vill ha ett orealistiskt datum. I vårt exempel vill fru B ha det tidigaste datum som hon kan få herr A att gå med på. Även om hon troligen skulle godta det tidigaste datum hon kan få, är hon egentligen mest intresserad av att få herr A att arbeta så hårt han kan för att det aktuella projektet ska bli klart så snabbt som möjligt. Å andra sidan vill herr A också bli klar med jobbet så snabbt som möjligt. Men han skulle också vilja ha utrymme i tidtabellen om något skulle gå fel. Han är inte helt säker på hur stort jobbet verkligen är och skulle vilja ha en buffert om något är mer omfattande än förväntat. Han vill därför ha en realistisk tidtabell, men en som kan jämkas något i slutänden. Med dessa motstridiga önskemål är det helt klart att åtagandet måste bli föremål för en förhandling. Herr A vill ha det senaste datumet han rimligtvis kan få och fru B vill ha det tidigaste. Med användande av alla slags data, argument och befogenheter de kan frammana, ska de på något sätt komma fram 12 Nr 4 december 2003

13 till ett datum som de båda är överens om. Poängen är att när överenskommelsen sluts vet ingen av parterna hur lång tid jobbet kommer att ta. Även om chefen har befogenhet och inflytande och programmeraren besitter kompetensen behöver båda den andras samtycke. Sådana förhandlingar kan verka jämspelta, men chefen har en viktig fördel. Om vi antar att herr A inte helt säkert vet hur lång tid jobbet kommer att ta, får han förlita sig på sin intuition och sin övertalningsförmåga. Om han förhandlar med sin chef befinner han sig i ett allvarligt underläge. Han vet att fru B:s uppfattning om hans arbete är avgörande för hans framtid. Oavsett om det är realistiskt eller inte, bär han alltid på en oro över att förhandlingarna kan påverka hans vitsord, karriärutsikter och lön. För att få stöd i denna diskussion om åtaganden behöver herr A några verktyg. De enda verksamma verktygen är dock planeringsförmåga, data om jobbets storlek, kostnaden för tidigare likartade jobb samt planen för detta jobb. Herr A:s förhandlingsstyrka hänger nästan helt på data som han kan uppbåda från detta och andra liknande jobb. Fru B har i allmänhet bemyndigande som herr A:s chef. Hon har inflytande över hans lönesättning och skulle kunna välja någon annan för jobbet. Och om han inte har andra projekt att arbeta på kan herr A till och med få sparken. Fru B har därför en kolossal förhandlingsstyrka över herr A. Även i förhandlingar med kunder är programmerare relativt maktlösa. Kunderna kan välja andra leverantörer, insistera på tuffa kontraktsvillkor eller orsaka andra otrevligheter. Även om dessa krav inte direkt påverkar programmerarna, påverkar de deras chefer som sedan pressar programmerarna. Utan uppbackning av en plan som baseras på trovärdiga data har programmerarna nästan inget inflytande i dessa diskussioner om tidtabeller. Fördelen med trovärdighet Det finns dock ett undantag från programmerarens maktlöshet. Men bara om herr A har trovärdighet. Till exempel hade Bill tidigare genomfört flera projekt i tid och Vincent litade på honom och trodde på vad han sa. Låt oss anta att herr A redan har genomfört flera projekt på utsatt tid eller tidigare. Om nu herr A säger att ett jobb tar fyra månader kommer fru B förmodligen inte att argumentera. Hon kan be om data som stöder hans påstående, men hon vet att herr A gör vad han åtar sig och att han genomför det enligt den beslutade tidtabellen. Trovärdighet har tyngd. När programmerare har trovärdighet kan de diskutera tidtabeller utifrån en styrkeposition. Alla tror på dem när de föreslår ett datum. Faktum är att en programmerare med trovärdighet är som ett magiskt planeringsverktyg, ett som är skräddarsytt för jobbet som ska göras. Cheferna frågar bara den trovärdige programmeraren hur lång tid och hur mycket resurser som jobbet kräver och, voilà, så har de ett datum de kan lita på. Även om det kan ta ett tag för programmeraren att ta fram en plan, vet alla att när de får den så är den något som det var värt att vänta på. Vinna trovärdighet Särskilt i vår verksamhet finns det ingen som tror på tidtabeller för mjukvara. Till och med ledande mjukvaruföretag flyttar rutinmässigt fram sina datum flera gånger före leverans. Som programmerare har vi alltid ett ofördelaktigt utgångsläge. Ingen tror oss. Vi har ingen trovärdighet. För att få trovärdighet måste vi förtjäna den. Och enda sättet vi kan vinna trovärdighet på är att hela tiden uppfylla våra åtaganden. Även om din trovärdighet tål en eller annan motgång, är linjen hårfin. Det är som ett bankkonto. Om du sätter in tillräckligt med pengar kan du även göra ett och annat uttag. Men till slut när du gör ett uttag är saldot nere på noll. För att behålla trovärdigheten måste du fortsätta att leverera dina jobb i tid och missar du en enda gång måste du på nytt börja göra dig förtjänt av den. För att vinna trovärdighet måste du därför planera arbetet och du måste ta fram planer som är realistiskt förankrade i dina tidigare prestationer. Sedan ska du bara åta dig något när du har en plan. Om du gör det blir dina åtaganden ansvarsfulla och du kommer att få lättare att infria dem varje gång. Först då kommer du att respekteras som en kompetent programmerare. Du får mer arbetstillfredsställelse och glädje av arbetet och du kommer att ha trovärdighet. Watts S. Humphrey är initiativtagare till utbildningsprogrammet i programvaruprocesser vid Software Engineering Institute på Carnegie Mellon University. Han arbetar som forskare vid institutet och sitter även i dess styrelse. Mellan 1959 och 1986 var han knuten till IBM, där han var direktör för programmeringskvalitet och programmeringsprocesser. Han är författare till en rad tekniska artiklar och sju böcker. Han innehar fem amerikanska patent. Watts S. Humphrey utsågs 1998 till hedersdoktor i programvaruutveckling av Embry Riddle Aeronautical University. År 2000 fick Watts Humphrey Software Quality Institute i Chennai, Indien, sitt namn till hans ära. Nr 4 december

14 AV KARL E. WIEGERS Varför är processförbättring så svårt? Copyright CMP Media LLC. Publicerad med tillstånd av CMP Media LLC. Ursprungligen publicerad på engelska i Software Development magazine med namnet Why Is Process Improvement So Hard?. Jag har aldrig mött någon som sanningsenligt kan säga: Den mjukvara jag skapar idag är så bra som den överhuvudtaget kan bli. Jag vet i alla fall att jag inte kan det. De som inte med fog kan hävda detta, bör alltid försöka bli bättre på att hantera och genomföra sina mjukvaruprojekt. Det är det som är själva kärnan bakom en förbättring av mjukvaruutvecklingsprocessen. Det verkar så enkelt och i litteraturen finns en rad framgångshistorier om företag som på ett avgörande sätt har förbättrat sin mjukvaruutveckling och projektledning. Men många mjukvaruföretag som försöker förbättra sina processer klarar inte att uppnå signifikanta och varaktiga förbättringar i fråga om genomförandet av sina projekt. Varför är något som verkar så enkelt så svårt att uppnå i praktiken? När allt kommer omkring har vi ju förebilder i form av framgångsrika företag som publicerar sina erfarenheter av processförbättringar samt en växande flora av bästa praxis från mjukvarubranschen att lära av. Institutioner som Software Engineering Institute har gett oss flera (kanske alltför många) ramverk som vägledning i vår strävan efter processförbättringar. Som konsult träffar jag rader av smarta mjukvaruutvecklare och chefer som i flera fall har svårt att få rimlig avkastning på sina investeringar i förbättringar av mjukvaruutvecklingsprocessen. I denna artikel tar jag upp fem viktiga skäl till varför det är svårt att få processförbättringar att fungera och ger några förslag på hur man undviker fallgroparna. Tiden räcker inte till Vanvettiga tidtabeller ger inte tillräckligt med tid åt det nödvändiga projektarbetet, för att inte tala om åt att undersöka och införa bättre arbetssätt. Inga mjukvarugrupper har gott om tid att ta reda på var felet ligger i deras nuvarande utvecklingsprocesser och vad som borde göras på annat sätt. Kunder och högre chefer kräver mer mjukvara, snabbare, med högre kvalitet, och förresten så behöver vi slimma organisationen en smula och vi har inte råd att betala övertid, så tyvärr. En konsekvens är att mjukvaruföretag kanske kan leverera release 1.0 i tid, men sedan måste de släppa release 1.01 i det närmaste omedelbart därefter för att åtgärda de värsta buggarna. En del av problemet är inställningen att tidpunkten för den första releasen är den enda viktiga faktorn för ett lyckat projekt. Även om så ibland är fallet, tror jag det är sant betydligt mer sällan än vad som hävdas. Jag använder själv ett antal välkända kommersiella mjukvaruprodukter som kan ha hållit sina leveransdatum (fast helt säker är jag inte), men själv skulle jag dra mig för att medge att jag ingick i utvecklingsteamet. Jag skulle ha föredragit om utvecklarna hade ägnat mer kraft åt att förbättra kvaliteten, vilken är en konsekvens av flera processförbättrande insatser. Kvalitetsbrister som åtgärdas sent i projekt kan få tidtabellen att spricka, men processer som bygger in kvalitet redan från början kan faktiskt förkorta cykeltiderna. Denna fördel är inte uppenbar för dem som inte förstår att uppskatta den möjliga tre- till tiofaldiga avkastningen på investeringar i kvalitet (enligt Capers Jones). Ett holistiskt kvalitetskostnadsperspektiv ser till en produkts samlade livscykelkostnader, inklusive kostnader för underhåll och kundsupport, inte bara till tidpunkten för den första releasen. Men inte ens det synsättet tar hänsyn till den tid som jag, kunden, förlorar när jag försöker ta mig runt buggar i mjukvaran eller min irritation över företaget som sålde den till mig. Tillverkande företag vet att deras maskiner med jämna mellanrum behöver tas ur drift för installation av nya verktyg, förebyggande underhåll samt installation av produktivitetseller kvalitetshöjande uppgraderingar. Produktchefer och marknadsavdelningar ser dessa planerade driftstopp som nödvändiga och anpassar sina produktionsscheman efter dem. Processförbättring är mjukvarubranschens motsvarighet till maskinuppgraderingar. Den uppgraderar möjligheten för både enskilda och företag att genomföra mjukvaruprojekt. Men det går egentligen inte att stänga av mjukvaruutvecklingsmaskinen, utan uppgraderingarna måste införas parallellt med produktionsarbetet. Det är alltid svårt att få tiden att räcka till, men jag känner faktiskt till ett webbutvecklingsprojekt som avsätter några veckor mellan releaserna för att utforska ny teknik, experimentera och införa förbättringar. En återkommande releaseplan ger möjlighet att gå igenom vad som gick bra och mindre bra med den senaste releasen, fokusera en del förbättringskraft på ett eller två högprioriterade områden samt överföra förbättrade arbetsmetoder till nästa release. Processförbättringsaktiviteterna måste integreras med utvecklingsarbetet så att de blir ett rutinmässigt inslag i varje projekt. Avdela en viss procentandel av utvecklingsinsatserna åt fortlöpande processförbättringar 10 procent om du menar allvar med förbättringarna, 5 procent om du vill göra märkbara framsteg eller 2 procent om du vill se ut som om du gör något. Inkludera dessa resurser och uppgifter i projektplanerna och tidtabellerna. Låt inte den tekniska personalen arbeta enbart med själva projektarbetet i en förhoppning att processförbättringarna blir gjorda av sig själva det blir de inte. Om du inte redan imorgon börjar ägna mer tid åt att förbättra hur du utför dina tekniska och administrativa arbetsuppgifter, kan du vara säker på att nästa projekt inte blir ett dugg bättre än det nuvarande. Bristande kunskaper Ett andra hinder för generell processförbättring är att många som arbetar i mjukvarubranschen inte verkar känna till bästa branschpraxis. Jag brukar genomföra informella undersökningar på konferenser och utbildningsseminarier och fråga hur många av deltagarna som tillämpar en eller flera 14 Nr 4 december 2003

15 arbetsmetoder och hur många som känner till de frågor som jag tar upp. Mina ovetenskapliga data antyder att en genomsnittlig mjukvaruutvecklare inte ägnar mycket tid åt att studera litteraturen för att lära sig de mest kända mjukvaruutvecklingsmetoderna. Programmerare kanske köper böcker om Java och COM, men de letar inte efter något om processer, testning eller kvalitet på bokhyllorna. Branschens kännedom om ramverk för processförbättringar, t.ex. mognadsmodellen för programvara (SW-CMM), har ökat på senare år, men effektiva och vettiga applikationer är fortfarande ganska sällsynta. Alltför få utvecklare och chefer tillämpar aktivt de erfarenheter på mjukvaruområdet som finns inom branschorganisationer som t.ex. IEEE Software Engineerings samling av standarder ( Mycket av branschens erkänt bästa praxis har helt enkelt inte fått någon större spridning bland mjukvaruutvecklarna. Denna praxis inkluderar formella inspektioner, riskhantering, förändringshantering, mätbaserad analys och uppföljning av projekt samt kravhantering. Läs litteraturen för att övervinna detta hinder för en framgångsrik mjukvaruutvecklingsprocess! Lär om branschens bästa praxis från källor som Steve McConnells Rapid Development: Taming Wild Software Schedules (Microsoft Press, 1996) och Norm Browns artikel Industrial-Strength Management Strategies (IEEE Software, juli 1996). Utnyttja delandet av lokal bästa praxis bland medarbetarna i din grupp eller på din avdelning, så att alla får möjlighet att lära av de som besitter specialkunskaper på vissa områden. Genomför regelbundna lunchföreläsningar (fyllda med pizza, socker och koffein) där teammedlemmarna turas om att välja en artikel eller ett bokkapitel att läsa, diskutera och försöka tillämpa i projektet. Är du chef ska du belöna de teammedlemmar som gör sig extra besvär för att lära sig och tillämpa metoder som kan lösa gruppens tekniska och administrativa utmaningar. Informationen Nr 4 december

16 finns någonstans därute, du behöver bara ta dig tid att hitta och använda den. Fel anledningar En del företag genomför processförbättringar av fel anledningar. Det kan vara någon extern kraft, t.ex. en underleverantör, som kräver att utvecklingsorganisationen uppnår CMMnivå X vid ett visst datum Y. Eller kanske någon av de högre cheferna har lärt sig tillräckligt om CMM för att röra om i grytan och kräva att företaget tar plats på CMMtåget. Någon berättade nyligen för mig att hans företag försökte uppnå CMM-nivå 2 (av fem), men när jag frågade varför kunde han inte ge något svar. Han borde ha kunnat beskriva några problem som arbetssättet och metoderna på nivå 2 skulle kunna hjälpa till att lösa eller de affärsmål som hans företag hoppades kunna uppnå som en följd av att ha uppnått nivå 2. Det grundläggande motivet till en förbättring av mjukvaruutvecklingsprocessen borde vara att eliminera en del av de problem som kännetecknar de nuvarande projekten. Medlemmarna i ett team motiveras sällan av till synes godtyckliga mål om att uppnå en högre mognadsnivå eller en extern certifiering bara för att någon har bestämt det. De flesta människor borde motiveras av möjligheten att kunna genomföra sina åtaganden, öka kundernas tillfredsställelse och leverera utmärkta produkter som motsvarar kundernas förväntningar. Jag känner till flera processförbättringar som omedelbart har stött på motstånd från fältet när de motiveras med att det handlar om CMM utan att tydligt motiveras med varför de är nödvändiga och vilka fördelar som teamet hoppas uppnå. Börja med att göra en självanalys. Vilka aspekter av de nuvarande arbetsmetoderna medför de flesta sena nätterna vid tangentbordet? Vilka situationer leder oftast till frustrerande omarbetningar av redan klara delar? Kämpar du mest med att uppfylla tidtabeller, tillämpa ny teknik effektivt, utveckla rätt produkt eller uppnå önskad kvalitetsnivå? Förmodligen känner du redan till de smärtsamma faror som hotar, men en extern processutvärdering kan fokusera på och föra upp dessa problemområden till ytan. Efteranalyser eller underhandsanalyser av projekt kan även erbjuda ett strukturerat sätt att tänka igenom vad som har gått bra så här långt (fortsätt så!) och vad som har gått mindre bra (gör på annat sätt!). Dogmatiska tillvägagångssätt Ett fjärde hinder för en effektiv processförbättring är checklistementaliteten, ett stelbent och dogmatiskt införande av CMM eller andra ramverk för processförbättringar. Checklistementaliteten fokuserar på det falska målet att uppnå någon form av processcertifiering, inte det verkliga målet att förbättra projektresultaten. Jag har hört chefer hävda att bara för att deras team har lyckats skapa den lika berömda som häftiga stora pärmen med utvecklingsprocedurer, så har de uppnått processförbättring. Visst? Nix! Kontentan av processförbättring är att teammedlemmarna arbetar på ett nytt sätt som ger dem ett bättre totalresultat. Ett företag kan ha de mest fantastiska procedurer och processer, men om ingen följer dem, om de samlar damm på hyllan, om alla fortsätter att arbeta som de alltid har gjort, så har processförbättringen misslyckats. Processförändring är en kulturell förändring. Därför måste chefer och förändringsansvariga inse att de måste förändra företagets hela kultur, inte bara införa nya sätt att arbeta. Att förändra hur människor tänker och agerar är mycket svårare än att installera en ny produktionsutrustning som går dubbelt så snabbt som den gamla. Företagets chefer måste styra teamet mot bättre arbetssätt genom att ställa upp realistiska (inte ouppnåeliga) förbättringsmål, knyta processförbättringar till affärsresultaten, föregå med gott exempel och visa uppskattning av alla som bidrar till att genomföra förändringen. Du behöver inte leva upp till varenda förväntning som presenteras inom ramen för processförbättringar som CMM. De är menade som riktlinjer som användarna på ett klokt sätt ska anpassa till sina förutsättningar (se min artikel Molding the CMM to Your Organization i Software Development, maj 1998). Till exempel har många utvecklingsorganisationer problem med sina kravspecifikationer och testningsprocedurer, men dessa frågor behandlas inte alls av huvudprocessområdena på CMM-nivå 2. Är det trasigt, måste det lagas oavsett vad checklistan säger. Nya processer måste vara flexibla och realistiska. Jag känner till ett företag som krävde att alla produkter för mjukvarurelaterat arbete skulle inspekteras formellt. Det kan se bra ut på papperet, men är inte praktiskt genomförbart för de flesta företag. Deras dispensprocess skulle få arbeta övertid samtidigt som användarna skulle spela ett spel för att se ut som om de följde denna orealistiska policy. Om en process inte ger önskat resultat när den tillämpas med gott uppsåt av insatta användare, är den inte rätt process. Människor hittar alltid vägar att ta sig runt omöjliga processer. Teammedlemmar måste förstå att inte alla nya processer gagnar dem personligen och omedelbart. De flesta reagerar direkt på en begäran att göra något nytt med Vad får jag ut av det? Den rätta frågan är Vad får vi ut av det? Vinnlägg dig om en teaminställning som visar hur en förändring i hur person A arbetar kan ge betydande långsiktiga fördelar för personerna B och C längre ned längs utvecklings- och underhållskedjan, även om person A måste arbeta hårdare än vad som krävs idag. Otillräckligt engagemang Ett sista skäl till varför en förbättring av mjukvaruutvecklingsprocessen misslyckas är att företag ofta har de bästa avsikter, men saknar äkta engagemang för processförbättringar. De börjar med en processanalys, men lyckas inte följa upp med faktiska förändringar. Ledningen ställer inte några krav på utvecklarna i fråga om processförbättringar, 16 Nr 4 december 2003

17 Förbättrat framtida läge vecklingsprocesserna som ett medel att nå målet, inte som ett mål i sig själv. Produktivitet Utgångsläge Processförbättringen inleds Inlärningskurva Räkna med att förbättringarna tar tid. Förvänta dig inga omedelbara mirakel. Tänk på inlärningskurvan. Anpassa på ett klokt sätt befintliga förbättringsmodeller och bästa branschpraxis till företagets situation. Välj en av de etablerade arbetsmetoderna och använd den som en vägledning, inte som en tvångströja. Figur 1. allokerar otillräckliga resurser, tar inte fram någon förbättringsplan, tar inte fram någon vägkarta och leder inte införandet av nya processer. Det kan lätt hända att det inte blir någon avkastning alls på investeringar som görs för att förbättra mjukvaruutvecklingsprocessen. Det kan hända när ett företag investerar i analyser av sina processer, utbildar teamet, skriver handlingsplaner för processförbättringar och tar fram nya procedurer, men aldrig på allvar ändrar hur företagets medarbetare arbetar. Följden blir att cheferna tappar förtroende och intresse, att användarna drar slutsatsen att allt precis som de misstänkte bara var ett spel för galleriet samt att frustrerade processförändringsansvariga byter jobb. Ibland kan den första entusiasmen och engagemanget lägga sig när några snabba resultat inte märks omedelbart. Andra förbättringsmetoder, såsom användning av verktyg för statisk kodanalys, kan ge bättre resultat omedelbart. Det kan ta betydligt längre tid innan andra metoder, t.ex. mätbaserade uppskattningar, ger resultat. Respektera realiteten bakom inlärningskurvan, eller J-kurvan för teknikinförande (figur 1). De investeringar som görs i processför- Hoppa inte av här! Tid bättringar påverkar den nuvarande produktiviteten, eftersom tiden som ägnas åt att utveckla bättre sätt att arbeta imorgon inte är tillgänglig för dagens uppgifter. Det kan vara frestande att avbryta hela projektet när skeptikerna ser hur den energi de vill lägga på omedelbara krav tappas av i hopp om en bättre framtid. Ge inte upp! Hämta motivation från de i högsta grad verkliga och långsiktiga fördelar som många företag (såsom Motorola, Hewlett-Packard, Raytheon, Boeing samt andra som inte har publicerat sina erfarenheter) har vunnit från uthålliga förbättringar av sina mjukvaruutvecklingsprocesser. Vad kan du göra? Här är några tips för att undvika fallgroparna i samband med processförbättringar: Inse att förbättring av mjukvaruutvecklingsprocesserna är en nödvändig strategisk investering i företagets framtid. Om du inte börjar nu, blir det bara svårare att hålla jämna steg med de företag som redan har börjat. Fokusera på affärsresultatet du vill uppnå och använd förbättringen av mjukvaruut- Hantera processförbättringen som ett projekt. Ta fram en strategisk processförbättringsplan för företaget och taktiska handlingsplaner för varje fokuserad förbättringsinsats. Allokera resurser, bedöm risker, ta fram tidtabeller, följ upp utvecklingen mot planerna, mät resultaten och fira framgångarna. Du kan göra betydande framsteg i hur du skapar mjukvara. Faktum är att det är nödvändigt. Karl E.Wiegers är chefskonsult på Process Impact, ett konsult- och utbildningsföretag inom området mjukvaruprocesser. Han har skrivit flera böcker och 160 artiklar om en rad aspekter av utveckling och hantering av mjukvara, kemi samt militärhistoria. Karl har ingått i IEEE Software Magazines redaktionskommitté och är skrivande redaktör på Software Development Magazine. Nr 4 december

18 AV SVEN WENNERSTRÖM Ny utvecklingsmiljö infördes i helikopterprojekt När Saab Tech drog igång projektet med ett stridsledningssystem till Helikopter 14, passade man på att också förändra utvecklingsprocessen. I ett slag infördes UML, RUP och en helt ny utvecklingsmiljö.trots vissa problem i inledningsskedet är alla i projektet ense om att förändringarna var till det bättre. Den första milstolpen eller leveransen gör ont när man just har bytt ut sin arbetsprocess. Det finns alltid en tendens att hålla emot förändringen och jobba som man brukar, säger Olof Karlström, linjechef vid Saab Tech i Järfälla. När helikopterprojektet drog igång var han biträdande projektledare och bland annat ansvarig för frågor som rörde utvecklingsmiljön. Nedan följer en sammanfattning av ett samtal med Dan Andersson, systemarkitekt, om förändringsarbetet i Saab Techs Helikopterprojekt. Med i diskussionen var också Camilla Hahn, tidigare RUP-mentor i projektet och ansvarig för webbadaptionen, och Göran Backlund, båda från Combitech Systems. Förändringarna bestod i att införa RUP Rational Unified Process som arbetsmetod i projektet och UML Unified Modeling Göran Backlund Dan Andersson och Olof Karlström. Language för att visualisera, modellera och dokumentera mjukvaran. Samtidigt infördes också en ny utvecklingsmiljö. I projektet har konsulter från Combitech Systems bland annat fungerat som coacher och mentorer, skött utbildning och handlett processen. Göran Backlund: Hur kom det sig att ni valde att arbeta på ett annat sätt i Helikopterprojektet? Olof Karlström: Det var främst projektledaren som hade ett antal mål med förändringen. Delvis ville vi komma igång med modellbaserad utveckling och börja använda UML i designarbetet. I det här fallet var också kraven på systemet mycket tunt specificerade, kunden hade inte gjort så mycket som den brukar. Vi såg att den iterativa modellen skulle kunna lösa många problem åt oss. Dan Andersson: UseCase-modellering fann vi vara en utmärkt metod när det inte fanns någon funktionell kravbild på systemet. Vi har till och med varit ute på helikopterbataljonen och testat modellen på våra slutanvändare. Nytt arbetssätt O: Under projekteringen var motivet att vi skulle spara pengar genom RUP. Främst genom att använda mallar, generella roller och RUP:s webbstöd. G: Blev det inte så i verkligheten? D: För att införandet av processen ska lyckas måste processen adapteras för situationen som råder i företaget. Projektet måste fungera tillsammans med företagets övriga rutiner vad gäller personalpolicy, redovisningsskyldighet och teknikpolicy. Ändringsprocessen startade utan att vi hade lyckats kommunicera ut dessa constraints för adaptionen. Det ledde till att några omtag behövde göras innan vi var på banan. O: Dessutom kostade det att få verktygen i vår utvecklingsmiljö att fungera. G: Hur drevs förändringsarbetet? D: Det är projektet som drivit igenom förändringen och vi har själva utvecklat arbetsmodellerna, delvis initialt, men också efterhand. O: Vi skapade ett delprojekt som arbetade med processutvecklingen och med utvecklingsmiljön. Delprojektledaren rapporterade till projektledningen, så ytterst var det projektledaren för hela projektet som var ansvarig för att förändringen kom till stånd. Det gjorde skillnad med en projektledare som var Göran Backlund och Camilla Hahn. intresserad och ville åt det här hållet. Camilla Hahn: Det var en av förutsättningarna. Utan det engagemanget hade det inte gått, anser jag, i och med att arbetssättet inte fanns i organisationen tidigare. G: Fick ni stöd från linjeorganisationen? 18 Nr 4 december 2003

19 O: Det finns linjeinstanser som stöttat på verktygssidan, till exempel IS/IT-avdelningen. Vår division inom Saab Tech har också varit positiv. Det står i projektdirektiven att det är ok att genomföra förändringen och att ta den extra kostnaden. Men det motiveras i att man ska tjäna tid och förhoppningsvis kunna räkna hem den extra kostnaden i projektet. När det gäller den grundläggande kursen i RUP och i UML, så stöttar linjen ekonomiskt. G: Ställde kunden eller beställaren något krav på att utvecklingsarbetet skulle bedrivas enligt RUP? O: Kontraktet med vår kund har stipulerat klassiska milstolpsresultat, som inte passar med ett iterativt sätt att arbeta. I det här fallet valde projektledningen att ta fajten med kunden om arbetsprocessen, vilket också motiverade personalen i förändringsarbetet. Motivation i projektet G: Ni har pratat om utbildning och kurser som introduktion till UML och RUP för dem som inte har några förkunskaper. Men sen då, när man gått kursen och ska omsätta det i projektverksamheten? D: När vi körde igång med den nya processen insåg folk att vi redan kunde det mesta. RUP är inte uppfunnen från början, utan upphovsmännen bygger på best practice, vilket är ett finare sätt att säga att man varit ute på fältet och knyckt en hel del. Egentligen är det styrkan i RUP, att de har tagit de bästa tillgängliga metoderna och satt samman det till något som hänger ihop både teoretiskt och praktiskt. Det gör att processen redan från början är beprövad. Ser man bortom det nya namnet så är det standardmetoder. O: Vi hade redan tidigare en fungerande egen process, så vi behövde inte motivera folk att arbeta enligt en process. C: Det var nog en förutsättning för att förändringsarbetet gick så smidigt, att det ju fanns en process tidigare. Det handlade om att byta process och aldrig om att börja arbeta enligt en process. O: Det var viktigt att också teamledarna inom projektet drev förändringen. I teamens uppdrag ingick att designa sina delområden på rätt sätt enligt UML. Då går det inte att slingra sig ur. D: En design som inte följer standarden går inte att få in i verktygen, så det fanns inga alternativ. En viktig mental omställning är också att verktygen faktiskt visar en systemmodell och inte bara en ritad bild av systemet. När man greppar att man faktiskt arbetar direkt i samma modell som övriga designers och utvecklare, så inser folk att man måste följa standarden. G: Det låter motivationsdrivande att man hela tiden ser sin del i sammanhanget. O: Man ser ganska snabbt nyttan av sitt arbete, eftersom alla andra i projektet i realtid kan se ändringarna i modellen. Man ser också att andra är beroende av ens eget arbete. Samtidigt är det inte säkert att alla människor mår bra av det här arbetssättet. Det finns de som helst vill jobba färdigt innan de publicerar sina bidrag till modellen. Det får man ha respekt för. D: Vad vi lyckats bra med är att få alla att ta processen på allvar. Det kan finnas en risk att man kapslar in förändringarna hos enstaka medarbetare och att övriga fortsätter att arbeta på det gamla sättet. Alla måste vara med och använda rätt verktyg och notation. Där tycker jag att vi har lyckats, för i nästan alla dokument så är det den som har gjort jobbet som också har tillverkat ingående diagram. C: Jag anser att man måste ha mentorer i projektet, som agerar just som mentorer och stöttar i projektet och inte gör arbetet själva. D: Mentorer som har tid, att gå genom kollegor är tungt, eftersom dom har egna leveranser att tänka på. Mentorernas arbete är inte att göra någon annans jobb utan bara sitta och peka och hjälpa till. Hur har det gått? G: Införandet av RUP är en stor förändring. Hur mottogs det nya arbetssättet i organisationen? Har det varit en lyckad förändring? Nr 4 december

20 D: Framgången hos en metod eller process kan ofta mätas i om folk vill återgå till det gamla. Det har jag en känsla av att ingen vill. Så trots att det var tungt att genomföra det här i början, så är nog alla överens om att det var en bra förändring. C: I början fanns åsikter över hela skalan. Det fanns de som var riktigt entusiastiska även om många var kritiska. D: Det var lite olyckligt att den första adaptionen som gjordes inte stämde med verkligheten, men sedan gick det ganska snabbt att vända trenden. O: Vi bytte ju dessutom mer än processen. Vi bytte också till UML och fick en helt ny utvecklingsmiljö. Jag upplevde att det lättaste att acceptera var införandet av UML. Nu har RUP också satt sig, så ur den aspekten har det varit lyckat. G: Att byta både process och utvecklingsmiljö på en gång, är det något du kan rekommendera andra? O: Nej, det är ju egentligen helt fel, men det går att göra om man har rätt inställning och är medveten om riskerna. Man måste stå fast även om det inte fungerar direkt. G: Har ert nya arbetssätt fått konsekvenser även för andra delar av företaget? D: RUP är en modell uteslutande för mjukvaruutveckling. Upphovsmännen erkänner själva att de helt enkelt struntat i hårdvaruutveckling. Det tycker jag är ett väldigt bra beslut, att inte försöka applicera metoden på något där den inte passar. O: Det som kanske varit lite kontroversiellt inom företaget är att UML anses vara grundkunskap i projektet. D: Frågan om UML ska införas eller inte tycker jag personligen är en ickefråga. Att sitta och jobba med en hemsnickrad notation, det ska man bara inte göra. RUP och UML föder varandra väldigt mycket. Det är lättare att börja med RUP om man använder UML och RUP som metod utan UML är mycket svårt att tänka sig. Lärdomar av projektet G: Det är säkert många andra som funderar på att börja använda RUP eller UML. Skulle ni avslutningsvis kunna formulera ett par goda råd till den som står inför ett sådant arbete? Har ni något som varning också? O: För det första måste hela projektledningen stå bakom införandet. Man får inte tappa fokus utan måste driva hela tiden. C: Både projektledningen och teamledarna måste kunna processen. De ska utbildas först av alla. O: En bra sak vi gjorde var att delprojektet för förändringsarbetet ingick i utvecklingsprojektet och hade stora mandat. Det har inte skett helt utan konflikter, men på ett sätt är jag en vän av konflikter. Jag tycker att det är bra om det smäller här och där, för det visar vilka områden som är viktiga och intressanta. Man ska inte se konflikter som ett misslyckande, eftersom man lär sig av dem. Ska man vara lite efterklok så borde vi kanske ha planerat för konflikterna och ställt oss frågan vad ska vi göra när vi blir osams? D: Försök också att fånga upp processen i kundkontrakten, så att kontraktet inte kräver att nya och gamla arbetsmetoder blandas. För oss är det administrativt tungt att vår kund fortfarande vill ha de gamla milstolpsleveranserna. Vi har tvingats att både avsluta iteration och uppnå milstolpar. Vi har lagt arbetet så att det i princip kommer en milstolpe per iteration, men många får ändå nästan dubbel administration att sköta. G: Sammanfattningsvis blev det alltså ett lyckat förändringsarbete. Ni valde dessutom att ta risken att förändra både process, verktyg och miljö på en gång. Vad var drivkraften bakom ett så omfattande förändringsarbete? O: Drivkraften är kanske överlevnad. Försvarsindustrin är konkurrensutsatt och vi måste överleva på exportmarknaden. När man ser att konkurrenterna är aktiva, så måste man se till att själv försöka bli bättre. Om man som vi startar större projekt sällan, så måste man våga ta risken att förändra mycket på en gång. 20 Nr 4 december 2003