RISKANALYS Basdatorarbetsplatstjänst på Chalmers fas 2 BAT

Transkript

1 Sidan: 1 (35) RISKANALYS Basdatorarbetsplatstjänst på Chalmers fas 2 BAT

2 Sidan: 2 (35) INNEHÅLLSFÖRTECKNING 1 REVISIONSINFORMATION OM DETTA DOKUMENT DELTAGARE RISKANALYS SYFTE MÅLSÄTTNING OMFATTNING METOD SAMMANFATTNING PROJEKTRISKER MÅLGRUPPER, ADMIN, STUDENTER, FORSKARE INFORMATION OCH SÄLJA IN DET HOS KUND FÖRANKRA BESTÄLLARE OCH ANVÄNDARE SPRÅKSVÅRIGHETER MELLAN PROJEKT OCH MÅLGRUPP FÖR FÅ ANVÄNDARE SVÅRIGHET ATT HITTA PILOTANVÄNDARE OLIKA FÖRVÄNTNINGAR PÅ EN FULLT UTVECKLAD TJÄNST TID (DELPROJEKT) SLA-FÖRHANDLING, LEGITIMITET PÅ ANVÄNDARSIDAN HÅLLER EJ TID OCH PENGAR PGA. TILLÄGG UNDER PERIODEN RESPONS PÅ FÖRSLAG BLIR SÄMRE OLIKA FÖRVÄNTNINGAR BEROENDE PÅ VEM MAN ÄR ANV/BESTÄLLARE FÖR FÅ ANVÄNDARE I TESTET ATTITYDER EJ NÖJDA ANVÄNDARE PERSONBORTFALL, KONKURRERANDE PROJEKT SER INTE TILL ATT HELA DRIFTSMILJÖN ÄR TILLRÄCKLIGT BRA FÖRANKRING FINANSIÄRER TJÄNSTEN EJ TILLRÄCKLIGT GENOMTÄNKT OCH TESTAD FÖRTROENDE FÖR LEVERANTÖR BASPAKETET OTILLRÄCKLIGT KORT TIDSPERIOD, DÅLIG DOKUMENTATION SUPPORTRISKER SUPPORT HELPDESK DRIFT APPLIKATIONER OCH SYSTEM KOMMA ÖVERENS OM SERVICENIVÅ HELPDESK KOMPETENSBRIST, KOMPETENSNIVÅ KOMMA ÖVERENS OM NIVÅ PÅ HELPDESK EJ FUNGERANDE KRINGUTRUSTNING LOKALA RESURSER BAT LOKAL IT, VEM GÖR VAD? PROGRAMSUPPORT DELA UPP HELPDESK/SUPPORT AFFÄRSRISKER KOSTNADSKOMPLEXITET SVÅRT ATT JÄMFÖRA KOSTNADER INTERNT OCH EXTERNT (TJÄNSTEN) INITIALKOSTNAD SVÅRT ATT BEDÖMA MARKNADEN, HUR STOR DEN ÄR SERVICE KOMMER UPPLEVAS SOM DYRARE, DE ACCEPTERAR INTE SERVICENIVÅN IT-FAKTURA + BAT SEKTIONSUPPDELNING... 24

3 Sidan: 3 (35) 7.7 NYTTAN MED BAT/CCM PRODUKT/LEVERANSRISKER FÖR FÅ PROGRAM FÖR MÅNGA PROGRAM TUNN KLIENT OCH MOBILITET SVÅRT ATT FÅ MED TYNGRE APPLIKATIONER MER JOBB OM ENSTAKA APPLIKATIONER ELLER/OCH HELA PAKET KRINGRUSTNING PDA MM SÄKERHET MOT ANVÄNDBARHET KOSTNADER PRODUKT, URVAL, LICENS LICENSER KONTROLL HANTERING MED SEKRETESS TILLGÄNGLIGHET SPRÅKPROBLEM PROGRAM DISTANSARBETE PÅ VILKET SÄTT HELHETSLÖSNING SAKNAR SERVICETJÄNSTER VERSIONSHANTERING TEKNISKA RISKER KOPPLING TILL CHALMERS KONTOSYSTEM IT-LÄRANDE EJ MEDIASTÖD PROGRAMKOMPETENS BEROENDE AV NÄTVERK VIRUSPROBLEM SÄKERHET, ANVÄNDARNAS ORO FÖR ATT FINNAS PÅ SAMMA SYSTEM PRESTANDA FÖRKLARING TILL KOLUMNRUBRIKER... 35

4 Sidan: 4 (35) 1 Revisionsinformation Utarbetat av Datum Version Ändringar Niclas Stoldt P0.1 Kapitel 1-4 och 10 Marina Hedin P0.2 Kapitel 5-9. Granskning av Niclas delar. Niclas Stoldt 1.0 Granskning

5 Sidan: 5 (35) 2 Om detta dokument Detta dokument beskriver projekt BAT:s risker. Dokumentet är ett resultat av ett riskseminarium som hölls den 28 februari 2002.

6 Sidan: 6 (35) 3 Deltagare Följande projektmedlemmar var med under analysen: 1. Jan-Martin Löwendahl 2. Görgen Olofsson 3. Michael Morin 4. Peter Strömberg 5. Henrietta Wictorsson 6. Per Andersson 7. Lars Andersson 8. Kristoffer Johansson Följande projektmedlemmar var ej med under analysen: 1. Börje Sennung 2. Björn O. Eriksson 3. Paul Waserbrot 4. Stellan Englèn, Ladok

7 Sidan: 7 (35) 4 Riskanalys 4.1 Syfte Syftet är att åskådliggöra riskanalysens resultat. Riskanalysen innefattar: Risker Uppskattning av sannolikhet och konsekvens Prioritering 4.2 Målsättning Att identifiera och prioritera de risker som hindrar projektet att uppfylla projektmål (enligt PDF) främst under fas Omfattning Riskanalysen omfattar projekt-, support-, affärs-, produkt- och teknikrisker. Riskseminariet avsåg inte ta fram pkt 5 i metoden nedan: åtgärder, ansvarig och färdigtidpunkt. Dokumentet innehåller därför inte heller pkt 5. En risk, Versionshantering, har tillkommit sent på mötet och har därför inte prioriterats. 4.4 Metod Följande steg ingår i riskanalysen: 1. Gemensamt komma överens om projektet mål 2. Lista risker och hot för projektet. Detta görs individuellt i gruppen 3. Sätt ihop en gemensam lista, som grupperas i kategorier (på tavlan) 4. Gör en prioritering av varje risk genom att uppskatta en sannolikhet för att Risken/hotet skall inträffa och konsekvensen om det inträffar. Sannolikhet H M L H H=Hög M=Medel L L=Låg Talen i tabellen avser prioritet och innebär följande: Prio 1 - riskerna skall elimineras Prio riskerna skall elimineras eller hanteras Prio riskerna skall hanteras eller bevakas 5. Föreslå åtgärder för att eliminera, förebygga eller hantera risker, utse ansvarig person och bestämma färdigtidpunkt

8 Sidan: 8 (35) 3 Sammanfattning Riskerna är sorterade efter prioritet enligt: 1 har högst prioritet, 6 har lägst prioritet. Risk benämning Beskrivning S K Prio Kategori Ansv proj Målgrupper, admin, studenter, forskare För få program Information och sälja in det hos kund. Förankra beställare, användare Språksvårigheter mellan projekt och målgrupp För få användare Svårighet att hitta pilotanvändare Support helpdesk drift applikationer och system Kostnadskomplexitet Komma överens om servicenivå helpdesk Olika förväntningar på en fullt utvecklad tjänst. Koppling Chalmers kontosystem Vad är BAT tänkt att användas till, vilken gruppering, differentiering av olika programpaket till olika målgrupper, risken är att det inte är klart definierat. Grupperna måste vara klart definierade Användarna får inte tillräcklig funktionalitet. Om projektet mot användarna, att inte förankra i organisationen Användarna har svårt för att tala om vad de vill ha, de talar inte samma språk och tvärt om. Användarna är inte tillräckligt intresserade Vad är det som ingår? Definiera vilken omfattning av support. Komplex supportsituaiton. Vi tror att det är blir billigare, men är det säkert? Vi kan inte bevisa att det blir billigare, svårt att göra en korrekt kostnadsjämförelse Kommer man ha samma syn på service Förväntningar, acceptans på version 1.0 H H 1 P H H 1 L H H 1 P H H 1 P H H 1 P H H 1 P H H 1 P H H 1 S H H 1 A H H 1 S H H 1 P H H 1 T Ansv utanför När Status

9 Sidan: 9 (35) Kompetensbrist, kompetensnivå Tid (delprojekt) Komma överens om nivå på helpdesk SLA-förhandling, legitimitet på användarsidan För många program Håller ej tid och pengar pga. tillägg under perioden IT-lärande ej mediastöd Tunn klient och mobilitet Respons på förslag blir sämre Svårt att få med tyngre applikationer Olika förväntningar beroende på vem man är anv/beställare Mer jobb om enstaka applikationer eller/och hela paket Programkompetens Ej fungerande kringutrustning Kringrustning PDA mm För få användare i testet Tidsbrist, resursbrist Lokalt eller någon telefonsupport Vem bestämmer? En motpart måste hittas. Skall inte finnas tio olika program för att göra matematiska beräkningar. H H 1 S H H 1 P H H 1 S H H 1 P H M 2 L H M 2 P Teknisk begränsning t. ex distansutbildning H M 2 T Mobila användare H M 2 L Måste kunna gå genom en tungarbetad organisation för att få respons Svårt att tillämpa det i BAT, användaren vet inte vilka stora resurser han begär Om man skall vara tvungen att köpa hela konceptet eller enstaka applikationer Det blir omöjligt i driften att veta hur det fungerar. Måste ha hjälp. T. ex om skrivaren inte fungerar Användaren kommer att vilja ha det i produkten. Kalendertid inget problem utan för få användare H M 2 P H M 2 L H M 2 P H M 2 L H M 2 T H M 2 S H M 2 L H M 2 P Attityder Inställning M H 3 P

10 Sidan: 10 (35) Ej nöjda användare Personbortfall, konkurrerande projekt Ser inte till att hela driftsmiljön är tillräckligt bra Svårt att jämföra kostnader internt och externt (tjänsten) Initialkostnad Svårt att bedöma marknaden, hur stor den är. Säkerhet mot användbarhet Kostnader produkt, urval, licens Licenser Lokala resurser Service kommer upplevas som dyrare, de accepterar inte servicenivån IT-faktura + BAT sektionsuppdelning BAT lokal IT, vem gör vad? Programsupport Vad händer om folk inte gillar tjänsten? Vad händer med projektet om användarna inte är nöjda? Om någon slutar i projektet eller blir sjuk. Glömmer mer skarp test, tidsbrist. Projektet skall få fram en jämförelse kostnadsmässigt internt och externt. Det kan bli för dyrt, vem betalar, en slags tröskelkostnad. Förutsäga marknaden Många användare, balans mellan säkerhet och användbarhet Hur hanterar vi licenserna, antingen basutbud eller tillägg, hur hanterar man kostanden? Kostnader och lev av ett program kanske ändrar sig plötsligt och en viss grupp kanske inte får använda, dvs. licensregler En helpdeskfråga men svårt att få lokala resurser Kostnaden dyrare eftersom den blir definierad, garanterbarhet Hur får vi ut kostnaden på klienten? Lokal IT vänder sig till lokal IT, har med ansvar att göra. Orkar inte ge support på allt, var skall gränsen gå? M H 3 P M H 3 P M H 3 P M M 4 A M M 4 A M M 4 A M M 4 L M M 4 L M M 4 L M M 4 S M M 4 A M M 4 A H L 5 S H L 5 S Förankring finansiärer L H 5 P

11 Sidan: 11 (35) Kontroll Hantering med sekretess Tillgänglighet Beroende av nätverk Nyttan med BAT/CCM Baspaketet otillräckligt Virusproblem Språkproblem program Tjänsten är ej tillräckligt genomtänkt och testad Förtroende för leverantör Dela upp HelpDesk/support Säkerhet, användarnas oro för att finnas på samma system Distansarbete på vilket sätt Prestanda Kort tidsperiod, dålig dokumentation Helhetslösning saknar servicetjänster Versionshantering Användarna vill gärna installera spel mm, gäller att få acceptans hos användarna, användarna kanske tycker att de tappar kontrollen. Måste ha samman regler för alla, vad man får göra. Man kan oroa sig för att man får sämre tillgänglighet, ökat beroende t. ex om man arbetar hemma. Fungerar inte detta då står allt stilla, kommer inte att kunna göra något alls. Måste jämföra de olika alternativen och peka på nyttan, titta på konkurrerande lösningar H L 5 L L H 5 L L H 5 L L H 5 T L H 5 A H L 5 P Idealsikt om alla kör samma program. H L 5 T Engelska rakt H L 5 L igenom? Bristfällig testning L H 5 P Intern eller extern lev? L H 5 P Risken är att vi tar L H 5 S för lätt på frågan Behörighet L M 6 T Vem skall vi hänvisa till när produkten skall fixas? Ta hand om distansarbete Vad gör jag om prestandan är för låg? Allt som görs skall dokumenteras Ta hand om t. ex e- mailkonton M L 6 L L M 6 T L M 6 P M L 6 L L

12 Sidan: 12 (35) Prioritet 1 5 PROJEKTRISKER 5.1 Målgrupper, admin, studenter, forskare Beskrivning Vad är BAT tänkt att användas till, vilken gruppering, differentiering av olika programpaket till olika målgrupper, risken är att det inte är klart definierat. Grupperna måste vara klart definierade Indikatorer Förebyggande Hantering Prioritet Information och sälja in det hos kund Beskrivning Om projektet mot användarna, att inte förankra i organisationen Indikatorer Förebyggande Hantering Prioritet Förankra beställare och användare Beskrivning Indikatorer Förebyggande Hantering

13 Sidan: 13 (35) Prioritet Språksvårigheter mellan projekt och målgrupp Beskrivning Användarna har svårt för att tala om vad de vill ha, de talar inte samma språk och tvärt om Indikatorer Förebyggande Hantering Prioritet För få användare Beskrivning Användarna är inte tillräckligt intresserade Indikatorer Förebyggande Hantering Prioritet Svårighet att hitta pilotanvändare Beskrivning Indikatorer Förebyggande Hantering Prioritet Olika förväntningar på en fullt utvecklad tjänst

14 Sidan: 14 (35) Beskrivning Förväntningar, acceptans på version Indikatorer Förebyggande Hantering Prioritet Tid (delprojekt) Beskrivning Tidsbrist, resursbrist Indikatorer Förebyggande Hantering Prioritet SLA-förhandling, legitimitet på användarsidan Beskrivning Vem bestämmer? En motpart måste hittas Indikatorer Förebyggande Hantering Prioritet Håller ej tid och pengar pga. tillägg under perioden

15 Sidan: 15 (35) Beskrivning Indikatorer Förebyggande Hantering Prioritet Respons på förslag blir sämre Beskrivning Måste kunna gå genom en tungarbetad organisation för att få respons Indikatorer Förebyggande Hantering Prioritet Olika förväntningar beroende på vem man är anv/beställare Beskrivning Indikatorer Förebyggande Hantering Prioritet För få användare i testet Beskrivning Kalendertid inget problem utan för få användare

16 Sidan: 16 (35) Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Attityder Inställning Beskrivning Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Ej nöjda användare Beskrivning Vad händer om folk inte gillar tjänsten? Vad händer med projektet om användarna inte är nöjda? Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Personbortfall, konkurrerande projekt Beskrivning Om någon slutar i projektet eller blir sjuk.

17 Sidan: 17 (35) Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Ser inte till att hela driftsmiljön är tillräckligt bra Beskrivning Glömmer mer skarp test, tidsbrist Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Förankring finansiärer Beskrivning Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Tjänsten ej tillräckligt genomtänkt och testad Beskrivning Bristfällig testning.

18 Sidan: 18 (35) Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Förtroende för leverantör Beskrivning Intern eller extern leverantör? Indikatorer Förebyggande Hantering Konsekvens L Prioritet Baspaketet otillräckligt Beskrivning Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Kort tidsperiod, dålig dokumentation Beskrivning Allt som görs skall dokumenteras

19 Sidan: 19 (35) Indikatorer Förebyggande Hantering

20 Sidan: 20 (35) Prioritet 1 6 SUPPORTRISKER 6.1 Support helpdesk drift applikationer och system Beskrivning Vad är det som ingår? Definiera vilken omfattning av support. Komplex supportsituation Indikatorer Förebyggande Hantering 6.2 Komma överens om servicenivå helpdesk Prioritet Beskrivning Kommer man ha samma syn på service Indikatorer Förebyggande Hantering 6.3 Kompetensbrist, kompetensnivå Prioritet Beskrivning Indikatorer Förebyggande Hantering

21 Sidan: 21 (35) 6.4 Komma överens om nivå på helpdesk Prioritet Beskrivning Lokalt eller någon telefonsupport Indikatorer Förebyggande Hantering 6.5 Ej fungerande kringutrustning Prioritet Beskrivning T. ex om skrivaren inte fungerar Indikatorer Förebyggande Hantering 6.6 Lokala resurser Sannolikhet M Prioritet Beskrivning En helpdeskfråga men svårt att få lokala resurser Indikatorer Förebyggande Hantering Sannolikhet 6.7 BAT lokal IT, vem gör vad? H

22 Sidan: 22 (35) Konsekvens L Prioritet Beskrivning Lokal IT vänder sig till lokal IT, har med ansvar att göra Indikatorer Förebyggande Hantering Konsekvens L Prioritet Programsupport Beskrivning Orkar inte ge support på allt, var skall gränsen gå? Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Dela upp HelpDesk/support Beskrivning Risken är att vi tar för lätt på frågan Indikatorer Förebyggande Hantering

23 Sidan: 23 (35) Prioritet 1 7 AFFÄRSRISKER 7.1 Kostnadskomplexitet Beskrivning Vi tror att det är blir billigare, men är det säkert? Vi kan inte bevisa att det blir billigare, svårt att göra en korrekt kostnadsjämförelse Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Svårt att jämföra kostnader internt och externt (tjänsten) Beskrivning Projektet skall få fram en jämförelse kostnadsmässigt internt och externt Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Initialkostnad Beskrivning Det kan bli för dyrt, vem betalar, en slags tröskelkostnad Indikatorer Förebyggande Hantering

24 Sidan: 24 (35) Sannolikhet M Prioritet Svårt att bedöma marknaden, hur stor den är Beskrivning Förutsäga marknaden Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Service kommer upplevas som dyrare, de accepterar inte servicenivån Beskrivning Kostnaden dyrare eftersom den blir definierad, garanterbarhet Indikatorer Förebyggande Hantering Sannolikhet M Prioritet IT-faktura + BAT sektionsuppdelning Beskrivning Hur får vi ut kostnaden på klienten? Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Nyttan med BAT/CCM

25 Sidan: 25 (35) Beskrivning Måste jämföra de olika alternativen och peka på nyttan, titta på konkurrerande lösningar Indikatorer Förebyggande Hantering

26 Sidan: 26 (35) Prioritet 1 8 PRODUKT/LEVERANSRISKER 8.1 För få program Beskrivning Användarna får inte tillräcklig funktionalitet Indikatorer Förebyggande Hantering Prioritet För många program Beskrivning Skall inte finnas tio olika program för att göra matematiska beräkningar Indikatorer Förebyggande Hantering Prioritet Tunn klient och mobilitet Beskrivning Mobila användare.

27 Sidan: 27 (35) Indikatorer Förebyggande Hantering Prioritet Svårt att få med tyngre applikationer Beskrivning Svårt att tillämpa det i BAT, användaren vet inte vilka stora resurser han begär Indikatorer Förebyggande Hantering Prioritet Mer jobb om enstaka applikationer eller/och hela paket Beskrivning Om man skall vara tvungen att köpa hela konceptet eller enstaka applikationer Indikatorer Förebyggande Hantering Prioritet Kringrustning PDA mm Beskrivning Användaren kommer att vilja ha det i produkten.

28 Sidan: 28 (35) Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Säkerhet mot användbarhet Beskrivning Många användare, balans mellan säkerhet och användbarhet Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Kostnader produkt, urval, licens Beskrivning Hur hanterar vi licenserna, antingen basutbud eller tillägg, hur hanterar man kostanden? Indikatorer Förebyggande Hantering Sannolikhet M Prioritet Licenser Beskrivning Kostnader och lev av ett program kanske ändrar sig plötsligt och en viss grupp kanske inte får använda, dvs. licensregler

29 Sidan: 29 (35) Indikatorer Förebyggande Hantering Konsekvens L Prioritet Kontroll Beskrivning Användarna vill gärna installera spel mm, gäller att få acceptans hos användarna, användarna kanske tycker att de tappar kontrollen Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Hantering med sekretess Beskrivning Måste ha samman regler för alla, vad man får göra Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Tillgänglighet Beskrivning Man kan oroa sig för att man får sämre tillgänglighet, ökat beroende t. ex om man arbetar hemma.

30 Sidan: 30 (35) Indikatorer Förebyggande Hantering Konsekvens L Prioritet Språkproblem program Beskrivning Engelska rakt igenom? Indikatorer Förebyggande Hantering Sannolikhet M Konsekvens L Prioritet Distansarbete på vilket sätt Beskrivning Vem skall vi hänvisa till när produkten skall fixas? Ta hand om distansarbete Indikatorer Förebyggande Hantering Sannolikhet M Konsekvens L Prioritet Helhetslösning saknar servicetjänster Beskrivning Ta hand om t. ex konton.

31 Sidan: 31 (35) Indikatorer Förebyggande Hantering Sannolikhet Konsekvens Prioritet 8.16 Versionshantering Ej definierad Ej definierad Ej definierad Beskrivning Indikatorer Förebyggande Hantering

32 Sidan: 32 (35). Prioritet 1 9 TEKNISKA RISKER 9.1 Koppling till Chalmers kontosystem Beskrivning Indikatorer Förebyggande Hantering Prioritet IT-lärande ej mediastöd Beskrivning Teknisk begränsning t. ex distansutbildning Indikatorer Förebyggande Hantering Prioritet Programkompetens Beskrivning Det blir omöjligt i driften att veta hur det fungerar. Måste ha hjälp Indikatorer Förebyggande Hantering Sannolikhet 9.4 Beroende av nätverk L

33 Sidan: 33 (35) Prioritet Beskrivning Fungerar inte detta då står allt stilla, kommer inte att kunna göra något alls Indikatorer Förebyggande Hantering Konsekvens L Prioritet Virusproblem Beskrivning Idealsikt om alla kör samma program Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Säkerhet, användarnas oro för att finnas på samma system Behörighet Beskrivning Indikatorer Förebyggande Hantering Sannolikhet L Prioritet Prestanda

34 Sidan: 34 (35) Beskrivning Vad gör jag om prestandan är för låg? Indikatorer Förebyggande Hantering

35 Sidan: 35 (35) 10 FÖRKLARING TILL KOLUMNRUBRIKER Risk nr: Riskens nummer P = Projektrisk S = Supportrisker A = Affärsmässig risk L = Produktrisk, Leveransrisk T = Teknisk risk Risk benämning: Riskens benämning (riskens namn, riskens rubrik) S: Sannolikhet K: Konsekvens P: Prioritet, Produkten av S och K. Prio 1 - riskerna skall elimineras Prio riskerna skall elimineras eller hanteras Prio riskerna skall hanteras eller bevakas Åtgärd: Vad som skall göras för att åtgärda risken. Ansvarig: Vem som är ansvarig för att åtgärden blir utförd. När: När åtgärden senast skall vara åtgärdad. Status: (tomt) = Ej påbörjat P = Påbörjad A = Avslutad