Känner du till receptet för framgångsrik projektledning? sid 4. Varför Vasa sjönk:tio problem i mjukvaruprojekt. motmedel sid 6

Transkript

1 ntimeger INSIKT I TID T E M A : L E D L A G E T M O T S E G E R Nr 2/3 juni 2004 Känner du till receptet för framgångsrik projektledning? sid 4 Varför Vasa sjönk:tio problem i mjukvaruprojekt och några motmedel sid 6 Ska projektledaren vara teknisk specialist? sid 16

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ö Magnus C Ohlsson, Malmö Michael Petersson, Linköping Redaktör Eva Holmquist, Jönköping eva.holmquist@combitechsystems.com Nätvariant av OnTime Ledare...3 Förändringståliga projekt Känner du till receptet för framgångsrik projektledning?...4 Varför Vasa sjönk:tio problem i mjukvaruprojekt och några motmedel...6 Misslyckade projekt i mindre företag...14 Ska projektledaren vara teknisk specialist?...16 Allting är projekt!...18 Packningsdilemmat...23 Nära samarbete trots lång formell väg till slutkunden...25 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 utveckling av inbyggda system bättre än någon annan. Våra uppdragsgivare kallar in oss när de ska gå in på nya teknikområden, effektivisera sina arbetssätt eller behöver hjälp med att förstärka sin utvecklingsverksamhet genom outsourcing eller skickliga utvecklare. Affärsidén bygger på att tillföra våra kunder kunskap inom systemutveckling och verka som en kunskapsförmedlare mellan de branscher som vi är verksamma i, det vill säga fordons-, telekommunikations-, medicinteknik-, industri- och försvarsbranschen.vår målsättning är att vara ledande inom vår nisch. Under de tolv år vi varit verksamma har vi etablerat oss nära våra kunder för att ge dem hög service. Jönköping (lokalkontor:växjö, Ulricehamn) Box Jönköping (Besöksadress: Slottsgatan 14) Tel Fax Malmö Box Malmö (Besöksadress: Djäknegatan 31) Tel Fax Göteborg (lokalkontor:trollhättan) Mölndalsvägen 30C Göteborg Tel Fax Stockholm Box Stockholm (Besöksadress: Dalvägen 24 Solna) Tel Fax Linköping (lokalkontor: Örebro) Teknikringen 9 SE Linköping Tel Fax E-post info@combitechsystems.com Hemsida Produktion Erichs Communications AB, Linköping Grafisk design PO.Annonsbyrå AB Tryck NRS-Tryckeri 2 Nr 2/3 juni 2004

3 LEDARE Led laget mot seger För att överleva som företag i framtiden måste vi kontinuerligt utveckla nya produkter. Större delen av all produktutveckling sker idag i form av projekt och det har visat sig att projektledaren är en kritisk faktor för att ett projekt ska lyckas nå sitt mål. Våra projektledare måste ha förmågan att leda laget till seger. Lyckas de inte kommer vi inte att ha några produkter att sälja i framtiden. Så enkelt, men ändå så svårt är det. Det finns metervis av litteratur skriven om projektledning. Det finns mängder av projektmodeller. Det finns en uppsjö av kurser för projektledare. Räcker inte det? Varför väljer vi att fokusera OnTime på projektledning? Vi upplever att det är svårt att se skogen för alla träd, därför har vi försökt hitta artiklar som kan ge inspiration och nya infallsvinklar. Projektledning är också ett mycket viktigt område för att vi ska vara konkurrenskraftiga som företag. Vi vill därför belysa den roll man som projektledare har för att projektet ska lyckas. En bra projektledare kan inte göra jobbet själv, men en dålig projektledare kan spoliera alla andras arbete. Det är fler än de som arbetar i ett projekt som berörs av projektet. Ett projekt har ofta många intressenter. Det kan vara användare av den produkt som utvecklas, kunden som köper produkten, underleverantörer till projektet och linjen. Det gäller att få samarbetet och kommunikationen att flyta smidigt. Alla har olika krav på projektet och det gäller för projektledaren att jämka samman alla dessa intressen. Att leda projekt är en svår konst. Det är inget man kan läsa sig till. Däremot kan man få tips och kanske någon insikt. Det är inte heller bara den som aktivt arbetar som projektledare som behöver lära sig vad projektledning innebär. Alla som arbetar i projekt behöver en förståelse för projektledning och det gäller även de som är intressenter i någon form till ett projekt. Vi hoppas att det här numret av OnTime kommer att ge nya insikter till alla er. Eva Holmquist Redaktör OnTime Nr 2/3 juni

4 AV MATS NÄSLUND Förändringståliga projekt Känner du till receptet för framgångsrik projektledning? Den skånska matlagningsikonen Tina har en odiskutabelt enkel metod att undersöka vad som står och kokar på spisen. Det gäller att smaka, smaka och åter smaka Jag anser mig vara ganska händig i köket. De flesta som blivit utsatta för min kokkonst har trots allt uttryckt sin uppskattning. Detta beror säkert på att jag lutar mig mot kokboken när jag ska göra något nytt. Kokboken beskriver som bekant både ingredienser och arbetsordning och håller den värsta innovationslustan i köket i schack. Tryggt att veta att jag inte kommer att göra bort mig helt. Exakt hur jag ska göra lämnas ofta till mitt omdöme och mina tidigare erfarenheter, på samma sätt som mycket av dagens projektledningslitteratur också förordar. Om tid och medel finns försöker jag som oftast också laga till anrättningen på prov för att se hur det blir och försöker hitta vägarna framåt till kulinarisk perfektionism. Detta är en lyx man i de flesta fall inte har råd med när det gäller att genomföra projekt. Den gyllene regeln är dock att repetition ger precision! Om Tina hade varit projektledare hade hon naturligtvis velat smaka på projektet. Med en enkel kokbok, en gnutta erfarenhet och sunt förnuft går det att identifiera smaker och ingredienser samt undvika att projektet bränner fast i botten på grytan. Behöver man då inte formella metoder för att leda projekt? Graden av formalism beror på projektets storlek och form. Precis som med kokboken måste den allmänt accepterade projektledningsteorin finnas i bakgrunden att stödja sig mot om något börjar gå snett. Det gäller alltså att ha omdöme att veta hur man ska leda ett projekt beroende på vilken stil projektet och medarbetarna kräver. Att leda nya projekt med okända metoder är ett riskfyllt arbete. Minska risken genom att använda en beprövad metod. Projekt går ofta överstyr på grund av kombinationen av svag planering och undermålig analys av produkt- och projektpåverkan vid förändringar. Det går inte att undvika förändringar och oväntade händelser i ett projekt. Förändringar är ett naturligt inslag i projektet och därför är det viktigt att utforma det så att det enkelt kan hantera dessa. Artiklarna i detta nummer ger en rad praktiska råd och insikter kring projektledning och mjukvaruutveckling. Jag tänkte komplettera artiklarna genom att lyfta fram begreppen projektmedvetenhet och projekttrygghet. Deras betydelse är stor när det gäller att skapa projekt som blir förändringståliga. Projektmedvetenhet krävs för framgång Ett framgångsrikt projektarbete kräver medvetenhet om vilka regler, värderingar och attityder som gäller. Det är projektledaren som ska synliggöra dessa. Synligheten bidrar till att skapa en projektmedvetenhet, men även förmågan att förstå helheten och den situation projektet befinner sig i, sett både ur ett ekonomiskt och tekniskt perspektiv. Individen ser inte längre arbetet som ett självändamål utan förstår dess betydelse för projektet som helhet. Projektledaren måste skapa ett driv i projektet genom väl genomtänkt kommunikation för att göra projektarbetarna medvetna om tidens betydelse. Beroende på vilken situation var och en befinner sig i väljer man också hur man vill utnyttja tiden och vilket värde man ger den. Den tillgängliga tiden påverkar ens känslor och värderingar på ett högst påtagligt och ömsesidigt sätt. Tiden står aldrig still och väntar på att vi ska bli färdiga och därför måste alla i projektet möta den med respekt. Saknas den nerven i projektet kommer heller aldrig drivet. En annan aspekt av drivet är att det också måste ges utrymme för eftertanke. Insikterna kommer i pauserna och rytmen från dessa. Det är där tillfälle ges att skapa distans och reflektera över hur arbetet går. Planer betyder ingenting. Planering betyder allt. Eisenhowers ord är tänkvärda. I det ögonblick man börjar arbeta efter planen kommer saker och ting oplanerat att börja ändra på sig. För att kunna revidera sina planer är det viktigt att snabbt kunna skapa en bild av var projektet befinner sig och vart det är på väg. Med detta är det inte sagt att man inte ska lägga stor energi på att ta fram de ursprungliga planerna och försöka förutse och hantera de största riskerna i projektet. Grunden för ett projekts förmåga att identifiera och hantera förändringar läggs i designen av själva projektet. Det krävs en helhetssyn kring vad projektet ska åstadkomma och hur detta görs på bästa sätt. Ha för vana att utföra en riskanalys av projektets utformning när det befinner sig i sin linda. Ett rätt designat projekt har bättre möjligheter att helt arbeta bort problem eller hantera det oplanerade, vilket i ärlighetens namn alltid kommer att inträffa. Vi måste lära känna varandra på det personliga planet för att bygga naturliga kommunikationsvägar. Detta skapar en känsla av samhörighet och förståelse för de värderingar som gäller i projektet och har stor betydelse för hur framgångsrikt projektet kommer att bli. Den här typen av aktiviteter, vi kan kalla dem sociala riskanalyser, ska helst genomföras flera gånger under projektet. Om förmågan till spontan kommunikation saknas kommer också gruppens förmåga att bibehålla helhetssynen på projektet att sakta men säkert försvinna. God kommunikation utgör en framgångsfaktor. Finns förutsättningarna för en god kommunikation i projektet finns även förutsättningen att skapa projektmedvetenhet genom hela organisationen. Projekttrygghet ger kreativitet Jag tror att mycket av kreativiteten i ett projekt kommer ur ett ord, projekttrygghet, vilket beskriver ett tillstånd av ömsesidigt förtroende, god självbild och ansvarstagande. Ett ömsesidigt förtroende mellan ledning och övriga projektmedlemmar skapar en trygg arbetsmiljö. Vikten av att leda på rätt sätt togs det fasta på redan under romarnas fälttåg, där triumftåg kunde utebli då man 4 Nr 2/3 juni 2004

5 LED LAGET MOT SEGER ansåg att härföraren hade tagit ett antal tvivelaktiga beslut men med lite tur ändå lyckats med det man föresatt sig. För att kunna leda andra på bästa sätt måste du veta vem du själv är. En projektledare som agerar helt utan självinsikt förlorar övriga projektmedlemmars förtroende. Citatet av en kollega understryker att en bristande självbild kan skapa stora problem i gemenskapen. Med en god självbild kommer prestigelösheten och modet, som leder till effektivt samarbete. Projektledaren är normbildande i projektet och visar både vad som är accepterat och när detta gäller. Omdömet får styra vad som är relevant i olika situationer. Det är viktigt att förstå vilka normer och värderingar man själv och andra har eftersom det kan uppstå en problematisk konflikt om de går isär. Det är inte alltid uppenbart hur situationen ska hanteras. Vikten av att projektdeltagarna axlar sina tilldelade roller, förstår dem och agerar med ett överenskommet ansvar, kan inte nog påpekas. Den franske filosofen Montaigne drar problemet kring ansvar och roller till sin spets i anekdoten om Anthistenes. En dag försökte Anthistenes övertala athenarna att befalla att deras åsnor skulle användas till att plöja åkrarna lika mycket som hästarna. Han fick då svaret att åsnan inte var till för sådant arbete. Det gör alldeles detsamma, svarade han, ni behöver bara befalla dem. För även de okunnigaste och odugligaste män som ni utnämner till befäl i krig blir ju synnerligen värdiga den uppgiften därför att ni utser dem. Projektledaren är ytterst ansvarig för att ro projektet i hamn och samtidigt se till projektmedarbetarnas bästa. Detta ansvar är ingenting man kan ta lätt på och gäller både i medoch motgång. Det krävs lite funderande över vad som förväntas innan man accepterar rollen som projektledare. Projekttryggheten för med sig att projektdeltagarna vågar närma sig gränserna i projektet och även agera på ett gränsöverskridande sätt, vilket i sig är ett kvitto på ett välmående projekt. Engagemang av detta slag är den högsta formen av ansvarstagande och borgar för bibehållen kreativitet. I ett sådant projekt existerar inte attityden det är inte mitt bord. Tryggheten i projektet gör det också lättare att erkänna problem och göra dem synliga. I en otrygg miljö finns risken att det uppenbara förblir osagt eller ignorerat. Att lära av sina misstag är viktigt och det är först när man inte försöker sig på detta man kan börja tala om ett misslyckande. I fallet med regalskeppet Vasas förlisning, som en av artiklarna behandlar, pekades det inte ut någon skyldig, men man lärde sig av fadäsen. Vasa var helt enkelt ett tekniskt experiment och det dröjde inte länge innan det byggdes framgångsrika skepp med både två och tre batteridäck. Jag hoppas att detta nummer kommer att ge dig som läsare en hel del tänkvärda och matnyttiga tips kring projektledning och projektarbete i allmänhet. Låt dig väl smaka! Mats Näslund har sju års erfarenhet från konsultbranschen genom sin tid på Combitech Systems och har under de senare åren specialiserat sig på projektledning. Mats är civilingenjör från Elektrotekniklinjen på Lund Tekniska Högskola och har nyligen genomgått utbildningsprogrammet Erfarenhetsutveckling för projektledare som Combitech Systems driver i samarbete med avdelningen för Yrkeskunnande och Teknologi vid Kungliga Tekniska Högskolan. Nr 2/3 juni

6 AV RICHARD E. FAIRLEY, OREGON HEALTH AND SCIENCE UNIVERSITY OCH Varför Vasa sjönk: Tio problem i mjukvaruprojekt och några motmedel Copyright 2003 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad på engelska i IEEE Software 2003, med namnet Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects. Regalskeppet Vasa sjösattes 1628 av den svenska flottan. Efter bara omkring meters seglats sjönk hon. Författarna granskar projektets problem, varför skeppet var instabilt och varför det ändå sjösattes. De tolkar fallet i termer hämtade från dagens stora, komplexa mjukvaruprojekt och presenterar några motmedel. Den 10 augusti 1628 satte den svenska flottans nyaste flaggskepp segel för sin jungfrufärd. Vasa seglade omkring meter innan en lätt kastby fick skeppet att kantra och gå under i Stockholms hamn varvid 52 människor förlorade livet. Skeppet var det dåtida Sveriges dyraste projekt någonsin och en total förlust. Det var en nationell katastrof Sverige låg i krig med Polen och skeppet behövdes till krigsinsatserna. Sjöförklaringen följande månad kunde inte fastställa orsaken till varför skeppet sjönk, vilket fick till följd att ingen förklarades skyldig. Efter inledande räddningsförsök föll skeppet mer eller mindre i glömska tills Anders Franzén hittade det år År 1961, 333 år efter förlisningen, lyftes Vasa ur djupet. Det var så välbevarat att det flöt på egen köl sedan kanonportarna förseglats och vatten och lera pumpats ut. Den skyddade hamnen hade bevarat skeppet från stormar och Östersjöns låga salthalt hade hindrat skeppsmask från att angripa och förstöra det helt i trä byggda skeppet. I dag ligger skeppet i Vasamuseet ( nära den plats där det förliste. Forskare har noga undersökt Vasa och studerat historiska dokument kring skeppets konstruktion. Det sjönk självfallet för att det var instabilt. Skälen är många och skiftande till varför det var instabilt och trots att detta var känt ändå sjösattes. Även om vi aldrig får reda på de närmare detaljerna kring Vasa skildrar denna artikel vårt mest sannolika scenario baserat på dåtidens omfattande och synnerligen välbevarade dokument, belägg insamlade i samband med besök på Vasamuseet, information från den angivna webbplatsen samt artiklar och böcker skrivna av personer som har undersökt omständigheterna kring Vasas förlisning. De inträffade problemen är lika relevanta för moderna människor i dag i deras strävan att bygga stora, komplexa mjukvarusystem som de var för 1600-talets byggare av örlogsskepp. Vasas historia Vasas historia är i korta drag följande: Ändrade order till skeppsbyggaren Den 16 januari 1625 gav kung Gustav II Adolf i uppdrag åt amiral Fleming att anlita de stockholmska skeppsbyggarna Henrik och Arend Hybertsson för att rita och övervaka byggandet av fyra örlogsskepp. Henrik var skeppsbyggmästaren och Arend den affärsansvarige. De anlitade skeppsbyggaren Johan Isbrandsson som under deras överinseende åtog sig att bygga skeppen på fyra år. De två mindre skeppen skulle få en köl på närmare 33 m och de två större på omkring 41 m. Med utgångspunkt från en rad motsägande ändringskrav från kungen våren och sommaren 1625 rekvirerade Henrik ektimmer från Kronans mark till två 33 m långa skepp och ett 41 m långt skepp. Den 20 september samma år förlorade den svenska flottan 10 skepp i en förödande storm. Kungen beordrade då att de två mindre skeppen skulle byggas först i forcerat tempo för att ersätta två av de förlista skeppen. Vasa började byggas i början av 1626 som ett litet traditionellt skepp, men färdigställdes två och ett halvt år senare som ett stort innovativt skepp efter att ha genomgått otaliga förändringar av kravspecifikationen. Den 30 november 1625 ändrade kungen sin beställning och beordrade nu att de två mindre skeppen skulle byggas 36 m långa så att de kunde ges en tyngre bestyckning med 32 stycken 24-pundiga kanoner placerade på ett traditionellt slutet kanondäck. ( 24-pundiga avser vikten på kulan som skjuts ur kanonen. En 24-pundig kanon väger omkring ett och halvt ton.) Henrik inventerade sitt materialförråd och fann att han hade tillräckligt med timmer för att kunna bygga ett 34 m långt och ett 41 m långt skepp. På kungens befallning, framförd av amiral Fleming, la Henrik kölen för ett 34 m långt skepp eftersom detta skulle kunna färdigställas snabbare än det större skeppet. Dokumenten är oklara huruvida kölen först las för denna storlek eller för ett 33 m långt skepp som sedan förlängdes till 34 m. Inga specifikationer för den modifierade kölen När Vasas 34 m långa köl hade lagts nåddes kungen av nyheten att Danmark höll på att bygga ett större skepp med två kanondäck. Kungen beordrade då att Vasa skulle förlängas till 41 m och förses med två slutna kanondäck. Ingen i Sverige, inte heller Henrik Hybertsson, hade någonsin byggt ett skepp med två slutna kanondäck. Den pressade tidplanen gjorde att skeppsbyggarna valde att skala upp den 34 m långa kölen med material avsett för det större skeppet som ett snabbare alternativ än att lägga en ny 41 m lång köl. Örlogsskeppens förändrade konstruktion från ett till två slutna kanondäck i början av 1600-talet markerade en ny sjökrigföringstaktik som blev norm mot slutet av 1600-talet och under 1700-talet. Målet var att avfyra bredsidor och sänka motståndaren. Dessförinnan avfyrade örlogsskeppen inledande kanonsalvor för att skada motståndarens skepp så att de kunde borda och erövra det. Av det skälet hade äldre örlogsskepp ett stort antal soldater ombord (upp till 300). Trots att kontraktet med Hybertssons ändrades (och finns bevarat), har ingen någonsin funnit specifikationer eller ens grova skisser till vare sig det 33 m eller det 41 m långa Vasa, och inga av de tillhörande (och välbevarade) dokumenten nämner några sådana ritningar. Det är osannolikt att någon ägnade tid åt att utarbeta specifikationer med tanke på omständigheterna och det pressade tidsschemat under vilka Vasa byggdes. De skulle förmodligen inte ens ha tagits fram till det ursprungliga 33 m långa skeppet, efter- 6 Nr 2/3 juni 2004

7 MARY JANE WILLSHIRE, UNIVERSITY OF PORTLAND Nr 2/3 juni

8 LED LAGET MOT SEGER som den skeppstypen hade byggts i många år och Hybertsson var en erfaren skeppsbyggmästare som arbetade med erfaren skeppsbyggare. Henrik Hybertsson skalade förmodligen upp dimensionerna från det ursprungliga 33 m långa skeppet så att de passade kraven på längd och bredd för ett 34 m långt skepp, och skalade sedan upp dessa igen till den 41 m långa versionen av Vasa. Metoden med vilken han skalade upp den 34 m långa Vasa till 41 m begränsades av den befintliga kölen som innehöll traditionella tre skarvarna. Han la till en fjärde skarv för att förlänga kölen, men kölen blev då tunn i förhållande till längden och för ett skepp av denna storlek blev djupgåendet ganska grunt. Hybertssons medhjälpare, Hein Jacobsson, vittnade senare om att för att ge plats åt två kanondäck byggdes Vasa 43 cm bredare än vad som ursprungligen hade planerats. Kölen var dock redan lagd så de kunde bara göra denna breddförändring i skeppets övre delar. Det höjde tyngdpunkten och bidrog till Vasas instabilitet (segelskepp är extremt känsliga för tyngdpunktens läge, några få centimeter kan göra enorm skillnad). De som utrustade skeppet för dess jungfrufärd fann också att den grunda kölen inte lämnade tillräckligt utrymme åt den mängd barlast som krävs för att stabilisera ett 41 m långt skepp. Den tunna kölen krävde extra förstyvningstimmer i lastrummet, vilket ytterligare begränsade det tillgängliga barlastutrymmet. Ändrade bestyckningskrav Antalet och typerna av kanoner som den uppskalade Vasa skulle få genomgick ett antal ändringar. Ursprungligen skulle det 34 m långa skeppet bestyckas med 32 stycken 24-8 Nr 2/3 juni 2004

9 LED LAGET MOT SEGER Tabell 1 Tio problem i mjukvaruprojekt och några motmedel Problemområde Motmedel 1. Orimlig tidspress Objektiva uppskattningar Mer resurser Bättre resurser Prioriterade krav Bantade krav Etappvisa releaser 2. Ändrade behov Iterativ utveckling Förändringshantering/baslinjehantering 3. Avsaknad av tekniska specifikationer Utarbetande av en första uppsättning specifikationer Händelsestyrd uppdatering av specifikationer Baslinjehantering av specifikationer Utse en mjukvaruarkitekt 4. Avsaknad av en dokumenterad projektplan Utarbetande av en första plan Periodisk och händelsestyrd uppdatering Baslinjehantering av projektplanen Utse en projektchef 5. & 6. Omfattande och sekundära innovationer Baslinjehantering Konsekvensanalys Fortlöpande riskhantering Utse en mjukvaruarkitekt 7. Smygande kravutveckling Första kravbaslinje Baslinjehantering Riskhantering Utse en mjukvaruarkitekt 8. Avsaknad av vetenskapliga metoder Prototypning Inkrementell utveckling Teknisk resultatmätning 9. Strunta i det uppenbara Enkla överslagsberäkningar Införlivande av dragna lärdomar 10. Oetiskt beteende Etiska arbetsmiljöer och arbetskulturer Personligt ansvar för att följa etiska regler pundiga kanoner. Den 41 m långa versionen däck. Slutligen beordrade kungen att Vasa skulle bestyckas med 36 stycken 24-pundiga skulle bestyckas med 64 stycken 24-pundiga kanoner, 24 stycken 12-pundiga kanoner, 8 kanoner 32 på varje däck plus flera mindre stycken 48-pundiga mörsare samt 10 mindre kanoner (några dokument anger det beordrade antalet till 60 stycken 24-pundiga kanoner). kanoner. Efter en rad ytterligare ändringar skulle Vasa bestyckas med 30 stycken 24-pundiga kanoner på nedre kanondäck och 30 ner hade fördelen att det gav större eldkraft Bestyckning med enbart 24-pundiga kano- stycken 12-pundiga kanoner på övre kanon- och medgav standardisering kring samma typ av ammunition, lavetter, krutladdningar och fasta utrustningsdetaljer. Det övre däcket måste dock bära den extra vikten av de 24- pundiga kanonerna i ett trångt utrymme som var byggt för 12-pundiga kanoner, vilket ytterligare höjde skeppets tyngdpunkt. Till sist sjösattes Vasa med 48 stycken 24-pundiga kanoner (hälften på varje däck), eftersom kanonleverantörens produktionsproblem omöjliggjorde leverans av flera kanoner i tid. Att invänta de ytterligare kanonerna skulle ha kolliderat med kravet att sjösätta skeppet så snabbt som möjligt. Ett annat belägg för det kraftigt pressade tidsschemat är att kanonernas gjutgods höll låg kvalitet. De skulle mycket väl ha kunnat haverera (exploderat) under ett sjökrigsslag. Kunniga skeppsbyggare konstruerade Vasas rigg och utrustning utan uttryckliga specifikationer eller ritningar på det traditionella sätt som hade utvecklats under lång tid. Kungen beordrade att skeppet skulle utrustas med hundratals utsirade, förgyllda och målade träskulpturer som avbildade bibliska, mytologiska och historiska teman. Avsikten var att Vasa skulle imponera genom att överglänsa det danska skeppet under byggnad. Inga kostnader besparades, vilket gjorde Vasa till sin tids dyraste skepp. De tunga ekskulpturerna höjde tyngdpunkten och ökade därmed instabiliteten ytterligare. Skeppsbyggmästarens död Henrik Hybertsson blev svårt sjuk 1626 och dog 1627, ett år innan Vasa var färdigbyggt. Under sjukdomsåret delade han ledningen av projektet med Jacobsson (Hybertssons medhjälpare) och Isbrandsson, men enligt de historiska dokumenten var projektledningen svag. Ansvarsfördelningen var inte tydlig och kommunikationen dålig. Eftersom det inte fanns några detaljerade specifikationer, milstolpar i tidsschemat eller arbetsplaner var det svårt för Jacobsson att förstå och genomföra Hybertssons odokumenterade tankar. Kommunikationen mellan Hybertsson, Jacobsson och Isbrandsson var dålig. Det Nr 2/3 juni

10 LED LAGET MOT SEGER resulterade i ytterligare förseningar för skeppets färdigställande. Amiral Fleming utsåg Jacobsson som ansvarig för att färdigställa projektet efter Hybertssons död. Vid denna tidpunkt och under det följande året arbetade 400 personer i fem olika grupper på skrovet, träskulpturerna, riggen, bestyckningen och barlasten uppenbarligen med liten, om ens någon, kommunikation eller samordning mellan sig. Detta var då den största arbetsstyrka som någonsin hade anlitats för ett enstaka projekt i Sverige. Det finns inga belägg för att Jacobsson utarbetade några dokumenterade planer efter att ha fått ansvaret för skeppets färdigställande. Inga metoder för att beräkna stabilitet, styvhet eller seglingsegenskaper Metoder för beräkning av tyngdpunkt, krängningsegenskaper och stabilitetsfaktorer för segelskepp var okända. Kaptenerna fick därför lära sig skeppens egenskaper genom att pröva sig fram. Vasa var det mest spektakulära men långt ifrån det enda skeppet som kapsejsade på och 1700-talen. Mätningar och beräkningar som gjorts efter 1961 visar att Vasa var så instabilt att skeppet skulle ha kantrat vid en krängning på mer än 10 grader. Det kunde helt enkelt inte klara den uppskattade vindstöten på 4 sekundmeter som fick skeppet att kantra. Nyare beräkningar visar att skeppet skulle ha kantrat i en lätt bris på 2 sekundmeter. Att vinden var så svag under Vasas första (och sista) seglats verifieras av det faktum att besättningen fick sträcka skoten för hand vid sjösättningen. Löjtnant Petter Gierdsson vittnade vid sjöförklaringen i september 1628: Vinden var inte tillräckligt stark att sträcka skoten trots att blocken voro väl smorda. De fingo därför sträcka dem för hand och en man var tillräcklig att hålla ett skot. Under sjöförklaringen nämnde flera vittnen att Vasa var tyngre upptill än nedtill, men ingen utvecklade frågorna om hur och varför Vasa hade blivit för tung upptill. Ingen tog upp vikten av det andra kanondäcket, kanonerna, träskulpturerna eller den övriga utrustningen. På den tiden trodde de flesta människor (inklusive experterna) att ju högre och mer imponerande ett örlogsskepp var och ju fler och större kanoner det hade, desto mer oförstörbart skulle det vara. Det misslyckade stabilitetsprovet Kapten Hannson (skeppets kapten) och en liten grundbesättning genomförde ett stabilitetsprov i närvaro av amiral Fleming i samband med att Vasa utrustades. Krängningsprovet bestod av att 30 man fick springa fram och tillbaka midskepps mellan relingarna. Efter tre turer fram och tillbaka avbröts provet eftersom skeppet gungade så kraftigt att det var uppenbart att det skulle kantra om provet fortsatte. Skeppet kunde inte stabiliseras eftersom det inte fanns plats för extra barlast under lastrummets golvbrädor. Den extra vikten skulle hur som helst ha sänkt ned nedre kanondäcks kanonportar nära eller under skeppets vattenlinje. Vasa uppskattas ha haft omkring 120 ton barlast. Det skulle ha behövts mer än dubbelt så mycket för att stabilisera skeppet. Vasa sjösattes med kända stabilitetsproblem till följd av dålig kommunikation, påtryckningar från Gustav II Adolf att sjösätta skeppet så snabbt som möjligt, det faktum att kungen befann sig mitt uppe i ett fälttåg i Polen (och därför inte var tillgänglig för konsultation) samt det faktum att ingen hade några förslag på hur skeppet skulle kunna göras stabilare. De vittnesmål som avgavs vid sjöförklaringen tyder på att Jacobsson, skeppsbyggmästaren, och Isbrandsson, skeppsbyggaren, inte närvarade vid stabilitetsprovet och var omedvetna om utfallet. Däcksunderofficeren Matsson vittnade om att amiral Fleming hade anklagat honom för att ha för mycket barlast, eftersom kanonportarna låg för nära vattnet! Mattson sägs då ha svarat: Gud give att skeppet kan stå upprätt på sin köl. På vilket amiralen svarade: Skeppsbyggaren har byggt skepp förut och du ska inte bry dig. Huruvida amiral Fleming och kapten Hannson avsiktligt lät bli att nämna resultatet från stabilitetsprovet är föremål för spekulation. Kungen hade beordrat att Vasa skulle vara klart 25 juli och om inte, skulle de ansvariga bliva föremål för Hans Majestäts ogunst. Vasas jungfrufärd skedde mer än två veckor senare den 10 augusti. Det rapporteras att amiral Fleming efter det misslyckade stabilitetsprovet beklagade sig: Om bara konungen var här. Tio problemområden och deras motmedel Flera av Vasaprojektets problem är bekanta för dem som har brottats med stora mjukvaruprojekt. Tabell 1 visar tio av Vasaprojektets problem som även är vanligt förekommande i mjukvaruprojekt tillsammans med några av deras motmedel. 1. Orimlig tidspress Många mjukvaruprojekt befinner sig, liksom Vasaprojektet, under orimlig tidspress för att uppfylla verkliga eller tänkta behov. Enligt Fred Brooks har fler mjukvaruprojekt gått över styr på grund av tidsbrist än för alla andra skäl sammantagna. Orimlig tidspress i ett mjukvaruprojekt orsakas av: Verkligt trängande behov. Uppfattade behov som egentligen inte är trängande. Ändrade krav utan motsvarande förändring av tidplanen eller resurserna (se problem 2). Orealistiska tidplaner som påtvingas projektet utifrån. Avsaknad av realistiska uppskattningar baserade på objektiva data. När tidplansuppskattningarna inte baseras på objektiva data har programmerarna ingen grund att stå på för att försvara sina uppskattningar eller för att motstå påtvingade tidplaner. Ibland kan man klara tidsgränserna genom att öka projektets resurser, använda 10 Nr 2/3 juni 2004

11 LED LAGET MOT SEGER bättre resurser, banta de (prioriterade) kraven, släppa etappvisa releaser eller en kombination av dessa motmedel. 2. Ändrade behov Några vanliga skäl till ändringar i mjukvarukraven inkluderar konkurrens (som i fallet med Vasa), användarbehov som utvecklas med tiden, ändringar i plattforms- och målteknik samt nya insikter vunna under projektets gång. Det finns två metoder för hantering av ändrade mjukvarukrav: Drivande av en iterativ utvecklingsstrategi (exempelvis inkrementell, evolutionär, snabb eller spiralformad). Tillämpning av baslinjehantering. Dessa metoder kan användas var för sig eller tillsammans. I fallet med iterativ utveckling kan kravändringar tillgodoses utgående från prioriteringar mellan de begränsande faktorerna tid, resurser och teknik vilka alla kan anpassas i takt med att projektet utvecklas. I fallet med baslinjehantering placeras kraven initialt under versionskontroll. Godkända ändringar resulterar i en ny version av kraven (en ny baslinje), som åtföljs av justeringar i tidplan, resurser, teknik och andra tillämpliga faktorer. Målet för båda metoderna är att alltid upprätthålla en balans mellan krav, tidplan, resurser, teknik och andra faktorer som kan utgöra risker för framgångsrik leverans av en godtagbar produkt inom projektets förutsättningar. 3. Avsaknad av tekniska specifikationer Mjukvaruprojekt börjar ibland, liksom Vasaprojektet, som små välbekanta aktiviteter för vilka tekniska specifikationer verkar onödiga. Många gånger växer de till stora, innovativa projekt. I fallet med Vasa kunde muntlig kommunikation kanske ha kompenserat något för avsaknaden av skriftliga specifikationer och en skriftlig projektplan. I fallet med mjukvaruprojekt är det, till och med för ett litet enkelt projekt, mycket lättare (och mindre riskabelt) att först utarbeta krav och placera dem på en baslinje, än att försöka återskapa kraven i efterhand när projektet har passerat en komplexitetströskel som motiverar utarbetande av tekniska specifikationer. 4. Avsaknad av en dokumenterad projektplan På grund av att konstruktörerna såg Vasa som ett litet, välbekant skepp och på grund av att projektteamet hade lång erfarenhet av att bygga skepp av den typen kan de förletts att tro att systematisk planering var onödig användning av tid och resurser. Mjukvaruprojekt börjar ofta under likartade förhållanden. Liksom i fallet med kraven är det mycket lättare att utarbeta en baslinjebaserad projektplan för ett till en början litet projekt än att försöka ta fram en plan i efterhand (när det inte finns tid för detta). En plan till ett mjukvaruprojekt måste inkludera: Nedbrytning av arbetet som ska göras (dvs en struktur för arbetsnedbrytning) Kravallokering till nedbrytningsstrukturens arbetsrelaterade delar En allokerad tidplan (exempelvis ett milstolpsdiagram) Allokering av resurser till varje tidplansintervall Levererbara arbetsprodukter för varje tidplansintervall Planer för anskaffning av mjukvara från leverantörer och öppna källor Planer för hantering av underleverantörer En riskhanteringsplan Klart definierade behörigheter och ansvarsområden Projektplanen för ett litet mjukvaruprojekt kan ofta dokumenteras på några få sidor och sedan utökas i takt med att projektet växer. 5. Omfattande innovationer I sin bok To Engineer Is Human noterar Henry Petroski att tekniska projekt ofta miss- Nr 2/3 juni

12 LED LAGET MOT SEGER lyckas när människor försöker sig på innovationer som går längre än den aktuella teknikfronten. Till viss del är mjukvaruprojekt alltid innovativa eftersom reproducering av befintlig mjukvara, till skillnad från reproducering av fysiska föremål, är en närmast trivial process. Mjukvaruprojekt genomförs i syfte att utveckla nya system från början och ta fram nya versioner av befintliga system, inte att reproducera mjukvara. Följande metoder kan tillämpas för att hålla omfattande innovation i mjukvaruprojekt under kontroll: Baslinjehantering av arbetsdokumenten (exempelvis krav, projektplaner, designdokument, testplaner och källkod) Analys av de föreslagna ändringarnas effekter Fortlöpande riskhantering 6. Sekundära innovationer Skälen till sekundära innovationer i mjukvaruprojekt inkluderar nödvändigheten av att ta hänsyn till begränsningar i den teknik som används, införandet av härledda krav till stöd för primära krav och förändringar av dessa samt innovationer baserade på utvecklarnas kreativa impulser. Liksom i Vasas fall kan dessa sekundära krav övertaxera ett mjukvaruprojekts resurser. Utöver de metoder som nämns för att få problem 5 under kontroll bör en mjukvaruarkitekt utses och ges ansvar och befogenhet att upprätthålla mjukvaruproduktens vision och integritet, vilket är ytterligare ett motmedel mot en rad andra problem. 7. Smygande kravutveckling Det verkar som om ingen var medveten och den totala effekten av de ändringar som gjordes på Vasa under det två och ett halvt år långa konstruktionsarbetet. Detta kan lätt hända i mjukvaruprojekt (och gör också det). Grundläggande metoder för att behålla kontrollen över mjukvaruprojekt är att ta fram en inledande dokumentation och konsekvent uppdatera krav och planer för att upprätthålla en godtagbar balans mellan krav, tidplan och resurser i takt med att projektet utvecklas. Ofta hörda ursäkter för ett misslyckande, med att ta fram den inledande projektdokumentationen, är otillräckliga kunskaper om hur detta görs och tron på att allt kommer att ändras ändå, så varför planera? Inledande krav och planer bör tas fram i den utsträckning det går (trots bristande kunskaper och trots att de kan förväntas ändras) 12 Nr 2/3 juni 2004

13 LED LAGET MOT SEGER samt med procedurer på plats för att utveckla dem systematiskt. Ett misslyckande med att, regelbundet och när omständigheterna kräver det, uppdatera de första kraven och planerna är ofta en konsekvens av uppfattningen att det inte finns tillräckligt med tid att göra detta ( aldrig tillräckligt med tid att göra det riktigt, men alltid tid att göra om det ). Denna uppfattning kommer i sin tur från otillräckliga procedurer för att fortlöpande hantera kraven och planerna samt en bristande respekt för de risker som detta skapar. 8. Avsaknad av vetenskapliga metoder Eftersom mjukvara saknar fysiska egenskaper finns det ett antal traditionella tekniska parametrar som inte går att beräkna för den (åtminstone inte i dag). Till skillnad från fysiska föremål som t ex Vasa går det dock att bygga mjukvarusystem i små, inkrementella steg och övervaka utvecklingen av tekniska parametrar som minnesanvändning, prestanda, säkerhet och tillförlitlighet i takt med att systemet utvecklas. 9. Strunta i det uppenbara I fallet med Vasa visade krängningsprovet att skeppet var farligt instabilt. Det fanns inte utrymme för ytterligare barlast. Hade det funnits utrymme skulle den extra vikten ha sänkt ned de nedre kanonportarna under vattenlinjen. Trots att vi saknar vetenskapliga metoder på många mjukvaruutvecklingsområden kan vi ofta undvika förutsebara katastrofer genom några få, och ofta ganska enkla, överslagsberäkningar. Om exempelvis ett transaktionssystem ska bearbeta transaktioner per sekund och varje transaktion kräver fyra komplexa förfrågningar, måste systemet bearbeta komplexa förfrågningar per sekund, inklusive den tid som åtgår för kontextväxling bland transaktionerna (dvs 250 mikrosekunder per kontextväxling och transaktion). När systemets väntetider tas med i beräkningarna kan det visa sig att det planerade systemet inte går att bygga. 10. Oetiskt beteende Ingenjörskonstens roll i det moderna samhället är att tillhandahålla system och produkter som förbättrar de materiella aspekterna av livet och därigenom gör livet enklare, säkrare, tryggare och mer njutbart. Tekniska innovationer involverar ofta etiska överväganden. I fallet med Vasa var målsättningen att göra Sverige säkrare för dess invånare och skänka ära åt landet. I sista stund när det blev uppenbart att skeppet inte var sjövärdigt valde de som hade befogenhet att stoppa sjösättningen att inte göra det. I vår tid bör programmerarna för det första betjäna allmänheten, för det andra vara förespråkare för kunderna och användarna av deras produkter samt för det tredje agera i sina arbetsgivares intresse på ett sätt som är förenligt med det allmännas bästa. Programmerarna bör ta det fulla ansvaret för sitt arbete och bara godkänna mjukvara om de har välgrundad anledning att tro att den är säker, motsvarar specifikationerna, klarar tillämpliga tester och inte försämrar livskvaliteten, hotar privatlivets helgd eller skadar miljön. Slutresultatet av arbetet bör främja det allmännas bästa. Varje programmerare bör känna till och följa en uppsättning etiska regler. Tabell 1 visar bara några av de många möjliga motmedlen för mjukvaruprojekt. En del motmedel som anges för ett problemområde gäller i lika hög grad även för andra problemområden. För utrymmets skull lämnar vi åt läsarna att utveckla tabell 1. Enligt protokollet från Vasas sjöförklaring frågade ingen hur eller varför skeppet hade blivit instabilt eller varför det sjösattes med kända stabilitetsproblem. Underlåtenheten att driva denna fråga i utredningen är kanske det mest slående problemet från fallstudien kring Vasa, i likhet med vår i dag så ofta observerade oförmåga att lära oss av våra misstag inom mjukvaruutveckling. I positivt hänseende kan sägas att stora örlogsskepp med dubbla kanondäck senare byggdes och seglades under andra halvan av 1600-talet samt under och 1800-talen. På samma sätt som utvecklingen gick framåt där, kan vi nu med rimligt hopp om framgång bygga större och mer komplexa mjukvaruintensiva system. OM FÖRFATTARNA Richard E. Fairley är professor i datorvetenskap och biträdande dekanus för OGI School of Science and Engineering vid Oregon Health & Science University. Hans forskningsområden inkluderar kravhantering, programarkitektur, utveckling av mjukvaruprocesser, skattning, mätning och övervakning av mjukvaruprojekt, riskhantering samt utbildning i mjukvaruutveckling. Mary Jane Willshire är biträdande professor i datorvetenskap på Electrical Engineering and Computer Science Department vid University of Portland, där hon föreläser och bedriver forskning kring mjukvaruutveckling, användargränssnitt samt databasteknik. Nr 2/3 juni

14 AV MOHAMMAD A. ROB Misslyckade projekt i mindre företag Copyright 2003 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad på engelska i IEEE Software 2003, med namnet Project Failures in Small Companies. Författaren råkade ut för en rad problem som till slut stjälpte hela projektet. Men istället för att sörja drar han lärdomar av det som inträffat och förmedlar här fem tips för att du ska slippa hamna i samma situation: I februari 1998, på toppen av IT-boomen när nästan alla företag höll på att åtgärda år buggar, anställdes jag som programmerare och analytiker av ett litet IT-företag i Houston, Texas. Företaget tillhandahöll datatjänster hårdvaru- och maskinvaruunderhåll, samt datalagring åt kunder och utförde även en del mjukvaruutveckling. Jag fick i uppdrag att ta fram funktionsspecifikationer för två pågående mjukvarurelaterade utvecklingsprojekt. En annan person, huvudsakligen involverad i systemdesignen, var min projektchef. Han visade sig vara mycket behjälplig med att svara på frågor och diskutera alternativ. Mitt intuitiva intresse för problemlösning på detaljnivå hjälpte mig vinna hans förtroende. Systemkraven var redan på plats, så närhelst jag hade frågor kring dessa kunde jag vända mig till honom. En gång, när han inte kunde förklara en sak för mig, ordnade han ett konferenssamtal med kunden. Det var dock alltid min chef som tolkade kundens krav. Han dikterade kraven och motsatte sig alla försök från kunden eller mig att utforma dem annorlunda. Trots att mina erfarenheter från detta företag var smärtsamma i slutänden gav de mig värdefulla insikter i hur projekt kan misslyckas. Anlitande av konsulter Under de följande 18 månaderna arbetade min chef och jag med att utveckla ytterligare två system och göra om ett tredje befintligt system. Efter att ha tagit fram de nya systemens funktionsspecifikationer lade vi ut själva mjukvaruutvecklingen på ett företag i Indien. Jag ombads testa systemen efter att ha mottagit leverans och ge återkoppling till programmerarna. Systemplattformen var Microsoft Access- VBA (Visual Basic for Applications). Vi planerade att göra om bakändens databaser med SQL Server och samtidigt behålla frontänden i Access. Jag skulle hålla projektchefen informerad om projektens fortskridande. När jag rapporterade att jag upptäckte fler fel än förväntat sa min chef att de indiska programmerarna saknade de nödvändiga programmeringskunskaperna. Men när jag frågade programmerarna om felen sa de att specifikationerna var bristfälliga. De klagade över att bakändens design var en blandning av traditionell filbaserad design och relationsdatabasdesign, medan frontändens design var en blandning av traditionella programmeringsspråk och visuella språk. En noggrann undersökning fick mig att instämma med programmerarna. Min chef vägrade dock att ge vika och vidhöll att specifikationerna var perfekta. Han var obeveklig i sin uppfattning att de indiska programmerarna bar skulden eftersom de inte kunde programmera. Efter att ha hållit på så här i flera månader övertygade min chef sin chef, vice vd med ansvar för produktionen, att säga upp kontraktet med det indiska företaget. Den ej färdiga delen av det mindre projektet gick till en lokal konsult för färdigställande med hjälp av en av mina programmerarkollegor. För att föra det större systemet vidare valde min chef att anlita ett litet Microsoft-certifierat mjukvaruföretag i Houston. Den nya konsulten var inte glad över databasens design, men gavs order av min chef att inte avvika från specifikationen. Jag fick skulden Det lilla företaget behövde uppdraget och sa därför inget. När jag fick den första leveransen upptäckte jag dock till min förvåning att de hade gjort om databasen. Jag tvekade att säga något om förändringen till min chef, men nämnde den för vår produktionschef. När min chef fick höra talas om detta sa han åt mig att inte lägga näsan i blöt. Mycket riktigt åkte det Microsoft-certifierade mjukvaruföretaget ut efter detta. Vad värre var, vårt företags vd gav mig skulden för röran på grund av min inblandning. Parallellt med detta gav vi oss in i ett komplext projekt för konvertering av en befintlig applikation utvecklad 10 år tidigare. Projektet avsåg att konvertera en Clipper-FoxPoroapplikation till en miljö baserad på Visual Basic-SQL Server. Den ursprungliga systemutvecklaren hade påbörjat konverteringsprocessen innan han lämnade företaget på grund av ett bråk om pengar. Min chef anlitade tre oberoende konsulter för att arbeta med konverteringen tillsammans med vårt eget folk. Jag fick till uppgift att utöver att övervaka programkonfigurationerna samordna testningen, verifieringen och integrationen av programmodulerna. Några månader senare hade flera konsulter kommit och gått, parallellt med att min chef fortfarande försökte förstå vad som var fel med projektet. Han liknade projektet vid en hoprullad orm: det hade varken huvud eller svans. Under tiden tog det en erfaren konsult tre månader att producera en enda rapport. Allt eftersom tiden gick blev kunden allt mer irriterad och hotade slutligen med att stämma vårt företag för kontraktsbrott. Trots att jag lämnade företaget kort därefter, fortsatte jag att hålla kontakten med en programmerarkollega som också letade efter nya möjligheter. Innan även han slutade, nämnde han att företaget hade gett min chef en första varning och sedan avskedat honom efter en andra varning. Därefter skrotades alla tre systemen. Projekten i backspegeln Sett i backspegeln betraktar jag mina erfarenheter på det hela taget som positiva trots det förtret de orsakade mig just då. Nu har jag hjälp av det inträffade när jag föreläser om systemanalys och systemdesign samt IT-projektledning. Studenterna uppskattar mina erfarenheter ur verkliga livet på föreläsningarna och jag ger dem projektarbeten med förväntningar hämtade från verkligheten. Vidare 14 Nr 2/3 juni 2004

15 LED LAGET MOT SEGER hjälper mina erfarenheter mig att rekapitulera och underbygga mjukvaruutvecklarnas expertkunskaper, inte minst skälen till att projekt går över styr (se Robert Glass Short- Term and Long-Term Remedies for Runaway Projects, Comm. ACM, vol. 41, nr. 7, 1998, sidorna 13 15). I min kurs i IT-projektledning diskuterar vi dessa lärdomar inom ramen för nio projektledningsrelaterade kompetensområden: integration, omfattning, tid, kostnad, kvalitet, risk, kommunikation, upphandling samt personalhantering (se A Guide to the Project Management Body of Knowledge, Project Management Inst., 2000). Ett misslyckande med att hantera något av dessa områden har gång efter gång visat sig försämra projektresultatet. Så här i efterhand misslyckades min chef på så gott som alla nio områdena. Dragna lärdomar De här erfarenheterna kan lära oss många lärdomar. De fem viktigaste är de följande: 1, Allt handlar om kommunikation Även om varje medlem i gruppen lämnade in veckovisa lägesrapporter hade vi aldrig några grupp- eller statusmöten. Kommunikationen med användarna var minimal. Konsultkontrakten var en katastrof. Kommunikationen och samarbetet med de utländska programmerarna var närmast obefintlig. Företagsledningen kommunicerade bara genom vår chef och var därför omedveten om de problem som byggdes upp inom projektgruppen. De kände bara till vad som berättades för dem. Framgångsrik mjukvaruutveckling kräver öppen kommunikation inom projektgruppen, mellan programmerarna och användarna samt med ledningen. 2, Ta reda på projektets storlek och komplexitet Vi gav oss in i flera projekt utan att känna till de närmare detaljerna. Projekten gavs till oss utan att vi hade fått delta i en genomförbarhetsstudie. Kraven ändrades därför ofta, främst på grund av designkomplexiteten och avsaknaden av användarengagemang. Vi fick reda på de olika projektens storlek och komplexitet först under arbetets gång. För framgångsrik mjukvaruutveckling måste projektets omfattning hållas under kontroll redan från början vilket vi fick lära oss den långa vägen. 3, Undvik nya eller okända konsulter Vi gick från en konsult till en annan, bara för att hamna i den ena katastrofen efter den andra. Den främsta anledningen var att de inte var insatta i projektets natur och systemdesignens komplexitet. Välj konsulter som har fortlöpande affärsrelationer med projektgruppen och undvik konsulter stationerade på annan ort eller i utlandet. 4, Upprätthåll projektgruppens utbildningsnivå Vår chef hade goda kontakter med flera lokala rekryteringsföretag som försåg oss med programmerare efter behov. Dessa ingenjörer hade dock skilda utbildningsbakgrunder från en med gymnasieexamen till några med doktorsgrader i psykologi och fysik. Följden blev en miljö kännetecknad av konflikter och kompromisser i fråga om mjukvarans kvalitet. För att få jobbet gjort så ordentligt och effektivt som möjligt måste företagen anställa programmerare med nödvändiga kompetenser och kunskaper. 5, Projektledningen måste vara flexibel Vår projektchef var en Unix-guru, men systemen var utvecklade i Windows-miljö. Han var C-programmerare på expertnivå, men applikationerna var utvecklade i Visual Basic. Han försökte göra systemen enkla för användarna, men svåra för programmerarna. Han var gammal och blasé, men gruppen var ung och entusiastisk. Han var obeveklig och vi fick alla betala priset för det. Mina erfarenheter från ett litet mjukvaruutvecklingsföretag visar att projektledning är krävande och om projektledaren är ett hinder så kommer projektet obönhörligt att misslyckas. Och när det gör det kan det innebära katastrof för chefen och alla som arbetar under honom eller henne i ett mjukvaruutvecklingsprojekt. Mohammad A. Rob är biträdande professor i ledningsinformationssystem vid universitetet i Houston-Clear Lake. Nr 2/3 juni

16 AV SVEN WENNERSTRÖM Ska projektledaren vara teknisk specialist? Djup teknisk förståelse viktig Sven-Evert Johansson Vad är ett lyckat projekt? För mig är ett lyckat projekt mer än att man skapat produkten som kunden vill ha, inom utsatta tids- och kostnadsramar. I ett lyckat projekt har man skapat något mer, en återanvändbar produktstruktur, en arkitektur och en plattform att bygga vidare på. Sven Evert Johansson hjälp av andra för att göra den uppskattningen löser inte hela problemet. Till slut är det ändå projektledaren som ska göra bedömningen om uppskattningarna ligger inom rimliga gränser. Frestas ta genvägar Naturligtvis är det inte rimligt att projektledaren ska behöva ha kunskaper i projektets alla detaljer, men han måste åtminstone ha en god bild av hur projektets delar hänger ihop för att inte riskera att fatta felaktiga beslut. Den som inte har förståelse för hur arkitekturen fungerar och hur projektet hänger ihop frestas ofta att ta genvägar i utvecklingsarbetet för att pressa fram snabba lösningar. Genvägar som hotar att degenerera hela systemet. Samtidigt måste man komma ihåg att det i många fall finns en konflikt mellan projektledning och arkitektur. Projektets mål är ju att nå sitt mål så billigt som möjligt, medan man på arkitekturplanet kan ha andra mål såsom återanvändbarhet och produktfamiljstänkande. Målen kan stå i motsats till varandra. För att kunna göra avvägningar mellan de olika målen som finns krävs kunskap om produkten, kunderna och omvärlden som produkten ska fungera i. V på produkten och tekniken att man vågar dra i bromsen. Vilka egenskaper ska då en projektledare besitta förutom den tekniska förståelsen och domänkunskaperna? Uppgiften att hålla fokus i projektet och visualisera målet och helheten är inte lätt och kräver både lyhördhet och förmågan att prata med folk. Dessutom krävs ett visst mått av ordningssinne, att man verkligen följer upp ändringshantering, ser till att dokument kommer fram och att testningen sköts. Administrerar istället för att leda Men att bara följa upp är inte projektledning, projektledning handlar om att skapa något och att faktiskt vara den som leder arbetet. Det administrativa arbetet runt omkring delegeras med fördel till projektadministratören. Att sitta och räkna på resurser och tidsplaner har inget med projektledning att göra, det är projektadministration. Tråkigt nog finns det tendenser att projektledare ofta väljer att administrera projekt istället för att leda dem. Med en större andel projektledare som verkligen leder sina projekt, skulle vi se bättre produkter och fler projekt som håller sig inom sina tids- och kostnadsramar. För att projektledaren ska kunna nå dit är det nödvändigt med en djup teknisk förståelse och domänkunskap. Hur ska en projektledare kunna adressera en komplex fråga om man inte förstår var komplexiteten ligger? Grundläggande för att ett projekt ska lyckas är att projektet organiseras och får ramar och en struktur. Projektorganisationen speglar produktens arkitektur och projektledaren måste därför ha förståelse för hur projektets delar hänger samman. Uppstår intrikata kopplingar mellan delsystem i produkten så kommer man också att få intrikata kopplingar mellan människor i projektet. Vilket i slutänden leder till en dålig projektekonomi. Utan en god kännedom om produkten är det dessutom omöjligt att göra kostnadsuppskattningar av de olika delsystemen. Att ta Större ansvar i iterativa processer Den tekniska kompetensen blir extra viktig i projekt som bedrivs enligt iterativa modeller, som till exempel RUP. Arbetsformen kräver att iterationerna planeras så att utvecklingsarbetet utförs i en ordning som fungerar för såväl plattform som arkitektur. De iterativa modellerna missar ofta att adressera frågorna kring systemets egenskaper i vilken iteration ska vi ha uppnått en viss prestanda? När ska vi ha nått kraven på återanvändbarhet? Det blir istället helt och hållet projektledarens ansvar. Det händer också att projekt eller delprojekt riskerar att haverera. Det är då projektledarens uppgift att vara den som säger ifrån om att man gått in i en återvändsgränd. Vilket naturligtvis kräver att man är så säker 16 Nr 2/3 juni 2004

17 AV SVEN WENNERSTRÖM Jan Sjunnesson Projektledaren har inte tid med tekniska frågor SProjektledarens viktigaste uppgift är att redan från början skapa goda förutsättningar för projektet. Det innebär att definiera projektets ramar och få alla att arbeta efter dem.att hålla ett större projekt på banan kräver full koncentration, det tar så mycket tid att det är olämpligt att samtidigt ha det tekniska ansvaret för projektet. En projektledare som samtidigt är ansvarig för systembesluten är chanslös i ett stort projekt, en sådan projektledare bromsar utvecklingen istället för att leda den. Organisationen blir stående i väntan på både tekniska och administrativa beslut. Gränsen för vad en ensam projektledare klarar tror jag går vid ca 20 projektdeltagare. Lösningen är att projektledaren koncentrerar sig på att leda projektet och delegerar ansvaret för hela systemlösningen till en systemansvarig teknisk ledare. De systemansvariga som jag arbetat tillsammans med har jag litat blint på. Den person som har fått rollen som systemansvarig har fått den för att han är extremt duktig. Två parallella strukturer Jag är van vid att arbeta i projekt som är organiserat i delprojekt om personer var. Där har vi haft två parallella strukturer, en med projektledare och delprojektledare och en med systemansvarig och delsystemansvariga. Organisationen har speglat arkitekturen. Projektledaren arbetar sedan nära delprojektledarna och den systemansvarige. Projektledaren måste hela tiden vara lyhörd för de signaler som kommer från projektet. Tecken på att till exempel delar av projektet riskerar att komma efter i tidplanen är svåra att uppfatta om man inte hela tiden lever med projektet och har en fullständig överblick. Något man inte har tid med om man samtidigt ska ägna sig åt projektets tekniska frågor. Även i kontakten med kund arbetar projektledaren och den systemansvarige som ett team. Jag som projektledare svarar aldrig på tekniska frågor, utan överlåter det åt systemansvarig. Vad jag kan svara på är vad som fungerar och inte fungerar i systemet just nu, men jag går aldrig in på tekniska detaljer. Som projektledare måste jag däremot ha en kommersiell förståelse, veta vad kunden vill ha ut av projektet och framför allt veta vad det egna företaget vill ha ut av projektet. Förtroende för projektledaren krävs Därmed inte sagt att projektledaren inte behöver teknisk kompetens. Även om man inte styr projektet tekniskt, så finns flera skäl till varför den tekniska kompetensen behövs: Nedbrytningen av projektet sker med den tekniska arkitekturen som grund, som ansvarig måste projektledaren förstå hur organisationen speglar arkitekturen. För att kunna föra en diskussion och uppfatta de signaler som projektet sänder ut måste man förstå tekniker och teknikers problem. Förståelse för produktens omvärld och vad som gäller i branschen där man verkar. Förtroendekapital. Vägval som inte kunnat förutses måste göras i alla projekt. Om projektdeltagarna inte har förtroende för projektledarens kompetens kommer projektet inte att följa med i de beslut som fattas. Dessutom krävs speciella personliga egenskaper som projektledare. Det viktigaste är lyhördheten, att lyssna på vad folk egentligen säger och att kunna tolka signaler. Det är också viktigt att med viss bestämdhet definiera de ramar och regler som ska gälla för projektet och se till att de följs. Dålig förankring och uppföljning Som konsult kommer jag ofta till projekt som drabbats av problem och har lite svårt att komma framåt. Nästan genomgående beror problemen på att man inte har de grundläggande ramarna för projektet klara för sig och att planerna inte är förankrade hos projektmedlemmarna. Ett annat problem brukar vara att projektet inte följs upp tillräckligt ofta, eller i tillräckligt detaljerad grad. En bra projektledare har hela tiden projektets mål och andemening i sikte. Han är inne i projektet, som en del av det, samtidigt som han kan ta sig ur det och se det från distans. Det är en skicklighet i sig. Jan Sjunnesson Nr 2/3 juni

18 AV ANDERS KÄLLMAN Allting är projekt! Denna artikel behandlar projektformen ur ett vanligt skandinaviskt perspektiv. Det ger förklaringar till hur man kan hantera styrbarheten i projekten. Slutligen ges en del tips och råd till projektledare för mindre projekt och uppdrag i organisationer, där det mesta idag ska bedrivas i projektform. I Skandinavien var det förr, år tillbaka mest vanligt med projekt för de mer omfattande förändringarna, nya komplicerade eller komplexa system, nya produkter som bilar och elektronik, utveckling av militär materiel etc. (förutom traditionella bygg- och anläggningsprojekt). Idag har det nästan gått inflation i projekt, allting tycks vara projekt. Den vanligaste formen sett ur organisatorisk synvinkel är att man arbetar i projektmatris. Det vill säga att man skapar projektorganisationen utifrån de resurser som finns i linjeorganisationen och kompletterar med inhyrda eller projektanställda medarbetare. Detta ställer stora krav på att organisationen kan hantera projektverksamheten. De stora projekten drivs ofta traditionellt, ibland men inte alltid, med bra projektmetodik och verktyg som stöd, men när alla förändringar och all utveckling ska ske i projektform, stora som små uppgifter, krävs en hel del extra av organisationen, definitivt av projektledare och beslutsfattare. Det kallas ibland för projektivitet, det vill säga organisationens förmåga att med projektformen nå verksamhetens affärsmässiga och sociala mål. Uttrycket myntades 1984 av Torbjörn Wenell, ansedd som något av en pionjär och projektguru i Skandinavien. För att nå hög projektivitet och driva allt förändringsarbete i projektform krävs att man hanterar grundkriterierna på ett acceptabelt sätt. Dessa grundkriterier är: Gemensam projektsyn i hela organisationen. Flexibel organisation med hög styrbarhet (styrbarhet förklaras separat). Ett kreativt arbetsklimat. En bra, föredömlig och situationsanpassad ledarstil. Balanserad projektportfölj. Fungerande och ändamålsenlig projektmetodik. Förklaring till dessa kriterier följer enligt nedan. PROJEKTIVITET Gemensam projektsyn Samtliga involverade i projektverksamheten ska ha förståelse och insikt i hur man arbetar i projekt. Det gäller alla, från top-management till enskilda medarbetare. Metodiken ska givetvis vara anpassad till verksamheten och organisationens storlek. Det är av yttersta vikt att man i ledningens linjefunktion med löpande arbetsuppgifter, skiljer detta mot de roller som man tar på sig i projektorganisationen. Flexibel organisation med hög styrbarhet Det måste finnas både tidsutrymme och möjlighet för medarbetare att ingå i olika projektkonstellationer. Detta låter som en självklarhet, men i de flesta av dagens organisationer i Sverige, där man delar löpande arbete i linjefunktionen med projektmedverkan, sker ofta suboptimering av individernas tillgängliga tid. Detta är en stor orsak till att många projekt inte håller tidplanerna. En vanlig fälla är också att man låser individer till sin fackkompetens eller att man skapar oundgängliga nyckelresurser som ska vara involverade i nästan alla projekt. Styrbarheten beskrivs nedan separat och gäller för såväl hela företaget/organisationen som det enskilda projektet. Ett kreativt arbetsklimat Organisationen ska bädda för att man i projekten ska ha möjlighet till ett kreativt arbetsklimat, såväl psykiskt som fysiskt och att utnyttja synergieffekterna av att arbeta i grupp. Kreativiteten får inte hämmas av bestraffning när man gör fel (första gången) då projektarbete ju är att man många gånger är ute på oprövad mark. Medicinen bör vara tillrättavisning vid fel och belöningar vid väl utfört arbete även om detta varit förväntat. Medarbetarna i projektet ska också ha tillgång till relevanta och tidsenliga verktyg för att kunna utföra sina arbetsuppgifter på ett effektivt sätt. Lokalerna ska också vara ändamålsenliga. Rätt miljö för arbetsmöten med bra utrustning, white-board och blädderblock är en självklarhet och inga rum utan fönster. I vissa projekt kan det vara en fördel med kontorslandskap som ger möjlighet till närkontakt mellan medarbetarna. I andra projekt krävs lokaler och kontorsrum som ger möjligheter till lugn och koncentration för den enskilde medarbetaren. En bra, föredömlig och situationsanpassad ledarstil Att vara ett föredöme, leda som man lär, rätt chef på rätt plats är väl målet för varje ledare, men det är inte alltid som man gör rätt saker utan man, i god tro, försöker göra saker rätt. En vanlig fälla är också att personer avancerar i hierarkin till sin inkompetensnivå, dvs att när man blir befordrad utifrån att ha varit en kompetent och skicklig specialist blir chef eller projektledare utan att ha de ledaregenskaper som krävs. Som ledare är det självklart att man sänder rätt signaler till sina medarbetare. Det går inte att säga med ord det ena och agera på ett annat sätt. Detta kan ju jämföras med att man som förälder inte kan förbjuda sina tonåringar att röka eller dricka alkohol och berätta om hur skadligt det är, samtidigt som man gör det själv. Balanserad projektportfölj Portföljhantering är ett måste för att organisationen ska nå hög projektivitet. Att kunna prioritera mellan olika projekt och samtidigt prioritera resurser mellan löpande arbete i linjeorganisationen är ett måste. Många organisationer startar för många projekt. Det borde bara finnas 3 nivåer på prioritet på projekten, i stället för som många gånger är fallet, 5 eller ännu fler nivåer. I vissa organisa- 18 Nr 2/3 juni 2004

19 LED LAGET MOT SEGER INTENT Figur 1 ROLES NEED STRUCTURES STRAT M ODEL TOTALITY ATEGY tioner tycks ju alla projekt ha prioritet 1 utan bedömning om vad som verkligen är viktigast. De tre nivåerna bör vara: måste genomföras (mht. omvärlden), mycket viktigt och viktigt. Förändringar med lägre viktighetsgrad bör inte startas som projekt utan som löpande förändringsarbete i linjeorganisationen utan fastställt slutdatum. I en organisation med hög projektivitet gäller också att skilja mellan projekt och uppdrag. Projekt med, i relation till företaget, stor organisation, tidsrymd på minst ett halvår, viss komplexitet och komplicerad förändring, ska bedrivas med formalia och relevant projektorganisation. Mindre uppgifter kan bedrivas som uppdrag utan krav på all formalia och korta beslutsvägar. Ledare för dessa uppdrag ska inte drivas av projektledare, möjligen presumtiva sådana, då risken annars finns för en urvattnad projektledarroll. Avdelningsinterna förändringar bör sällan drivas som renodlade projekt. En viktig sak i sammanhanget är också att skilja mellan orderprojekt och interna projekt och att ha en tydlig prioritering mellan dessa. För att hantera de olika projekten, med prioritet och resurstilldelning, bör PROJECTIVITY TOOLS KNOWLEDGE COMPETENCE APPLICAT BENEFIT UNDERSTANDING ATIO N BELIEF ABILITY TRAINING det finnas en organisationens projektkoordinator (projektdirektör) som har samma status i organisationen som övriga avdelningschefer. Denne person kan ingå i styrgrupperna för de viktigaste projekten och samtidigt fungera som länk mellan projekten och linjeverksamheten. Projektkoordinatorn kan också ha ansvaret för utveckling av projektmetodik, utbildning inom projektområdet och portföljhanteringen. En ändamålsenlig projektmetodik En självklarhet för en organisation som strävar mot hög projektivitet är att man har en ändamålsenlig projektmetodik att följa. Det är viktigt att modellen är generell och gäller för alla typer av projekt och inte är sammanvävd med kvalitetssystem, produktutvecklingsmodell, systemutvecklingsmodell eller andra utvecklingsmodeller. Modellen ska användas som verktyg för respektive projekt och inte vara ett regelverk som skapar överbyråkratisering och överdriven formaliahantering. För att nå hög projektivitet i en organisation krävs ett samspel mellan kompetens, metodik, färdighet och vilja. Se figur 1. STYRBARHET Begreppet styrbarhet utvecklades i Sverige under senare delen av 70-talet och början av 80-talet av Torbjörn Wenell och S G Larsson, då pionjärer inom projektområdet i Skandinavien. De utgick då från faktorer som påverkade hela organisationens sätt (inte enskilda projektet) att styra verksamheten mot långsiktiga mål och visioner. Min egen erfarenhet har visat att dessa faktorer gäller även idag och sannolikt kommer det även att gälla för lång tid framöver, dock med justeringar mot de omvärldsförändringar som ständigt sker. Det går även att omsätta de sex styrbarhetsfaktorerna till det enskilda projektet, stora som små. I många fall ännu viktigare i mindre projekt som inte får så stor uppmärksamhet, eller där det inte ställs så höga krav på formalia från projektledare och medarbetare. De sex styrbarhetsfaktorerna är: Vision/Mission/Roll Organisationsstruktur Läsbarhet Personresurser Ledarstil Värdegemenskap Nedan följer förklaring till de sex styrbarhetsfaktorerna och vad man bör ta hänsyn till. Faktorerna är beskrivna utan inbördes rangordning. Vision/ Mission/ Roll Visionen är ju ett idealtillstånd som vi strävar efter att nå, ofta tätt förknippat med missionen för organisationen. I många projekt är ju detta inte kanske huvudmålet eftersom det ligger längre bort i tiden än projektslutet. I ett lyckat projekt ska ju delmålen vara uppfyllda inom projekttiden. Visionen är här mer jämförbar med den sammanfattning av alla de effekter man önskar nå, effektmålen. Det är av stor vikt att alla som bidrar till projektets förväntade framgång är medvetna om visionen och vilken nytta man bidrar med mis- Nr 2/3 juni

20 LED LAGET MOT SEGER Figur 2 sionen. Missionen bör uttryckas på ett sådant sätt att alla involverade inser sin roll, det man bidrar med, för helheten. Organisationsstruktur Projektorganisationen ska vara anpassad till förutsättningarna. Detta kan ju låta självklart men ofta är detta inte fallet utifrån flera skäl. Ett kan vara att man skapar en projektorganisation utifrån tradition, så brukar vi göra eller från det som uttrycks generellt i en modell. Viktigt är att man spår om framtiden, speciellt i längre projekt. Hur kommer linjeorganisationen se ut om ett år eller två? Finns det nyckelresurser att tillgå? Finns det tillräcklig flexibilitet för att byta ut projektmedlemmar? En vanlig fallgrop är alltför statiska projektorganisationer som inte anpassar sig till de yttre omständigheterna. Läsbarhet Tillgången på relevant fakta är av största vikt när oförutsedda händelser inträffar i projektet. Detta innebär att man kontinuerligt kan läsa av hur tillståndet i projektet är. Det gäller såväl ekonomiskt och tidsmässigt som kvalitetsmässigt. Den veckovisa medarbetaruppföljningen kan många gånger kännas överdriven och verkar kanske också så när det mesta går som det ska, men det är vid kritiska lägen som man har nytta av detta. I projektet ska det inte finnas något eftersläp i uppföljning av vare sig aktiviteter eller ekonomisk uppföljning. Rapportering av tid är ju inte ett konstaterande av nuläge, utan bra för ekonomisk uppföljning och framtida planering eller omplanering. Ett varningens ord bör också riktas mot flashiga OH-bilder, diagram och project-planer som inte återspeglar verkligheten. Det är ju inte viljan som ska förmedlas utan det verkliga tillståndet. Personresurser En fråga som varje projektledare borde ställa sig är nyttjar jag mina medarbetare på rätt sätt? Tidigt i projektstarten ska projektledaren ta reda på varje individs tidigare erfarenheter, personliga intressen, förväntningar 20 Nr 2/3 juni 2004