Per: Dokumentationens betydelse i systemutvecklingsprojekt

Dokumentation över vad man gör är väldigt viktigt och i synnerhet när det gäller systemutveckling där man kan se och följa själva utvecklingen av systemet.
Det är viktigt för att se att man håller den ”utritade linjen” för projektet.
Med riktigt utförd dokumentation så kan man se/analysera sig fram till vart någonstans ett projekt börjar gå snett(om det går snett alls) och man har då en möjlighet att i detalj se vad som orsakat problemet. Det finns även en möjlighet att man kanske måste göra om vissa delar som inte gett de önskade slutresultaten. Då har man om man har en god dokumentation lättare att urskilja exakt vart och vad som behövs ändras på/göras om. Man kan infoga nya delar till ett befintligt projekt på ett enklare sätt i och med att dokumentationen förhoppningsvis även talar om hur man försökt tänkt med olika beslut, hur de är uppbyggda.
Dokumentationen är även viktig när det gäller projektmedlemmarnas insyn i det egna projektet, det gör det lättare för personer som deltar i projektet att hålla sig uppdaterad och om personer blir sjuka/är lediga en längre tid även en möjlighet att ”komma ikapp”, hålla sig ajour med projektet.
Dokumentation är även viktig för framtida projekt. Det är en viktig del av vad man lärde sig och vilka fel man gjorde så man inte gör om samma misstag igen och kan göra de ”bra” sakerna ännu en gång, återanvända bra och fungerande lösningar på problem som kan komma att dyka upp igen.
En till sak som är viktig med dokumentation är att den kan/bör användas som lagligt dokument. Exempelvis projektdirektivet där man talar om vad man ska göra och inte göra i ett projekt och hur det skall göras skall skrivas under av både utföraren och uppdragsgivaren vilket gör att det är blir ett lagligt dokument. Där kan man se från bådas(uppdragsgivaren och utföraren) se vilka skyldigheter och förpliktelser som parterna har men även vad de kan kräva av motparten.
Det är om det finns tydliga mål och krav i projektdirektivet lätt att när projektet är klart se om man uppfyllt de kraven och målen som var ställda.
Där kommer slutrapporten in, ett dokument som fastställer vad som gjorts i projektet, hur det gjorts och vilka resultat det givet men även vilka problem som uppstått.
Slutrapporten bör man även skriva under av båda parter för att slippa framtida problem/stämmningar osv.. Det ger även uppdragsgivaren den skyldigheten och möjligheten att läsa igenom och sätta sig in i projektet och därmed förhoppningsvis komma med eventuella frågor och sista kompletteringar i detta skede(beroende på tidigare överenskommelser). Allt för att båda parter ska bli nöjda och projektet skall få ett godkänt slutresultat av alla berörda parter och att man kan ha fler samarbeten.
En sak som icke är att förglömma är dokumenteringen av tidsrapporteringen i projektet, det är en väldigt viktig bit för att uppdragsgivaren ska se exakt hur mycket tid som faktiskt använts i projektet. Men det är även viktigt för projektgruppen/ledningen att se hur många timmar olika personer lagt ner på projektet för att skapa sig förståelse om framtida projekt behöver struktureras på ett annorlunda sätt när det gäller kompetenser och tidsplanering.

/per

Dokumentationens roll i systemutvecklingsprojekt

Dokumenation är viktigt i ett projekt för att kunna gå tillbaka och kolla om det skulle uppstå tveksamheter. Vissa dokument är viktigt att de är undertecknade av projektgrupp och uppdragsgivare eftersom de är lagliga dokument som kan få påföljder om de skulle brytas. Andra anledningar till att dokumentationen är viktig är att man undviker att glömma bort saker som sagts under arbetets gång, saker som kan ha stor betydels framöver men kanske inte just vid tillfället som de tas upp. Alla i projektgruppen har lättare att hänga med i de olika turer som projektet kan ha under sin uppbyggnad. Det kan även finnas tillfälle då någon inte har haft möjlighet att delta i något av mötena, denna person kan då enkelt bli ajour med vad som togs upp genom att läsa dokumentationen. I dokumentationen kan man även gå tillbaka och kolla att man fått med allt i systemet som det var sagt att uppdragsgivaren ville ha, men man kan även där skriva in eventuella begränsningar. Man kan i dessa dokument även följa arbetets gång, hur systemet har utvecklats, eventuella problem som man stött på och/eller löst och som man kan ha nytta av i kommande projekt. Dokumentationen är viktig för att kunna veta om man nått fram till något resultat. Har projektet blivit som det var tänkt eller var det nått som hände som gjorde att det inte blev så, varför blev det på ett visst sätt osv. Har man skrivit ner allt kan man gå tillbaka och analysera och kanske lista ut varför det inte blev som det var tänkt. Med andra ord är dokumentationen väldigt viktig!

//Annica

Case Lavasoft – Mårten

1. Vad var det som gick fel med projektet?
Så som jag uppfattade det så var det kaos redan i början av projektet. Ingen visste riktigt hur slutprodukten skulle bli. Projektledaren lovade att det skulle klarna framöver och mot slutet av projektet insåg de att de inte hade den rätta kompetensen för att utföra vissa saker som fanns på kravlistan. Detta skulle självklart framkommit i starten av projektet så de kunde diskutera fram en lösning, nu blev det istället kaosartat då det framkom så sent. Om de innan projektledaren bestämde sig för vilket system de skulle använda sig kunnat samlas och ge sina egna förslag och synpunkter på saker och ting hade det nog blivit bättre. Eftersom projektledaren skapade en plan utan sina medarbetares samtycke uppstod det mycket frågor som inte riktigt benades ut, alla förstod inte vad hon menade med sin plan. Jag kan även tänka mig att vissa medlemmar kände sig överkörda, de kanske hade bra idéer som de inte hann få fram eventuellt framföra på ett bra sätt innan det redan framtagits en plan. Att de heller inte tog reda på om systemet de skulle skapa fungerade tillsammans med företagets befintliga system är riktigt dåligt. Detta är något de skulle gjort redan i projektstarten för att undvika problem längre fram. Då de också omarbetar sin specifikation så långt in i projektet drar tiden iväg och projektledaren ber programmerarna dra igång sitt arbete innan de riktigt är på det klara med vad som ska göras. De inser att de måste göra om vissa delar i programmeringen och tiden drar iväg.
Hade de lagt mer fokus på starten i projektet och benat ut de frågor som fanns så hade mycket av dessa problem kunnat motverkas.

2. Vilka misstag gjorde man inledningsvis i projektet?
Det första problemet jag kan se med detta projekt är att projektmedlemmarna inte kan komma överens om vilket system de ska använda. Projektledaren tar då initiativet att själv bestämma och ber några projektmedlemmar skriva ner några viktiga stolpar samt skapa ett diagram. När hon sedan presenterar detta och ber projektgruppen ställa frågor så tycker ju flera att beskrivningen är alltför vag, de förstår helt enkelt inte. Projektledaren försäkrar sedan sina medarbetare att beskrivningen ska bli mer detaljerad framöver.

Enligt mig har man redan här låst fast sig. I början av ett projekt måste alla vara med på noterna och förstå vad som bestäms. Hur ska de kunna ställa frågor kring ett system de inte fattar? Oftast inom en projektgrupp har ju varje medlem olika specialiteter, vissa är bra på att koda, andra på design och så vidare. Om det då bestäms något som t.ex. inte kodaren förstår riktigt kan det uppstå problem längre fram, det kanske inte går programmera systemet på det sätt projektledaren hade tänkt sig. Eftersom inte alla var på det klara med hur de skulle utveckla systemet i början kunde man inte förutse problem som skulle komma framöver i den tekniska biten. Detsamma gäller också tidsplanen, programmeraren kanske inte kan hålla den tidsram som gäller för att bli klar i tid. Allt detta hade kunnat motverkas om projektledaren tagit sig tid att förklara för sin projektgrupp tills alla var med på noterna hur hon tänkt sig.

3. Hur kunde problemen kvarstå utan åtgärd under så lång tid?
Det jag kommer att tänka på är att de inte redan från början var överens om hur det skulle bli. Detta pga. Att den plan som projektledaren arbetat fram med några andra inte var tillräckligt detaljerad, många i gruppen förstod inte hur hon tänkt sig. Hon lovade sedan att de skulle klarna framöver då det skulle bli mer detaljerat. Denna detaljplanering borde varit klar i ett tidigare skede så eventuella brister i planeringen kunde framkomma. Projektledaren hade antagligen inte den kompetens själv att kunna veta om alla delar i systemet skulle gå att skapas på det sättet hon tänkt sig. Sedan rann ju projekttiden iväg och brister i kompetens och systemet de skapade kom inte fram förrän i slutskedet då det redan var försent att hålla sig inom tidsplanen.

4. Ev. andra egna reflektioner.
Detta projekt visar på det vi pratat och läst mycket om i denna kurs, nämligen att starten av projektet är det man bör lägga mest tid på. Tydligen hade inte Lavasoft insett detta. Hade dem jobbat fram ett ordentligt projektdirektiv från starten tror jag att de redan då kunde komma fram till att de inte hade den kompetensen som behövdes, att vissa delar av systemet inte skulle fungera med deras befintliga system osv.

Per: Case LavaSoft

1.Vad var det som gick fel med projektet?
1.Jag uppfattar det som att LavaSoft inte riktigt läst igenom/förstått vad kunden egentligen ville ha gjort eller i varje fall tolkat det fel från början när man skapade det dokument om kundens behov och krav(projektdirektivet). Detta för att det finns krav från kunden som man inte vet om kunskapen finns till att skapa inom företaget. Den insikten gör man sent i projektet och det borde naturligtvis ha framkommit redan från starten.
Det största felet som jag uppfattar att projektet hade var att dom inte tog sig tid och benade ut dom stora och viktiga frågorna redan från början(projektledarens roll att se till). Att man inte skapade ett projektdirektiv som var tillräckligt detaljerat med vad som ingår och vad som inte ingår vilka kunskaper som finns osv.. Det kanske var så att man var för liten grupp med för dålig kunskap för att ta beslut om vad och hur projektet skulle skötas. En uppenbar miss var att man inte kontrollerade att det systemet man valt passar in till dom andra delarna av kundens websystem, vilket får man förmoda var ett av kraven. Det borde naturligtvis projektledaren sett till att man gjort. Hon gjorde ännu ett fel när hon inte gick igenom beskrivningen tydligare med projektmedlemmarna så att alla förstod målen och vad som skulle göras och när. Om hon gjort så hade hon förmodligen fått påpekat för sig att hennes val av system inte skulle vara kompatibelt med kundens befintliga websystem eller åtminstone haft en möjlighet att korrigera det misstag som gjordes med projektdirektivet(kundens krav/behov) om kunskapen överhuvud funnits i projektgruppen.
Jag ser inte att det är ett fel att projektledaren tar beslut när projektgruppen är oense om en sak, som ex. vilket system man ska använda, men i det här fallet är det tydligt att projektledaren inte har haft tillräckligt med kunskap för att ta det beslutet och därför fattat fel beslut.
Alla dom sakerna gjorde att projektet inte höll sin deadline och därmed förlorade möjligheten till fler uppdrag från kunden.

2.Vilka misstag gjorde man inledningsvis i projektet?
2.Det man spontant kan tycka är att den som skapat projektgruppen inte gjort ett bra jobb med projektmedlemmarna. Projektledaren gör några stora fel det första som händer(om det bara är ett dåligt beslut eller okunskap framgår inte), och resten av medlemmarna kanske inte har den sammanlagda kompetensen som behövs för just det här projektet.
Det är som jag skrev i förra frågan att man inte skapade ett bra projektdirektiv med tydliga och klara direktiv vad som var kundens behov och krav samt att kontrollera att man hade den kompetensen att lösa uppgiften. Även att alla visste vad som skulle göras av vem och när. Att projektledaren även om hon tar ett beslut på ett visst system(som hon i det här fallet inte skulle gjort) ser till att alla förstår varför och är med på det. Det är viktigt att alla har samma bild av vad som skall göras så projektet går åt rätt håll redan från början. Om man försöker med en genväg i början kommer det ofta och ”biter en i baken” innan allt är färdigt.

3.Hur kunde problemen kvarstå utan åtgärd under så lång tid?
3.Det tydligaste felet var att man inte gick grundligt tillväga när man skapade projektdirektivet och sa att man skulle arbeta vidare med det och lägga till detaljer(det ordnar sig mentalitet). Att man inte insåg att man saknade kompetensen som behövdes för vissa saker. Sedan när man väl tog in folk med rätt kompetens(designgruppen) som påpekar bristerna så tar man ändå inte tag i saken utan fortsätter mer eller mindre som förut. Att man fortsatte framåt utan att frågeställningarna var utredda. Det man borde gjort är att ”bita i det sura äpplet” och i princip startat om projektet(gått igenom projektdirektivet från början).

4.Ev andra egna reflektioner.
4.Jag får en känsla av att gruppsammansättningen inte riktigt har fungerat, när man blir oense om saker och ting ofta. Att man är oense och har olika åsikter är en förutsättning för att komma fram till bra och nya idéer men det får inte vara så mycket att det skapar en dålig stämning i gruppen. Inte heller bör det bli så att projektledaren tvingas gå in och bestämma vilket sätt som är bäst hela tiden, det bör gruppen tillsammans komma fram till.

Case Lavasoft

1.
Jag tycker att det uppstod mycket konflikter inom projektgruppen som gör att alla inte strävar mot samma mål. Man verkars inte lösa konflikterna utan projektledaren fick helt enkelt bestämma vad som skulle göras även om alla inte var med på det. Visserligen är det ju projektledarens uppgift att besluta när problem uppstår men det är ändå svårt att behöva jobba i motvind. Kanske blev gruppen för liten och inte så bra ihopsatt och dessutom var det inte bra att den isolerade sig från de övriga. Projektledaren skyndade på gruppen för mycket för att hinna innan deadline, man kodade och testade systemet innan man var färdig med saker som måste vara klara innan man kommer till det steget. Resultatet blev att man fick göra om en del saker som hade kunnat bli rätt från början om man gjort dem i rätt ordning. Det fanns fortfarande frågetecken kvar när man började koda allting. Projektgruppen såg inte till att kolla upp om det systemet de tänkte utveckla enligt kundens krav passade in i det system som kunden nu hade, vilket kan få konsekvenser när man ska implementera systemet. Ytterligare saker som gick fel var ju att man inte kunde hålla tidsplanen och att företaget aldrig mer anlitade dem efter denna fadäs.
2.
Inledningsvis var det nog oenigheten inom projektgruppen om vilket system, som kunde tillgodose kundens krav, man skulle använda sig av. Det gör ju att alla inte känner lika stort engagemang för projektet. Projektledaren skulle ha löst den frågan först innan hon gav sig i kast med att upprätta tidsplanen. Även om hon ansåg sig veta vilket system som skulle användas lyckades hon inte helt sälja in det hos alla i gruppen, många var ännu tveksamma till hur det hela skulle läggas upp. Det känns även som om tidsplanen gjordes för tidigt, innan man visst hur mycket som egentligen behövdes göras.
3.
Som jag skrev förut så verkar det inte som om projektledaren fick med sig alla sina medarbetare helt och hållet. De kommunicerade kanske dåligt med varandra, likaså isolerade de sig och tog kanske inte hjälp av andra experter utanför gruppen för att kunna lösa de problem som uppstod. Även om de visst att de inte hade all kunskap som skulle behövas blev det lite som ” själv är bäste dräng”.
4.
Ytterligare negativa delar är att när man efter ombearbetning färdigställt specifikationen fanns det ännu frågeställningar som inte var lösta. Projektgruppen kanske inte heller fortsatte med de träffar och uppdateringar som de hade i början av projektet med uppdragsgivaren eller också pratade de liksom olika språk så de förstod helt enkelt inte varandra. Det är väldigt viktigt att man använder ett språk som kunden förstår när man lägger fram saker och ting.

//Annica