Mickes skolblogg: Examinationsuppgift 1 PPB300

Då det dokument/skrift som dessa svar bygger på är sådant att det öppnar för egna tolkningar och antaganden så är risken stor att det som examinator bedömer som ska vara svar under fråga 1 kanske hamnar under fråga 2 istället och tvärtom. Det finns också en risk för att vissa saker kommer att tas upp under två eller flera av frågorna Jag hoppas dock att de slutsatser som jag kommer fram till ändå är de viktigaste att ta hänsyn till. För att försöka påvisa en förståelse för projektarbete och hur det ska hanteras så kommer jag att under fråga 4 ta mig friheten att i korthet beskriva hur jag hade hanterat situationen, eller rättare sagt hur jag ser att man kunde ha agerat annorlunda från början till slut.

Uppgifter

Vad var det som gick fel med projektet?

Ja, vad var det som inte gick fel? Undermålig planering, dålig förankring i projektgruppen samt en projektledare som inte alls tycktes veta hur ett projekt ska byggas upp för att ha en verkligt god chans att lyckas. För det första verkar det som att man i inledningsskedet inte alls tagit reda på alla krav som kunden egentligen har. Visserligen står det att man har regelbundna "möten” samt att man ”håller på att ta fram ett dokument som klart och tydligt beskriver behov och krav på webbplatsen”. Och det är väl jättebra. Men tog man reda på i vilken miljö systemet, eller webbplatsen, skulle verka i? Vilka andra system skulle den vara kompatibel med? Det tycks som att denna fråga helt glömdes av när direktivet förhandlades fram, så vida det dokument som omnämns verkligen ska ses som ett direktiv. Att ta fram en kravspecifikation bör ske i samråd med beställaren[1]. Denna specifikation bör innehålla alla tänkbara, (och otänkbara) krav som beställaren har på systemet. Är svårt att avgöra sådana saker utan att ha tillgång till den dokumentation som ändå togs fram. Ett direktiv ska kunna användas för att just undvika många av de problem som detta projekt drabbades av. Det ska vara vägledande i beslutssituationer, entydigt, realistiskt, utredningsverkställigt, informativt och problemorienterat[2].

Projektgruppens sammansättning, var den genomtänkt? Hade man de kompetenser man behövde för att genomföra projektet[3]? Uppenbarligen inte. Vissa delar i specifikationen ändrades utifrån kompetensen på företaget, om jag tolkar det hela rätt. Istället borde man redan från början, efter att direktivet var framtaget, och projektplanen och kravspecifikationen arbetades fram ha sett över vilka kompetenser som behövdes, vilka som fanns att tillgå i företaget och vilka som man kanske behövde anlita externt[4]. Men detta tycktes aldrig vara aktuellt.

Designgruppen, ingick den i projektgruppen? Eller var det en fristående grupp? Var det en fristående grupp så vill det till ännu mer av planering[5], kommunikation och möten av alla de slag för att man ska dra åt samma håll. Risken för missförstånd är annars mycket stor, om olika grupper arbetar med olika saker i projektet, utan att förstå hur just deras del passar in i det stora hela. Just att känna en slags grupptillhörighet, en vi - känsla, utan att för den skull helt isolera sig från omvärlden, kan vara A och O för ett lyckat projekt[6].

Visserligen kan det i olika situationer krävas att projektledaren går in och styr upp arbetet samt fattar avgörande beslut för att inte projektet ska köra fast[7],[8]. Men i detta fall tycks Maja ha haft alltför bråttom att dra igång projektet. Då det var så pass stor oenighet om vilket system som skulle passa att projektera, så borde man ha löst det på annat sätt än att låta projektledaren fatta detta beslut ensam. Visserligen så kanske systemet verkligen var det enda rätta, men då skulle Maja ha sett till att förankra detta i hela projektgruppen, med kunden samt med en styrgrupp av något slag, något som tycks saknas[9],[10].

Att börja tidsplanera ett projekt innan man egentligen vet vilka delar som kommer att ingå i projektet är också mycket svårt. Dels för att det som sagt i det läge som Maja planerade tiden inte var helt klarlagt hur projektet skulle utformas i dess helhet, dels så måste Maja besitta en mycket bred kunskap för att kunna bedöma hur lång tid olika delar i projektet tar. De som bäst lämpar sig att avgöra detta är ju de som besitter kompetensen. Å dessa fick ju aldrig i detta läge säga sitt. Dock ska projektledaren eller styrgruppen göra mycket grova uppskattningar av projektets tidsåtgång och ekonomiska kostnader i ett tidigt skede tillsammans med kunden, helst i samband med att direktivet arbetas fram[11],[12]. Då får alla parter klart för sig vad som gäller och om det går att i ett senare skede justera någon av de poster som ingår i den så kallade åtagandetriangeln[13].

Ytterligare ett problem var att kravspecifikationen tycks vara otillfredsställande utförd. Det fanns visst en kravspecifikation, men man borde ha insett redan vid förhandlingarna med kunden samt framtagandet av direktivet att vissa krav skulle bli svåra att tillmötesgå. Och en lösning borde ha förhandlats fram mellan kund, styrgrupp och projektledare/projektgrupp[14]. Istället så gick man in i efterhand å ändrade i specifikationen, utan att, som det verkar, förankra detta med kunden.

Att Maja sen beslutar sig för att dra igång vissa delar av projektet ”bara” för att tidsplanen säger så, är också ett stort misstag. Är inte allt klarlagt om vad och på vilket sätt man ska koda, så är risken överhängande att slutresultatet inte alls blir det förväntade. Vilket får till följd, precis som beskrivs i texten, att vissa delar måste göras om och tidsplanen spricker ordentligt. Man borde istället ha samlat gruppen å planerat om projektet i dess helhet, och fått detta förankrat hos styrgrupp och kund[15],[16].

Vilka misstag gjorde man inledningsvis i projektet?

Ett flertal misstag begicks. Visserligen togs ett dokument fram i början, vilket kanske var ett projektdirektiv[17],[18], men som jag tolkar det så fanns det i detta direktiv ett antal brister som inte borde ha funnits där. Kravspecifikationen[19] var inte tillfredsställande gjord, det vill säga man hade inte utrett alla krav som beställaren hade på systemet, så att detta kunde vara kompatibelt med de redan befintliga systemen. Direktivet innehöll förmodligen också brister. Var det helt klarlagt exakt vad man skulle projektera, och vad man inte skulle bry sig om? Hade man tagit fram riktlinjer för beslutsprocessen? Fanns det klara riktlinjer för avrapportering mot kund samt, om detta fanns, vilket inte framgår, mot styrgruppen[20]?

Att projektledaren själv beslutade om vilket system som bäst skulle passa kunden är också ett misstag. Att börja planera projektets tidplan innan man egentligen vet vilka olika delar som ingår funkar heller inte. Att på eget bevåg, visserligen med hjälp av några medarbetar, ta fram stolpar och annat som man sedan kastar i ansiktet på de andra medarbetarna i projektet, är en mycket dålig väg att gå. När man så påpekar de briser som man anser finns, så tycks det inte som att Maja lyssnar på kritiken, utan kör bara på, med en förklaring om att det kommer i ett senare skede att utarbetas mer precisa planer. Men om man redan från början talat om hur man ser på problemet för den övriga gruppen, då är risken väldigt stor att man låser fast sig vid detta, och det blir mycket svårt att ändra riktning på skutan. Vad som borde ha skett inledningsvis, och som hade avhjälpt mycket av de problem som senare dök upp, hade varit en väl genomtänkt projektplanering, helst då med hela projektgruppen inblandad. Hade man fått till stånd denna med övergripande fas - indelning, en grov tids - uppskattning samt viss annan planering samtidigt som man arbetade fram kravspecifikationen så hade kanske projektet slutat på ett annat sätt. Visserligen så fick en grupp designers i uppdrag att utforma den detaljerade designen samt planen. Men designen skulle ha kommit senare, efter projektplaneringen[21],[22].

Hur kunde problemen kvarstå utan åtgärd under så lång tid?

På grund av att ingen egentligen hade riktig klart för sig vad projektet skulle leda till, samt att man i projektgruppen hade oklara roller[23]. Detta ledde i sin tur till irritation och osämja inom gruppen, något som projektledaren borde ha åtgärdat med en gång när detta uppstod[24],[25]. Men då hennes ledarstil var av den auktoritära sorten, hon bestämde saker på egen hand mm, istället för att diskutera fram lösningar med övriga medlemmar, så kunde hon inte heller medla i alla dessa konflikter, utan fattade besluten själv[26]. Det tycks heller inte ha skett någon avrapportering vare sig mot kund eller mot något slags styrgrupp/ledningsgrupp, utan projektet har levt sitt egna liv inom företaget, vilket lett till att ingen utanför projektgruppen ifrågasatt projektet[27]. Och som jag tidigare nämnt så tycktes det saknas dokument som klart och tydligt beskrev projektets mål och olika faser. Allt gick på lösa boliner, och problemen löstes när de dök upp istället för att man försökte, till exempel med en riskanalys, analysera vilka olika risker som fanns i projektet och om dessa uppstod, klart och tydligt definiera hur de skulle lösas och vem som i så fall skulle fatta de avgörande besluten[28]

Ev. andra egna reflektioner.

Jag väljer under denna punkt, med risk för att upprepa mig en del, att beskriva i all korthet hur jag som projektledare hade valt att hantera detta uppdrag, i alla fall i teorin. Sen är det ju tyvärr så att teori och verklighet sällan stämmer överens.

Förhoppningsvis hade jag som projektledare fått vara med vid förhandlingar med uppdragsgivare. Jag hade då tillsett att ett direktiv som klart och tydligt ringade in det som projektet skulle arbeta med hade tagits fram. Samtidigt som detta direktiv förhandlades fram hade jag sett till att det parallellt tagits fram en kravspecifikation, som beskrev alla de krav som fanns på systemet, designmässigt, funktionsmässigt samt kompabilitetsmässigt, för att undvika liknande problem som beskrivs i texten. I direktivet hade det också klart framgått vilka grova ramar som fanns att följa tidsmässigt, och ekonomiskt, samt hur avvikelser av de samma skulle hanteras. Likaså hade direktivet behandlat hur avrapportering mot kund eller styrgrupp skulle ske, på vilket vis och vid vilket tidsintervall. Likaså hade en riskanalys på övriga risker som kan inträffa i projektet framtagits och genomarbetats så att så få oklarheter som möjligt funnits om hur dessa problem skulle hanteras om de uppstår[29].

Efter direktivet hade jag sedan funderat på, helst tillsammans i dialog med styrgruppen, vilka kompetenser som ansågs behövas, vilken sammansättning av projektgruppen som ansågs vara mest lämplig för slutmålet mm. Efter att ”kontraktering” skett av dessa personer, hade så nästa steg varit att samla alla för ett planeringsmöte, eller en ”brainstorming” där alla fritt fått säga sin menig om hur man anser att projektet bäst utförs mm. Som ledare hade jag försökt att få alla att prata och känna sig delaktiga och behövda. Att försöka få alla i gruppen att inse målet, och att hitta en gemensam väg dit, är mycket vikigt för att ett projekt ska lyckas. När projektgruppen ”pratat sig samman” så blir nästa del att ta fram en övergripande planering av projektet[30].

Detaljplanringen hade jag väntat lite med, för att genomföra denna vid någon träff där gruppen inte bara samlas för att planera utan även för att lära känna varandra bättre. Dock hade jag vid detta tillfälle sett till att en detaljplan hade tagits fram, som visar på resursfördelning, ansvar och tidsplanering ner i minsta detalj, eller i alla fall så långt det anses vara möjligt[31].

Täta uppföljningar, rapporteringsmöten om projektets fortskridande, både för projektgruppen, men även för styrgrupp/uppdragsgivare, hade jag sett som en självklar del i min uppgift som projektledare[32].

Om problem liknande de beskrivna hade uppstått, hade jag som ledare beslutat mig för att samla gruppen, styrgruppen och uppdragsgivaren för att vi gemensamt skulle kunna komma fram till en lösning som var godtagbar för alla.

Det som inte framkommer i texten, en som är väldigt viktigt, särskilt när det gått åt skogen, är om det skedde någon form av utvärdering av projektarbetet efter det att projektet var avslutat. På en sådan utvärdering kan man lära sig mycket, både själva projektgruppen men också ledningen för företaget. Tyvärr glöms detta bort alltför ofta[33].

Avslutande kommentar

Det som jag beskriver ovan, både svaren i fråga 1-3 amt min lilla beskrivning i fråga 4, är bara ett sätt att se på det. Man kan naturligtvis tolka in massor i en text som den vi utgått från, vilket då naturligtvis leder till olika svar. Men som jag inleder med att skriva, så hopas jag att det som kommer fram ovan är tillräckligt för att påvisa de kunskaper jag har inom området.

Källförteckning

Eklund, Sven (2002). Arbeta i projekt – en introduktion. Upplaga 1:9 Studentlitteratur.

Lindholm, Börje. Wisen Jan. (2004). Effektivt projektarbete. Sjunde upplagan. Nordstedts Juridik AB

[1] Eklund Sven (2002) sidor 55-57

[2] Lindholm, Börje och Wisen, Jan (2004) sidor 50-51

[3] Lindholm, Börje och Wisen, Jan (2004) sidor 100-102

[4] Lindholm, Börje och Wisen, Jan (2004) sidor 111-112

[5] Eklund Sven (2002) sidor 35-38

[6] Lindholm, Börje och Wisen, Jan (2004) sidor 133-134, 153-155

[7] Lindholm, Börje och Wisen, Jan (2004) sidor 106-107

[8] Eklund Sven (2002) sida 38

[9] Eklund Sven (2002) sida 35-36, 66-67, 68

[10] Lindholm, Börje och Wisen, Jan (2004) sidor 133-134

[11] Lindholm, Börje och Wisen, Jan (2004) sida 51

[12] Eklund Sven (2002) sidor 57-59

[13] Eklund Sven (2002) sida 53

[14] Eklund Sven (2002) sidor 55-57

[15] Eklund Sven (2002) sidor 83-84

[16] Lindholm, Börje och Wisen, Jan (2004) sidor 155-157

[17] Lindholm, Börje och Wisen, Jan (2004) sidor 50-59

[18] Eklund Sven (2002) sidor 51-61

[19] Eklund Sven (2002) sidor 53-57

[20] Lindholm, Börje och Wisen, Jan (2004) sidor 56-58

[21] Lindholm, Börje och Wisen, Jan (2004) sidor 133-140

[22] Eklund Sven (2002) sidor 63-72

[23] Eklund Sven (2002) sidor 20-23

[24] Eklund Sven (2002) sidor 26-28, 32-33

[25] Lindholm, Börje och Wisen, Jan (2004) sidor 98-100, 106-108

[26] Eklund Sven (2002) sida 40

[27] Lindholm, Börje och Wisen, Jan (2004) sidor 97-98

[28] Lindholm, Börje och Wisen, Jan (2004) sidor 60-64

[29] Lindholm, Börje och Wisen, Jan (2004) sidor 50-64

[30] Eklund Sven (2002) sidor 63-7

[31] Eklund Sven (2002) sidor 73-84

[32] Eklund Sven (2002) sidor 85-87

[33] Lindholm, Börje och Wisen, Jan (2004) sidor 163-168

//Micke Lidköping vid Vänern