Risklista - 1DV611/effect-reklambyra GitHub Wiki

Topp 5 risker

ID Namn Beskrivning Sannolikhet Konsekvens Prioritet
R3.1 Otillgänglighet. Någon i projektteamet blir upptagen, sjuk etc. 3 2 6
R3.3 Felaktig tidsuppskattning. Något tar längre tid än väntat/planerat. 2 3 6
R3.7 Oåtkomlig data från APIer Om det inte är möjligt att få ut viss data genom sidornas API. 2 3 6
R1.2 Kravändringar. Kunden ändrar krav under projektets gång. 2 2 4
R2.2 Kommunikation i projektteam. Kommunikation online kan brista, och vissa saker kan glömmas att tas upp under möten. 2 2 4

Scope & Krav

R1.1 - Otydliga krav

  • Beskrivning: Kunden ger otydliga/odefinierade krav eller förväntningar.
  • Sannolikhet: 1
  • Konsekvens: 2
  • Prioritet: 2
  • Strategi:
  • Uppdatering iteration 2: Vi har fått kraven och dem verkar ganska tydliga. Sänker sannolikheten från 2 till 1.
  • Uppdatering iteration 4: Regelbundna möten hålls med kunden där eventuella frågetecken kan tas upp. Sänker konsekvensen från 4 till 2.

R1.2 - Kravändringar

  • Beskrivning: Kunden ändrar krav under projektets gång.
  • Sannolikhet: 2
  • Konsekvens: 2
  • Prioritet: 4
  • Strategi: Det kan vara bra att börja göra basfunktionaliteten, eftersom den inte kommer att ändras så mycket. Ha regelbunden kontakt med kunden och visa vad vi gjort eller planerar att göra så att dem kan säga till så tidigt som möjligt.
  • Uppdatering iteration 3: Basfunktionaliteten sätts på plats först sen läggs ytterligare funktionalitet till baserat på vad kunden önskar och hur mycket tid som finns kvar. Konsekvensen sänks från 3 till 2.

R1.3 - Fel kravprioritet

  • Beskrivning: Kravprioriteten kan vara felaktig, vilket gör att timmar läggs på något onödigt istället för något viktigare.
  • Sannolikhet: 1
  • Konsekvens: 3
  • Prioritet: 3
  • Strategi: En kravspecifikation ska göras som listar och prioriterar kraven baserat på kundens önskningar.
  • Uppdatering iteration 4: Kravspecifikationen är satt med tydliga prioriteringar. Sänker sannolikheten från 2 till 1.

Kommunikation

R2.1 - Kommunikation till kund

  • Beskrivning: Kunden får inte reda på projektets utveckling.
  • Sannolikhet: 1
  • Konsekvens: 3
  • Prioritet: 3
  • Strategi: Om kunden vill veta hur projektet går är det upp till de/den kundansvarige att underrätta dem. Kanske med ett möte eller uppdateringar veckovis.
  • Uppdatering iteration 3: Regelbundna uppdateringar ges i form av möten, eller om det inte är mycket nytt via mail. Sänker sannolikheten från 2 till 1.

R2.2 - Kommunikation i projektteam

  • Beskrivning: Kommunikation online kan brista, och vissa saker kan glömmas att tas upp under möten.
  • Sannolikhet: 2
  • Konsekvens: 2
  • Prioritet: 4
  • Strategi: Google Hangouts används som mötesplats och om det strular används backupprogram som Skype. Kommunikation sker också i Slack.
  • Uppdatering iteration 3: När det är problem med Hangouts har det gått bra med Skype eller vice versa. Sänker både sannolikheten och konsekvensen från 3 till 2.

Resurser & Team

R3.1 - Otillgänglighet

  • Beskrivning: Någon i projektteamet blir upptagen, sjuk etc.
  • Sannolikhet: 3
  • Konsekvens: 2
  • Prioritet: 6
  • Strategi: När detta händer är det upp till var och en att jobba ikapp timmarna, som beskrivs i konfliktkontraktet. Det är också viktigt att kommunicera med resten av teamet så dem vet om de behöver täcka för den som är borta eller inte.
  • Uppdatering iteration 3: Eftersom vi är ganska många i gruppen (5 stycken) har det gått bra ändå när någon är borta. Sänker konsekvensen från 3 till 2.

R3.2 - Lärningskurvor

  • Beskrivning: Bristande kunskap/erfarenhet kan göra att lärningskurvor uppstår, vilket tar upp tid från resurserna för att lära sig.
  • Sannolikhet: 1
  • Konsekvens: 3
  • Prioritet: 3
  • Strategi: När de tekniska besluten har tagits ska potentiella lärningskurvor undersökas runt Elaborationfasen, det är helt OK att planera tid för att lära sig eller göra research om något. Tar det längre tid än väntat se R3.3.
  • Uppdatering iteration 3: För att undvika stora tidskrävande lärningskurvor, har tekniker som alla känner sig bekväma med valts. Sannolikheten sänks till 2.
  • Uppdatering iteration 4: Alla känner sig säkra med tekniker och verktyg. Sannolikheten sänks till 1.

R3.3 - Felaktig tidsuppskattning

  • Beskrivning: Något tar längre tid än väntat/planerat.
  • Sannolikhet: 2
  • Konsekvens: 3
  • Prioritet: 6
  • Strategi: Det kan vara en bra idé att planera tiden lite generöst, alltså om man är osäker på hur mycket tid något tar att utföra planera hellre in mer tid än mindre. Eftersom vi jobbar i en iterativ miljö kan vi lättare planera om varje iteration. Inträffar detta måste det framföras till resten av teamet så nästa iteration kan planeras utifrån det, och om nödvändigt kan fler personer delegeras till uppgiften.
  • Uppdatering iteration 4: Eftersom vi har valt tekniker vi är vana vid har vi bra koll på hur lång tid saker tar. Sänker sannolikhet från 4 till 2.

R3.4 - Tidsdokumentation

  • Beskrivning: Arbetstider dokumenteras inte på ett bra sätt, leder till att ingen vet hur länge man har jobbat.
  • Sannolikhet: 1
  • Konsekvens: 3
  • Prioritet: 3
  • Strategi: Varje person ansvarar för att dokumentera sina arbetstider, Toggl kommer användas för att få så transparent tidsdokumentering som möjligt.
  • Uppdatering iteration 2: Toggl används av samtliga så sannolikheten minskar från 2 till 1.

R3.5 - Besluttagande

  • Beskrivning: Projektteamet kan inte enas om beslut om projektet
  • Sannolikhet: 1
  • Konsekvens: 3
  • Prioritet: 3
  • Strategi: Liten sannolikhet eftersom det har gått bra än så länge. Händer det kan det lösas med en omröstning eller kan den ansvariga för det området ta ett beslut.

R3.6 - Arbetsuppgifter görs inte

  • Beskrivning: Någon i projektteamet gör inte sina arbetsuppgifter.
  • Sannolikhet: 1
  • Konsekvens: 4
  • Prioritet: 4
  • Strategi: Alla ska signera ett konfliktkontrakt som beskriver varje persons ansvar för att avskräcka någon att bryta det.

R3.7 - Oåtkomlig data från APIer

  • Beskrivning: Om det inte är möjligt att få ut viss data genom sidornas API.
  • Sannolikhet: 2
  • Konsekvens: 3
  • Prioritet: 6
  • Strategi: Undersökningar måste göras om vad som behövs för att få ut datan från APIerna och om det ens är möjligt. Om det inte är möjligt måste alternativa lösningar hittas, som en länk till där datan finns så får användaren manuellt fylla i det eller liknande.
  • Uppdatering iteration 3: Har gjort undersökningar på APIerna och det verkar vara bra stöd för i stort sett alla. Sänker sannolikheten 3, till 2.
  • Uppdatering iteration 4: Om det är någon enstaka sida där det inte finns API stöd kan man inkludera en länk och möjlighet att fylla i datan manuellt, och möjlighet att välja bort den sidan helt om man inte vill göra det manuellt.