Nja, alltså den här boken är ju rätt hajpad...men jag är skeptisk...visst själva konceptet och layouten är tilltalande men innehållet är i stort sett obefintligt. Författaren beskriver ett scenario där flyktingsituationen är den omvända, det vill säga det är vi Svenskar som tvingas fly, i det här fallet till Egypten. Och det är absolut en tanke som är värd att begrunda...och en tanke som gör det lite lättare att förstå situationen för dagens flyktingars...men författaren har ju inte tagit denna tanke ett enda ynka steg vidare. Visst väcker författaren tanken om hur det skulle vara att vara flykting...men detta är väl knappast en tanke som inte alla svenskar redan funderat på någon gång?
Så jag blev besviken...hade hoppats på att författaren hade fördjupat resonemanget och dragit det ett par steg till. Boken är mycket kort och läses bokstavligen på en kvart. Som det är nu känns boken möjligen meningsfull för elever på lågstadiet. Det bästa med boken är dess layout i form av ett pass samt de coola bilderna...
Jag är en stockholmare som försöker att bli lite smartare. Får se om jag lyckas med detta, inte helt säkert.
lördag 27 oktober 2012
Planes, Trains And Auto-Rickshaws
I Laura Pedersens bok Planes, Trains And Auto-Rickshaws: A Journey Through Modern India får vi följa med på en resa genom det moderna Indien, från kaosets Delhi till söderns tropiska landskap. Som brukligt i den här typen av reseskildringar så blandas författarens personliga reflektioner och reseminnen med allmänna fakta om platserna som besöks. Pedersen beskriver resan på ett mycket inspirerat och ibland humoristiskt sätt men tyvärr är de mer faktabetonade delarna inte lika kul att läsa. Där finns till exempel ett förhållandevis långt avsnitt om berömda Indiska ledare och ett annat som handlar om kvinnornas situation. Dessa avsnitt känns mest inslängda i boken för att ge den mer tyngd, men för min del innebar dessa avsnitt endast att boken tappade tempo. Men om man hoppar över dessa två avsnitt så är boken klart läsvärd!..
Plats:
Indien
torsdag 18 oktober 2012
Hobbiten - äventyrens äventyr och sagornas saga
Varför har jag inte läst Tolkiens Hobbiten tidigare? Hur kan jag ha missat den? Detta måste vara sagornas saga och äventyrens äventyr, ett mästerverk som borde läsas av alla, så väl unga som gamla.
Jag tror att det är många med mig som missat den på grund av den inte ingår i trilogin Sagan om Ringen, är man inte insatt är det ju lätt att tro att första delen i trilogin är sagans och äventyrets början. Men så är alltså inte fallet utan den värld och många av de karaktärer som finns i Sagan om Ringen finns även med i Hobbiten. Det är här man lär känna karaktärer som Bilbo Baggins, Gandalf och Gollum, läser man inte Hobbiten innan man läser Sagan om Ringen så missar man alltså mycket av karaktärsbeskrivningen. Sagan om Ringens fantasivärld blir än mer fullständig om man först läser Hobbiten!.........
Jag tror att det är många med mig som missat den på grund av den inte ingår i trilogin Sagan om Ringen, är man inte insatt är det ju lätt att tro att första delen i trilogin är sagans och äventyrets början. Men så är alltså inte fallet utan den värld och många av de karaktärer som finns i Sagan om Ringen finns även med i Hobbiten. Det är här man lär känna karaktärer som Bilbo Baggins, Gandalf och Gollum, läser man inte Hobbiten innan man läser Sagan om Ringen så missar man alltså mycket av karaktärsbeskrivningen. Sagan om Ringens fantasivärld blir än mer fullständig om man först läser Hobbiten!.........
Karta över den del av Middle-Earth där Hobbiten utspelar sig. (Klicka för större version.).. |
söndag 14 oktober 2012
Projektledning – Agila metoder
Inledning
I det här inlägget kommer jag att redogöra för vad agil projektledning och systemutveckling är samt hur denna skiljer sig från traditionella metoder. För att belysa skillnaderna har jag valt ut fem olika begrepp/områden som jag kommer att studera mer i detalj, och dessa är: projekttriangeln, projektledarrollen, projektgruppen, mötesrutiner och dokumentation. Avslutningsvis reflekterar jag över den agila metodens för- och nackdelar.Den agila modellen
Den agila projektmodellen har sitt ursprung ur det missnöje som i slutet av 1900-talet fanns i IT-branschen mot de då existerande modellerna, man ansåg att dessa var alltför stela och byråkratiska. För mycket tid lades på dokumentation och för lite på att utveckla de IT-system som skulle levereras. Nya mer flexibla projektmodeller växte fram och i början av 2001 samlades företrädare för dessa för att skapa gemensamma riktlinjer för hur denna typ av projekt kunde drivas. Man skrev ner dessa riktlinjer i det som kallas för det ”Det Agila Manifestet”, http://agilemanifesto.org/iso/sv/. I detta manifest skriver man bland annat följande:
Individer och interaktioner framför processer och verktyg
Fungerande programvara framför omfattande dokumentation
Kundsamarbete framför kontraktsförhandling
Anpassning till förändring framför att följa en plan
Det vill säga, medan det finns värde i punkterna till höger,
värdesätter vi punkterna till vänster mer.
Man förtydligar sedan detta i 12 stycken principer, dessa finns att läsa på http://agilemanifesto.org/iso/sv/principles.html. Två av dessa principer lyder: ”Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara” samt ”Leverera fungerande programvara ofta, med ett par veckors till ett par månaders mellanrum, ju oftare desto bättre.” Och detta är ett av den agila projektmetodens särdrag, man har många små leveranser istället för en eller ett fåtal större, som ju är det normala i traditionella projektmetoder. En av de största fördelarna med detta är att man lättare kan anpassa sig till de förändringskrav som ofta uppstår under projekt. I och med att beställaren får många små delleveranser så kan man snabbt upptäcka saker som behöver förändras och på ett smidigt sätt planera in detta i kommande delleveranser. Faktum är att de agila principerna till och med välkomnar förändringar under projektets gång detta då beställaren får ett bättre och mer konkurrenskraftigt system. (Gustavsson, 2007, sid 20 – 24 samt http://agilemanifesto.org/iso/sv/)
Andra särdrag hos den agila metoden är att projektledaren fungerar mer som en stödjande lagkapten än som en styrande chef samt att man inte gärna förändrar projektgruppen under projektets gång. Mer om detta och andra karaktäristika för den agila metoden beskriver jag nedan.
Projekttriangeln – tid, kostnad och resultat
Projekttriangel är ett sätt beskriva de tre parametrar som ett projekt styrs av. Tid, kostnad och resultat kan sägas vara projektets begränsningsparametrar då det är tillgången på dessa tre resurser som sätter projektets ramar. Detta gäller för såväl traditionella projekt som för agila. Skillnaden är dock att man i traditionella projekt kan förändra alla dessa tre parametrar under projektets gång medan man enligt den agila metoden endast kan förändra leveransparametern. Det vill säga om man i ett agilt projekt inser att man inte kommer kunna hinna leverera planerat resultat i tid så senarelägger man inte leveransen eller tillför mer personalresurser utan man skär istället ner på vad som ska levereras.Logiken bakom detta är att det i praktiken oftast är mycket svårt att tillföra personalresurser i ett projekt med kort varsel. Om man skulle få tillgång till fler personer i projektet så skulle detta i många fall innebära att det uppstod personalbrist på andra platser i verksamheten. Dessutom är det svårt att snabbt få in nya medlemmar i projektgruppen. Att öka projektgruppens storlek blir ineffektivt. Två av grundprinciperna inom den agila metoden är ju just att behålla projektgruppen liten och intakt samt att ha kort tid mellan olika delleveranser, skulle man då skjuta upp leveransdatum eller utöka projektgruppens storlek så faller mycket av konceptet. (Gustavsson, 2007, sid 28 - 32)
Detta innebär också att man i agila projekt använder sig av time-boxing, det vill säga man jobbar med en fast deadline och utför så mycket av aktiviteterna som är möjligt med de resurser man har. Det man inte hinner med tar man med i kommande leveranser. (Gustavsson, 2007, sid 40 - 41)
Projektledarrollen
Den största skillnaden för en projektledare i ett agilt projekt är att denne fungerar som lagkapten och inte som chef. Projektledarens främsta uppgift är alltså inte att styra gruppen utan att stötta och hjälpa gruppen och röja undan eventuella hinder så att denna ska kunna utföra sina uppgifter. Besluten fattas inte av projektledaren över projektmedlemmarnas huvuden utan det är projektgruppen tillsammans med projektledaren som fattar besluten. Jämfört med den traditionella projektorganisationen är den agila alltså mindre hierarkisk.Men det finns givetvis situationen där projektledaren även i agila projekt måste fatta beslut, främst då projektgruppen trots medlingsförsök från projektledarens sida inte lyckas enas kring ett beslut. I dessa fall ligger avgörandet hos projektledaren. Man bör dock sträva efter att minimera antalet sådana tillfällen.
Det är projektledarens ansvar att projektet leds enligt den agila metoden, dvs. han måste vara väl förtrogen med konceptet samt ha förmågan att lära upp de projektmedlemmar som inte är insatt i metoden. Det är viktigt att projektledaren förklarar sin egen roll för projektmedlemmarna och övriga intressenter. (Gustavsson, 2007, sid 67 - 70)
Gustavsson tar bland annat upp följande punkter som exempel på konkreta aktiviteter som ligger inom den agila projektledarens ansvarsområde:
- Se till att eventuellt oklara krav förtydligas.
- Säkra projektets bemanning så att denna har rätt kompetens samt inte förändras under projektets gång.
- Gå på möten samt ansvara för tillhörande praktikaliteter.
- Kommunicera utanför projektgruppen.
- Arrangera kick-off och avslutningsmöte.
- Hantera kunder och projektbeställare.
(Gustavsson, 2007, sid 71)
Projektgruppen
En stor skillnad mellan det agila arbetssättet och det mer traditionella är att man ger varje enskild projektmedlem ett större ansvar och befogenheter. Projektledaren skall mer ses som en lagkapten än som en chef. Dessutom finns ett kollektivt ansvar inom gruppen på ett helt annat sätt än i traditionella metoder, det vill säga man går in och hjälper varandra oavsett om arbetsuppgiften egentligen ligger utanför personens ursprungliga ansvarsområde. Detta innebär i sin tur att man premierar tvärkompetens, det vill säga man försöker undvika att det finns vissa uppgifter som endast kan lösas av en speciell projektmedlem. Man undviker också att ta in externa experter. Arbetar man strikt agilt så finns det inga specifika roller utan hela projektgruppen arbetar tillsammans för att uppnå projektmålen och varje enskild projektmedlem anpassar sina arbetsuppgifter till vad som för stunden efterfrågas i projektet. Projektgruppen skall vara liten, optimalt är en storlek på fen till nio personer, och gruppens sammansättning skall inte förändras under projektets gång. I mer traditionella projektmetoder så är rollerna mer fasta och man är mer öppen att ta in externa experter samt förändra projektgruppens sammansättning under projektets gång. (Gustavsson, 2007, sid 75 - 77)Det finns dock en roll som avviker lite från ovanstående beskrivning och de är testrollen. Den rollen ska även i den agila metoden vara klart utpekad, detta då är viktigt att inte programmerarna testar och granskar sin egen kod. Testaren ska dock tillskillnad från traditionella projektmetoder finnas med under hela projektet, detta då i den agila metoden ju finns många delleveranser som ska testas. (Gustavsson, 2007, sid 81 - 82)
I och med den agila metoden så förändras alltså arbetssättet. ”Systemutvecklaren har blivit social” lyder rubriken på Guzmáns artikel om den agila projektmetoden. Och även om rubriken är något tillspetsad, det fanns ju givetvis sociala systemutvecklare även innan den agila metoden föddes, så ligger det något i detta då systemutvecklaren med det agila arbetssättet har kontakt med personer inom fler kompetensområden. I de mer traditionella vattenfallsmetoderna så var det relativt vattentäta skott mellan de olika kompetenserna, dvs. affärsutvecklarna gjorde först en affärsmässig bedömning, därefter tog IT-arkitekter och systemerare vid, dessa lämnade i sin tur vidare till programmeraren och slutligen testade testaren systemet. Det agila arbetssättet bygger ju på att man kommunicerar över kompetensgränserna, programmerare och systemerare kan till exempel ha direktkontakt med beställare och användare vilket snabbar upp processen samt ger dem en större förståelse för vad det är projektet ska leverera. Som projektmedlem är det också stimulerande att bredda sitt kontaktnät. (Guzmán, 2012)
Mötesrutiner
Det som är karaktäristiskt för den agila metoden är de dagliga avstämningsmötena. Enligt Gustavsson bör dessa vara mycket korta, ca 15 minuter, och genomföras stående. Stående därför att de inte ska bli långdragna diskussioner. På dessa korta dagliga möten ska alla projektdeltagare närvara och man ska gå igenom vad man har gjort sedan föregående möte, vad man kommer att göra fram till nästa möte samt vilka eventuella problem som finns för att man ska kunna leverera detta. Om det finns tid kan man även diskutera om det finns nya aktiviteter som bör planeras in samt om det finns något nytt beslut som gruppen har intresse av att veta. Var och en av projektdeltagarna ska alltså svara på dessa frågor, på så sätt får man en detaljerad bild av vad varje person gör på daglig basis. Detta leder till att tempot hålls uppe samt att eventuella problem upptäcks snabbt. Ovanstående kan jämföras med mer traditionella projektmetoder där längre möten hålls med längre tidsintervall, kanske varje eller varannan vecka, något som ökar risken för att eventuella problem inte upptäcks i tid samt kan leda till att tempot minskar. (Gustavsson, 2007, sid 155 - 157)De möten som hålls är i första hand inte till för att projektledaren ska kontrollera och styra utan för att projektmedlemmarna ska få reda på vad de andra arbetar med och om det finns några problem. I de agila projekten har ju projektgruppen ett kollektivt ansvar där det ingår att hjälpa de medlemmar som har problem. (Gustavsson, 2007, sid 151)
En annan typ av möte är det som hålls i samband med varje etappleverans. Här ska leveransen presenteras för projektets intressenter. Och i sann agil anda ska mötet hållas kort, runt en timme, och förberedelserna bör inte ta mer än två timmar. Det är viktigt att man här presenterar det faktiska resultatet och inte en förskönad presentation. Intressenterna ska på mötet få se exakt så som systemet ser ut, i annat fall riskerar de att bli besvikna när de ser den färdiga produkten. Denna presentation är även viktig för projektmedlemmarna då den innebär en form av avslut och något jobba för. Mötet skall inte gå över till att bli ett planeringsmöte för nästa etapp utan de eventuella synpunkter som uppstår under presentationen ska memoreras och sedan diskuteras på ett kommande planeringsmöte. (Gustavsson, 2007, sid 173 - 175)
I samband med varje etappslut så hålls i agila projekt också ett erfarenhetsmöte, detta till skillnad från traditionella projekt där denna typ av möten oftast hålls i samband med projektavslutet. Fördelen med att hålla denna typ av möte efter varje etapp är att man i kommande etapper i det pågående projektet kan dra nytta av detta. Möten bör vara korta, max en timme, och utgå från de två frågeställningarna vad som gick bra och vad som kan förbättras. Varje projektmedlem tänker igenom dessa frågeställningar och sedan diskuterar man alla synpunkter gemensamt. De förbättringsförslag som kommit fram tar man sedan med sig till nästa etapps uppstartsmöte. (Gustavsson, 2007, sid 177 - 179)
Dokumentation
Här skiljer sig den agila metoden avsevärt från de traditionella metoderna genom att man försöker att minimera dokumentationen så långt det är möjligt. En av punkterna i det agila manifestet handlar om just detta, där står det att man ska sträva efter enkelhet och ”maximera mängden arbete som inte görs”. (http://agilemanifesto.org) Faktum är att den agila metoden uppstod till stor del som en reaktion på att den mängd tid och energi som gick åt till dokumentation i de traditionella metoderna. Dokumentationen blev också ofta snabbt inaktuell då kraven vanligtvis förändrades under projektets gång, mycket tid spenderades alltså att uppdatera gammal dokumentation. De fanns dem som tyckte att en allt för liten del i utvecklingsprojekten gick åt till själva utvecklandet, något man ville förändra i och med den agila metoden. (Gustavsson, 2007, sid 20)Det är dock givetvis inte så att agila projekt genomförs helt utan dokumentation, en viss dokumentation behövs men det man vill undvika är att dokumentera bara för dokumenterandets skull. Dokumentationen ska vara efterfrågad. Och den dokumentation man ska fokusera på är den som är av nytta utanför projektet, till exempel förvaltningsdokumentation. Man ska minimera projektintern dokumentation och inom projektet istället använda sig av muntlig kommunikation. (Gustavsson, 2007, sid 43 - 47)
Reflektioner
Jag själv arbetat ett antal år i projekt som drivits med den traditionella vattenfallsmodellen och då tyckt att denna ibland varit alltför stel och omständlig så jag kan se tjusningen med den agila modellen. Här har vi en modell som fokuserar på att få saker och ting gjorda istället för att lägga tid på sådant som långa möten och tidskrävande dokumentationskrav. Dessutom fokuserar den agila modellen på korta projekt med snabba leveranser, något som jag som arbetat i den snabbt föränderliga webbranschen kan se nyttan med. I en föränderlig miljö är den agila metoden bättre då den inte utgår från en detaljerad kravspecifikation och därför lättare kan anpassa sig till ändrade krav som uppstår under projektets gång, något som är mycket vanligt när det gäller till exempel webbprojekt.Även Gustavsson tar upp ovanstående fördelar med den agila metoden men nämner också att metoden är bra då projekten är så pass komplexa att det är svårt att i förväg föreställa sig hur slutresultatet kommer att bli samt vid vidareutveckling i förvaltningsorganisationen. (Gustavsson, 2007, sid 16) Kan bara instämma i detta. Vid riktigt komplexa projekt kan det antagligen vara en fördel att bryta ner det till flera mindre delleveranser enligt den agila metoden. Efter varje delleverans så är det nog lättare att få en klarare bild av hur slutresultatet kommer bli och man kan då också lättare planera för nästa delleverans. Dessutom tror jag att det är psykologiskt riktigt att dela upp ett långt och komplext projekt i flera väl avgränsade delleveranser, på så sätt får man något mer greppbart att fokusera på.
Men jag ser också att det finns tillfällen då den agila metoden inte är lämplig, exempelvis då man i ett projekt är beroende av fysiska ting som är svåra att förändra. Inom IT-branschen kan detta till exempel röra sig som hårdvara. Att förändra hårdvaran i efterhand kan bli mycket dyrbart och det är därför oklokt att inte ha en mycket detaljerad kravspecifikation redan från början. Samma sak gäller givetvis även utanför IT-branschen, inom byggbranschen kan man knappast starta projekt utan att från början ha en detaljerad kravspecifikation. Dels för att kunna göra hållfastighetsberäkningar och liknande men även för att det är alltför kostsamt att införa förändringar i efterhand. Här kan man alltså inte planera en delleverans i taget utan måste planera alla leverans i detalj redan från början.
Gustavsson tar även upp detta med fasta kontrakt, fasta deadlines med spikade leveranser och offentliga upphandlingar och påpekar att vid dessa tillfällen är den agila metoden inte lika effektiv. Vid alla dessa tillfällen saknas förutsättningar för den flexibilitet och rörlighet som den agila metoden bygger på. Den agila metoden bygger ju på att man sätter upp ett datum för leverans och visar det sig att man inte kan hålla detta så är det innehållet i leveransen man förändrar och inte deadlinen eller resursutnyttjandet. Har man en fast deadline och spikat leveransinnehåll så är det enda man kan förändra resursutnyttjandet, något som inte är förenligt med den agila metoden. Vid offentliga upphandlingar är situationen liknande eftersom den färdiga lösningen då alltid är detaljerat beskriven redan från början. (Gustavsson, 2007, sid 16-17)
Referenser
Gustavsson, Tomas. 2007. Agile – konsten att slutföra projekt. Karlstad: TUK Förlag AB.Guzmán, Rebecka. 2012. Systemutvecklaren har blivit social. IDG. Elektronisk. http://www.idg.se/2.1085/1.469067. Läst 2012-10-08.
Schwaber, Ken & Sutherland, Jeff mfl. 2001. Manifest för Agil systemutveckling. Elektronisk. http://agilemanifesto.org/iso/sv/. Läst 2012-10-09.
Tonnquist, Bo. 2007. Projektledning. Stockholm: Bonnier Utbildning.
fredag 12 oktober 2012
Den nakne ambassadören - Grym debutdeckare!
I Magnus Zaars debutdeckare Den nakne ambassadören får vi följa den unga diplomaten Clara Fabre på äventyr i Östkongo. Hon skickas dit för att ta reda på vart den svenska ambassadören tagit vägen, denna har nämligen försvunnit. Detta är upptakten på en berättelse som sedan kommer att kretsa kring korrupta politiker, militärer och ambassadtjänstemän. Och mitt i detta finns alltså den unga Clara Fabre som trots att hon ständigt blir motarbetad inte ger upp, hon bara ska lösa detta och ställa de skyldiga till svars!
Förutom att det är en deckare med hög spänningsnivå så är det även ett kritiskt inlägg i debatten om hur vi använder våra biståndspengar. Vilken typ av bistånd ska vi ge? Och hur ska vi minska den korruption som finns? Är det rätt att ge bistånd till militärdiktaturer? Författaren ger kanske inga svar på dessa frågor men han får läsaren att fundera kring detta.
Detta är en mycket bra debutdeckare som håller ett högt tempo och som har ett persongalleri som är intressant. Jag ser fram emot nästa del i serien om Clara Fabre!......
Förutom att det är en deckare med hög spänningsnivå så är det även ett kritiskt inlägg i debatten om hur vi använder våra biståndspengar. Vilken typ av bistånd ska vi ge? Och hur ska vi minska den korruption som finns? Är det rätt att ge bistånd till militärdiktaturer? Författaren ger kanske inga svar på dessa frågor men han får läsaren att fundera kring detta.
Detta är en mycket bra debutdeckare som håller ett högt tempo och som har ett persongalleri som är intressant. Jag ser fram emot nästa del i serien om Clara Fabre!......
onsdag 10 oktober 2012
Projektledning - analys av magisteruppsatsen ”Att skapa en uthållig projektverksamhet - en studie ur ett HRM-perspektiv om stresshantering i projektintensiva organisationer”
Inledning
I den här rapporten kommer jag att analysera Helen Bäckströms och Lisa Janssons magisteruppsats ”Att skapa en uthållig projektverksamhet - en studie ur ett HRM-perspektiv om stresshantering i projektintensiva organisationer”. Uppsatsen är skriven vid Linköpings Universitet och finns att hämta elektroniskt på http://www.diva-portal.org/smash/record.jsf?searchId=2&pid=diva2:21593. Att jag valt att analysera just denna uppsats beror på att den belyser ett mycket aktuellt ämne, nämligen stress och stressrelaterade besvär och sjukdomar. Och då ett projekt definitionsmässigt är begränsat i tiden, det vill säga det finns alltid en tid att hålla, så kan man anta att detta kan leda till stress, något som man som projektledare givetvis måste ha kunskap kring.Jag börjar med att sammanfatta uppsatsens resultat och titta på hur resultatet kan användas rent praktiskt i projektarbetet. Jag går sedan över till att peka på uppsatsens styrkor och svagheter samt hur dess resultat förhåller sig till kurslitteraturen. Rapporten avslutas med mina egna reflektioner samt en referenslista.
Sammanfattning av uppsatsens slutsatser
Uppsatsens syfta är alltså att ”ur ett HRM-perspektiv, och med fokus på stress, analysera vilka faktorer som är viktiga för att skapa en uthållig projektverksamhet i projektintensiva organisationer”. (Bäckström & Jansson, 2006, sid 107) Man har valt en kvalitativ ansats, det vill säga man går på djupet snarare än på bredden, och man gör detta genom dels litteraturstudier och dels genom att intervjua ett tiotal personer från två projektorienterade företag. Då man har ett ledningsperspektiv på stresshanteringen så intervjuar man personer i ledande befattningar samt personer från företagshälsovården.Författarna huvudslutsats summerar de som ”… att det inte bara förefaller vara viktigt vad som görs när det gäller att skapa uthållighet, utan även att något görs.” Med detta menar de att det självklart är viktigt vilka åtgärden man väljer att göra men att bara detta att man gör något över huvudtaget ger en positiv effekt. Att ledningens värderingar är den rätta och att de lyssnar på de anställda är enligt författarna avgörande för en uthållig projektorganisation. De anställda måste känna att de har ledningen stöd. (Bäckström & Jansson, 2006, sid 107)
Men givetvis är det också viktigt vad man gör, och författarna har genom sin analys kommit fram till ett antal olika faktorer som påverkar projektorganisationens uthållighet. De har grupperat faktorerna i de två grupperna projektverksamhetens organisering samt stresshanteringsåtgärder, se bild 1 nedan. Här ingår faktorerna god planering, situationsanpassat ledarskap, snabb feedback, tydliga prioriteringar, kontinuerlig & lättillgänglig information, effektiv kommunikation, stöttande ledning och markerande av gränser respektive beakta återhämtning, håll jämn & hög arbetsbelastning, identifiera & uppmärksamma individuella behov, sätt mål och bestäm önskvärt resultat, tillämpa förebyggande aktiviteter, uppmärksamma stressproblemet, skapa helhetssyn och struktur, ge erkänsla och uppskattning samt inse att alla har ett ansvar.
Bild 1. De faktorer som enligt författarna är viktiga för att skapa en uthållig projekt-verksamhet. (Bäckström & Jansson, 2006, sid 108)
Författarna motiverar i sin analys sedan kortfattat valet av påverkande faktorer och åtgärder, jag tar upp endast ett urval av faktorer här. God planering minskar enligt författarna projektdeltagarnas osäkerhet och bidrar till insyn och kontroll, något som leder till trygghet och därmed mindre stress. Att situationsanpassat ledarskap kan leda till en uthålligare projektorganisation motiveras med att den ledarstilen innebär att projektplanen kan förändras om förutsättningarna förändras. Snabb feedback från ledningen är viktigt då detta leder till ett ökat engagemang och en ökad glädje. Med tydliga prioriteringar avser här författarna den prioritering av resurser som ibland måste göras mellan linjen och projektet eller mellan olika projekt, om ledningen gör dessa prioriteringar på ett tydligt sätt minskar projektarbetarnas osäkerhet. (Bäckström & Jansson, 2006, sid 107-108)
När de gäller de stresshanteringsåtgärderna så anser författarna till exempel att det är viktigt att ledningen beaktar återhämtningen, något som kan ske till exempel genom tydligt inplanerade perioder. Detta är viktigt även om projektarbetarna utsätts för positiv stress, för positiv stress kan övergå till negativ stress om den pågår under alltför lång tid. Jämn och hög arbetsbelastning är viktigt då det ger projektarbetaren bättre kontroll och en upplevd positiv stress, vilket i sin tur leder till bättre effektivitet. De anser också att förebyggande stresshanteringsaktiviteter är viktigt då detta kan fånga upp dem som är i riskzonen på ett tidigt stadium. Den punkt som de utvecklar mest i sin slutsats är den som går ut på att alla har ett ansvar. Individen har ett ansvar för sin livssituation och för att ta till sig de stresshanteringsåtgärder som företaget erbjuder, projektgruppen har ett ansvar att identifiera problemen och sedan försöka åtgärda dessa och ledningen har ett ansvar för att företaget har rätt värderingar och kan erbjuda rätt stresshanterande åtgärder. (Bäckström & Jansson, 2006, sid 108-110)
Slutsatsernas praktiska användningsområden
Tyvärr är jag ganska skeptisk till att uppsatsen och dess slutsatser kommer att få någon praktisk betydelse. De slutsatser man drog är enligt mig redan något som får anses som etablerad kunskap. Jag har själv arbetat i projekt på två olika företag och alla de faktorer som de nämner i sin slutsats var sådant som man var väl medveten om. Problemet är enligt mig inte att man saknar kunskap om hur man bör driva projekt uthålligt utan hur man ska implementera den kunskapen i projekt-organisationen. Ett exempel på detta är det klassiska problemet med dålig informationshantering i projekt, något som tre av författarnas faktorer handlar om. Här hade jag gärna sett att de istället för att endast identifierat problemet även föreslagit konkreta på hur ledningen skulle kunnat agera för att förbättra. Ska ledningen satsa på utbildning? Är det kanske någon form av IT-stöd som behövs? Hur mycket tid bör en projektledare avsätta för informationshantering? Är det bästa kanske att i alla projekt ha en speciell person som endast ansvarar för informationshanteringen? Vilka av dessa, eller andra, åtgärder är mest effektiva ur stresstålighetssynpunkt? Hade uppsatsen haft det fokuset hade den praktiska nyttan varit oändligt mycket större.Jag kan dock se en viss nytta med uppsatsen ur ett läroperspektiv. Den är välskriven och pedagogisk och kan nog fungera mycket bra som litteratur på universitet eller för dem som ska arbeta i en projektorganisation för första gången.
Styrkor och svagheter
Jag anser att uppsatsens två stora svagheter är brist på generaliserbarhet och djup. Brist på generaliserbarhet därför att uppsatsen baseras på enligt mig alltför få studieobjekt, endast totalt tio intervjupersoner fördelat på två olika företag. Detta är visserligen en kvalitativ studie, till skillnad mot en kvantitativ, men jag tycker att även kvalitativ studie bör baseras på mer data. Författarna för själva ett resonemang kring detta och kommer fram till den något luddiga slutsatsen att ”…det är möjligt att våra resultat även skulle kunna vara tillämpbara i organisationer där de rådande förhållandena är liknande dem som studiesubjekten verkar i.” (Bäckström & Jansson, 2006, sid 9) Detta går ju inte att tolka på annat sätt än att de även själva är ganska tveksamma till att deras slutsatser går att använda ens på liknande företag, för att då inte tala om företag som verkar i andra branscher och/eller är av en annan storlek.Det kanske kan verka motsägelsefullt att jag anser att uppsatsen brister i både generaliserbarhet och djup, man kan tycka att om den inte är generaliserbar så borde den ju i så fall vara djup. Men tyvärr anser jag inte att den varken är det ena eller det andra, det vill säga den är varken kvantitativ eller kvalitativ. Jag tycker den brister i djup då intervjuerna känns mycket ytliga, och detta trots att intervjuobjekten är få. De skriver själva att den tid de fick med varje person var en eller maximalt två timmar, och detta inkluderar då även presentation av sig själva och uppsatsens syfte. Själva intervjun var alltså i vissa fall under en timme vilket jag anser är alldeles för kort för att man ska få en verkligt djup förståelse. Antalet intervjufrågor var också på tok för många, uppemot 30 stycken, för den begränsade intervjutiden. (Bäckström & Jansson, 2006, sid 117-124) Jag tror uppsatsen hade blivit bättre om de hade avgränsat ämnet mer. Kanske att de kunde fokuserat endast på en liten del av projektverksamheten, till exempel tid och resursplanering eller ledningens värderingar, och gått djupare in på hur just den delen påverkar projektuthålligheten.
Sedan kan jag tycka att det var lite synd att man endast intervjuade personer i ledande befattningar samt inom företagshälsovården, det vill säga inte någon som arbetat i ett projekt under projektledaren. Detta klargörs ju i och för sig redan i och med uppsatsens titel men jag kan ändå tycka att utelämnandet av projektmedarbetarna gör att uppsatsen inte känns komplett. Kanske utelämnandet av dessa ger en missvisande och eventuellt förskönad bild av verkligheten? (Bäckström & Jansson, 2006, sid 16-17)
Slutligen hade jag gärna sett att de på något sätt verifierat de slutsatser de kom fram till. Som uppsatsen är nu beskriver de hur de två företagen arbetar med stressrelaterade frågor men man får egentligen ingen uppfattning om vilka reella effekter arbetet fått. Effekterna beskrivs endast av intervjuobjekten, som ju är mycket partiska. Jag inser att de vore ett mycket stort och tidsödande arbete att verifiera uppsatsens slutsatser men jag tycker ändå att man borde försökt, i alla fall för någon del av de delslutsatser man kom fram till. Hade man inte möjlighet att själv göra det experimentellt så kanske man kunde gjort det genom att studera befintlig statistik och liknande.
Men för att säga något positivt så gillar jag uppsatsens upplägg rent pedagogiskt. Författarna beskriver mycket bra hur de gått till väga och man får också en bra genomgång av vad projekt och stress är. Uppsatsen fungerar alltså mycket bra för den som vill förstå vad stress och projekt är för något samt hur dessa förhåller sig till varandra. Jag uppfattar författarna som kunniga inom dessa två områden.
Uppsatsens slutsatser i förhållande till litteraturen
Varken Bo Tonnquists eller Tomas Gustavssons har fokus på stressrelaterade frågor. Ingen av böckerna har ett avsnitt eller kapitel som handlar om stress, stress finns inte heller med i böckernas innehållsförteckningar eller ordlistor. Faktum är att jag inte har sett ordet stress nämnas en enda gång i de delar av böckerna som jag läst. Med tanke på hur uppmärksammat stress och utbrändhet har blivit på sistone så tycker jag att det är konstigt att de Tonnquist och Gustavsson inte lägger större vikt vid detta. Läser man Bäckström och Janssons uppsatts så inser man ju att stresshantering är av avsevärd vikt för att projekt ska kunna drivas på ett bra sätt, något givetvis även Tonnquist och Gustavsson måste vara medvetna om.Men även om de inte specifikt tar upp stress och stresshantering så finns många av uppsatsens slutsatser med i deras böcker, dock inte ur ett stresshanteringsperspektiv utan mer ur perspektivet effektiv projektledning. Om man jämför de faktorer för projektetverksamhetens organisering som uppsatsförfattarna nämner i sin slutsats, se bild 1, med Tonnquists och Gustavssons böcker så finns det stora likheter. Till exempel tillägnar de varsitt helt kapitel åt det som uppsatsförfattarna kallar för ”god planering”. (Gustavsson, 2007, sid 103 – 138 & Tonnquist, 2007, sid 115 - 148) Och när det gäller vikten av situationsanpassat ledarskap så skriver Gustavsson en hel del om detta och även den Agila metod som Tonnquis skriver om bygger på anpassningsbarhet. (Gustavsson, 2007, sid 222 - 224 & Tonnquist, 2007, sid 22) På samma sätt kan man se att även de andra faktorerna under det som uppsatsförfattarna kallar för projektverksamhetens organisering finns med i böckerna. Men, och det är ett stort men, i böckerna finns inte alls kopplingen till stress och stresshantering.
Och går man över till det som uppsatsförfattarna kallar för stresshanteringsåtgärder, se bild 1, så finns dessa knappt alls med i böckerna. Jag har inte hittat något i böckerna om till exempel förebyggande åtgärder, uppmärksammande av stressproblematiken eller beaktande av återhämtning. Så min slutsats blir att Gustavssons och Tonnquists i sina böcker inte alls tar upp den frågeställning som behandlas av Bäckström och Jansson. Gustavsson och Tonnquist berör visserligen en del av de faktorer som nämns i uppsatsens slutsats men de gör det inte ur ett stresshanteringsperspektiv. Det vill säga, om du är ny inom området projektledning och läser Gustavssons och Tonnquists böcker så kommer du att lära dig hur man driver projekt på ett bra sätt men du kommer inte att ha någon förståelse för vilka faktorer som påverkar förekomsten av negativ stress samt hur du kan hantera detta.
Reflektioner
Jag har ju varit rätt så kritisk mot uppsatsen och dess slutsatser men samtidigt så inser jag att det inte är ett helt lätt ämne att studera. För att komma fram till några konkreta och bevisade slutsatser så krävs det antagligen ett enormt arbete då jag antar att man måste studera en stor mängd projekt och projektarbetare under en lång tid. Det räcker då inte med endast en eller två korta intervjuer utan det krävs nog att man följer dessa personer under lång tid, kanske många år, för att se hur deras stressnivå förändras i förhållande till deras arbetsbörda i projekten. Dessutom bör man nog ha en kontrollgrupp bestående av personer som inte arbetar i projekt. Ska man sedan jämföra effekten av många olika stresshanterande åtgärder så blir ju omfattningen enorm. Jag har full förståelse för att Bäckström och Jansson inte hade möjligheten att göra ett så pass omfattande arbete.Kan personligen reflektera över att författarna, och deras intervjuobjekt, inte går in på detta med att alla personer inte är skapta för att arbeta 40 timmar i veckan i projekt. För mig är det självklart att eftersom vi alla är unika så har vi också olika arbetskapacitet, jag hade därför gärna sett att de tagit upp detta med hur man skapar en projektorganisation som är anpassad även för dem som arbetar deltid. För om man håller benhårt på att alla ska arbeta lika många timmar per vecka så kommer man enligt mig aldrig att få en arbetsplats som är befriad från negativ stress. Vissa vill och kan arbeta i projekt 40 timmar medan det finns dem som är anpassade för att arbeta fler eller färre timmar. Detta kanske inte är en frågeställning som är specifik för just projekt som arbetsform men jag tror den är än mer aktuell för projekt då man här har större tidspress och en mer varierad arbetsbelastning än i linjen.
Jag har ju tidigare kritiserat uppsatsen för att jag inte tycker att den tillför någon nytt utan att den mest bekräftar vad som enligt mig är gammal kunskap. Men detta betyder inte att jag inte lärt mig något då jag läst uppsatsen. Till exempel poängterade författarna vikten av att man inom projektgruppen identifierade stressrelaterade problem och sedan tillsammans försökte åtgärda dessa. Detta visste jag väl i och för sig sedan tidigare men så här i efterhand kan jag se att de projekt jag arbetat i inte haft tillräckligt fokus på detta. När projekten väl rullar så ägnade jag i ärlighetens namn inte mycket tanke åt att se hur de andra projektmedlemmarna hanterade eventuell stress, och stress kom sällan eller aldrig upp som en punkt på projektmöten eller liknande. Detta är nog något jag kommer att tänka mer på nästa gång jag arbetar i projekt.
Författarna poängterar också gång på gång detta med vikten av positiv stress och att denna leder till ett effektivt arbete och gladare projektarbetare. Även här är det så att jag känt till att positiv stress är något bra, det hörs ju om inte annat på namnet, men jag har inte riktigt förstått hur pass viktigt detta är och att det är något som projektledare verkligen ska sträva efter att uppnå i sina projekt. I alla fall enligt uppsatsförfattarna. De nämner också vikten av att man även vid positiv stress får viloperioder, annars kan stressen övergå till att bli negativ. Kan inte undgå att tycka att detta fokus på positiv stress är lite som att leka med elden, detta då jag personligen tror att positiv stress är inkörsporten till negativ stress. Och jag tror också att det är mycket svårt för både en själv och för någon annan att avgöra när den positiva stressen håller på att övergå i negativ stress, det vill säga jag tror det är mycket lätt hänt att man inte inser att man är utsatt för negativ stress förens det är för sent. Och om jag förstått det hela rätt kan det vara mycket mödosamt och tidskrävande att komma tillbaka från utbrändhet. Så därför tycker jag denna positiva inställning till positiv stress är lite farlig, kanske hade det varit bättre och fokusera på att skapa en projektorganisation helt utan vare sig positiv eller negativ stress?
Referenser
Bäckström, Helene & Jansson, Lisa. 2006. Att skapa en uthållig projektverksamhet - en studie ur ett HRM-perspektiv om stresshantering i projektintensiva organisationer. Linköpings Universitet. http://www.diva-portal.org/smash/record.jsf?searchId=2&pid=diva2:21593.Gustavsson, Tomas. 2007. Agile – konsten att slutföra projekt. Karlstad: TUK Förlag AB.
Tonnquist, Bo. 2007. Projektledning. Stockholm: Bonnier Utbildning.
Prenumerera på:
Inlägg (Atom)