1. Czy jest sformułowanych przynajmniej 5 znanych ryzyk, które mogą wystąpić podczas wdrożenia i wpływać na jego czas ukończenia?
2. Czy ryzyka są dobrze opisane?
3. Czy są wypisane działania zapobiegawcze do każdego ryzyka?
4. Czy jest określone prawdopodobieństwo wystąpienia danego ryzyka?
5. Czy jest określony wpływ danego ryzyka na wdrożenie?
6.  
7. Lista ryzyk
8.  
9. Ryzyko 1
10.  
11. Nazwa: Integracja z systemami wewnętrznymi wykorzystywanymi przez uczelnię
12. Ryzyko wystąpienia: duże
13. Wpływ ryzyka na wdrożenie: znaczące opóźnienie prac developerskich i wdrożenia
14. Opis:
15. Potrzeba integracji z zewnętrznymi systemami wykorzystywanymi przez uczelnię wprowadza dodatkowe zagrożenia wynikające z możliwego braku dokumentacji i/lub nieznanej struktury danych w bazie danych. Uczelnia korzysta z wielu gotowych, komercyjnych aplikacji służącymi do zarządzania różnego rodzaju procesami na uczelni. Każda z aplikacji zarządza danymi niezbędnymi jej do spełniania określonych funkcji. Istnieje duże ryzyko, że nasz zespół będzie musiał wykonać analizę wykorzystywanych systemów i samemu odnaleźć interesujące nas dane. Ponadto uczelnia jest aktualnie w czasie migracji z jednego systemu zarządzania dziekanatem do innego (Uczelnia XP do Uczelnia 10).
16. Działania zapobiegawcze:
17. Pierwszy sprint w rozpisanym harmonogramie zadań obejmuję analizę istniejących systemów i przygotowanie ich do integracji. Zespół podchodzi do integracji priorytetowo jako kluczowej dla implementacji zakończonej sukcesem. Dzięki temu minimalizujemy niebezpieczeństwo, które mogłoby wyniknąć z przesunięcia tego rodzaju zadań na koniec prac implementacyjnych.
18.  
19. Ryzyko 2
20. Nazwa: Migracja uczelni z systemu Uczelnia XP do wersji Uczelnia 10
21. Ryzyko wystąpienia: średnie
22. Wpływ ryzyka na wdrożenie: dodatkowe opóźnienia w trakcie integracji i wdrożenia
23. Opis:
24. Uczelnia przeprowadza aktualnie proces migracji z systemu Uczelnia XP do systemu Uczelnia 10. Migracja pociąga za sobą aktualizację bazy danych (Microsoft SQL Server 2008 R2 na Microsoft SQL Server 2016 SP1 Standard). Pociąga ona za sobą zmiany w schemacie bazy danych, co może wydłużyć proces migracji. Ponadto migracja danych ze starej wersji do nowej niesie za sobą ryzyko zaistnienia danych niepoprawnych w nowej bazie danych. Takie dane mogę utrudnić przeprowadzaną przez nas integrację z różnymi systemami uczelnianymi.
25. Działania zapobiegawcze:
26. Od początku projektu należy jasno określić miejsce skąd pobierane będą przez nas dane. Dodatkowo już w pierwszym sprincie zaplanowana jest analiza systemów z jakimi mamy się integrować pod kątem wykorzystywanych struktur danych.
27.  
28. Ryzyko 3
29. Nazwa: Brak czasu ze strony klienta na omówienie prototypów/makiet
30. Ryzyko wystąpienia: średnia
31. Wpływ ryzyka na wdrożenie: opóźnienie procesu analizy i definicji wymagań – opóźnienia prac implementacyjnych
32. Opis:
33. W trakcie definicji dokładnych wymagań i projektowania prototypu wymagana jest ciągła współpraca z klientem. W sytuacji kiedy klient nie będzie dostarczał komentarzy w odpowiednim czasie istnieje uzasadnione ryzyko, że proces tworzenia prototypu i definicji wymagań będzie się przedłużać. Takie przedłużenie opóźni tym samym proces implementacji i wdrożenia. Ponadto niepoprawne lub niedokładne wymagania mogę również przejść do etapu implementacji. W tym wypadku zespół programistów może niepotrzebnie stracić czas na implementację błędnych założeń.
34. Działania zapobiegawcze:
35. Od początku projektu analitycy ustanawiają harmonogram spotkać z klientem uświadamiając go o ich wadze. Każde ze spotkać kończy się ustalonym zestawem wiadomości, które są następnie źródłem wymagań funkcjonalnych na aplikację. Ponadto stanowią one główne informacje, którymi kierują się twórcy interfejsu. Klient otrzymuje notatkę ze spotkania na temat wszystkich powziętych ustaleń, która jest przez niego formalnie potwierdzana. W ten sposób ograniczamy do minimum możliwość nieporozumień.
36.  
37. Ryzyko 4
38. Nazwa: Brak odpowiedniego personelu ze strony klienta na etapie definicji wymagań
39. Ryzyko wystąpienia: średnie
40. Wpływ ryzyka na wdrożenie: Powstanie aplikacji, która nie spełnia wymagań docelowych użytkowników i tym samym nie ułatwia i nie przeyspisza procesu zarządzania uczelnią
41. Opis:
42. Podczas definicji wymagań klient powinien dostarczać informacje od osób, które będą pracować z danymi modułami aplikacji. Tylko takie osoby mogą dostarczyć odpowiedni zestaw informacji związany z poprawnym zaprojekjtowaniem danych procesów i interfejsu. Często w firmach osoba, która będzie źródłem wymagań, nie jest osobą, która ostatenicze będzie wykorzystuwać aplikację. W takim wypadku zdanie docelowych użytlowników zostaje pominięte, co może doprowadzić do stworzenia produktu, który nie zostanie wdrożony. Nie będzie bowiem spełniał podstawowych wymagań stawianych mu przez jego użytkowników.
43. Działania zapobiegawcze:
44. Analityce i osoby odpowiedzialne za UX od początku swojej pracy będą prosiły o bezpośredni kontakt do osób, które pełnią dane funkcje na uczelni. Interfejsy będą z nimi konsultowane i dzięki temu ich zdanie będzie uwzględnione w procesie decyzyjnym związanym z tworzeniem interfejsu. Ponadto w późniejszej fazie projektu pracownicy będą mieli możliwość przetestowania prototypu i zgłoszenia ewentualnych poprawek.
45.  
46. Ryzyko 5
47. Nazwa: Brak czasu ze strony zespołu testującego na sprawdzenie wszystkich konfiguracji przeglądarek i systemów operacyjnych
48. Ryzyko wystąpienia: średnie
49. Wpływ ryzyka na wdrożenie: niskie
50. Opis:
51. Ze względu na dość niewielki okres czasu przeznaczony na implementację, zespół testerów ma niewielką ilość czasu na sprawdzenie wszystkich konfiguracji przeglądarek i systemów operacyjnych na których aplikacja powinna zachowywać się bez zarzutu. W przypadku nieprzetestowania danej konfiguracji mogą wystąpić różnego rodzaju problemy związane z wyglądem lub rzadziej z samym korzystaniem ze strony.
52. Działania zapobiegawcze:
53. Powiększony zespół testerów będzie sprawdzał moduły aplikacji na bieżąco, w trakcie całego procesu wytwarzania aplikacji. W ten sposób testy nie będą przesunięte na koniec projektu, kiedy projekt będzie bardzo bliski wdrożenia. Ponadto jak najszybsze zgłaszanie błędów na etapie budowy interfejsu powinno być prostsze do poprawny, niż przebudowa kodu na etapie wdrożenia. W ten sposób powinniśmy być w stanie przetestować i ewentualnie wprowadzić poprawki związane z większością konfiguracji systemu operacyjnego i przeglądarki jakie chcemy wspierać.
54.