Ryzyko w projektach informatycznych



Podobne dokumenty
Wstęp do zarządzania projektami

Wstęp do zarządzania projektami

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Szkolenie: Zarządzanie cyklem projektu w Jednostkach Samorządu Terytorialnego

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wstęp do zarządzania projektami

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Zastosowania informatyki w gospodarce Projekt

Zaplanować projekt fundraisingowy i przeprowadzić go przez wszystkie etapy realizacji nie tracąc z pola widzenia założonych efektów;

Szkolenie: Warsztaty przygotowujące do certyfikacji IPMA, poziom D

Zarządzanie projektami. Zarządzanie ryzykiem projektu

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA

Pomagamy firmom podejmować trafne decyzje biznesowe. Dostarczamy korzystne i nowoczesne rozwiązania IT. HURO Sp. z o.o.

BUDOWANIE PARTNERSTWA PONADNARODOWEGO. Wrocław, 13 maja 2010r.

Głównym zadaniem tej fazy procesu zarządzania jest oszacowanie wielkości prawdopodobieństwa i skutków zaistnienia zidentyfikowanych uprzednio ryzyk.

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Ryzyko i zarządzanie ryzykiem w projektach

WARSZTATY. Szkolenie International Project Management Association (IPMA) poziom D. Kraków, dn. 7 marca 2019

ZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie projektami zadaniowymi w oparciu o metodykę PMI

Działalność B+R Oferta Prowadzenie działalności B+R Wdrażanie wyników prac B+R Zarządzanie projektami B+R

MSF. Microsoft Solution Framework

W. 3. Zarządzanie projektami: potrzeba str. 30. W. 4. Odpowiedź na zmieniające się warunki str. 32. W. 5. Systemowe podejście do zarządzania str.

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium

ZARZĄDZANIE PROJEKTAMI W KOMUNIKACJI

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

ZARZĄDZANIE PROJEKTAMI W KOMUNIKACJI

VII. SZKOLENIA MIĘKKIE

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI

PRAKTYKA ZARZĄDZANIA PROJEKTAMI W OPARCIU O PMBOK GUIDE 5TH.ED.

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

( SZKOŁA ZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI

ZARZĄDZANIE INNOWACJĄ

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji

Zarządzanie projektami IT

P O L I T E C H N I K A K O S Z A L I Ń S K A. Zarządzanie Ryzykiem

Analiza ryzyka nawierzchni szynowej Iwona Karasiewicz

OD JAKOŚCI DO TRWAŁOŚCI REZULTATÓW W PROJEKTACH ERASMUS+

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem.

ZARZĄDZANIE STRATEGICZNE OPRACOWANIE

Dobór systemów klasy ERP

Cykl szkoleń z zarządzania projektami z certyfikacją IPMA poziom D - IV

Program kształcenia i plan studiów podyplomowych: Zarządzanie projektami

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Usługa: Testowanie wydajności oprogramowania

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Wsparcie narzędziowe zarządzania ryzykiem w projektach

VII. SZKOLENIA MIĘKKIE

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

2.11. Monitorowanie i przegląd ryzyka Kluczowe role w procesie zarządzania ryzykiem

STUDIA PODYPLOMOWE Zarządzanie Projektami

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Spis treści Wstęp 1. Wprowadzenie 2. Zarządzanie ryzykiem systemów informacyjnych

ZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI

Projekt: Szansa drzemie w zmianie nowoczesne ZZL

ŚCIEŻKA: Zarządzanie projektami

AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2

Szczegółowy opis przedmiotu zamówienia założenia dla metodyki realizacji Projektu

PRZEWODNIK PO PRZEDMIOCIE

Programowanie zespołowe

POLITYKA ZARZĄDZANIA RYZYKIEM ROZDZIAŁ I. Postanowienia ogólne

Obszar 1: PROŚ. Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego

PODSTAWY ZARZĄDZANIA PROJEKTAMI

Feature Driven Development

Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015

Human Performance Improvementjak HR może podnieść efektywność organizacyjną firmy

Zarządzanie projektami. Porównanie podstawowych metodyk

Szkolenie Podstawy Zarządzania Projektami Informator

Mapa ryzyk w realizacji e-projektu - identyfikacja zagrożeń. Skala zagrożenia dla projektu, prawdopodobieństwo wystąpienia. Szacowanie kosztów ryzyka.

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Poddziałanie 2.1.2, typ projektu 2. Wykaz usług

Szczegółowy opis przedmiotu zamówienia- założenia do metodyki realizacji przedmiotu zamówienia

Zarządzanie innowacją Adaptacja i zastosowanie sprawdzonych rozwiązań hiszpańskich na gruncie polskim

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja Autor: Jolanta Łabędzka-Benisz.

VENDIO SPRZEDAŻ kompleksowa obsługa sprzedaży. dcs.pl Sp. z o.o. vendio.dcs.pl info@dcs.pl Warszawa,

Monitoring procesów z wykorzystaniem systemu ADONIS

ZARZĄDZANIE ZESPOŁEM STWÓRZ ZESPÓŁ MARZEŃ CELE I KORZYŚCI SZKOLENIA: 2 dni

Zapewnij sukces swym projektom

Instrukcja. ocena aspektów środowiskowych PE-EF-P01-I01

Opis Kompetencji Portfel Interim Menedżerowie i Eksperci

Projektowanie interakcji

Proces zarządzania zasobami ludzkimi

ZARZĄDZANIE RYZYKIEM W LABORATORIUM BADAWCZYM W ASPEKCIE NOWELIZACJI NORMY PN-EN ISO/ IEC 17025:

Zarządzanie projektami a zarządzanie ryzykiem

Nowoczesny model funkcjonowania ośrodka badawczego a risk-based monitoring. Marek Konieczny Prezes Zarządu Łukasz Pulnik Partner Zarządzający

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

STRATEGICZNE MYŚLENIE - WYKORZYSTANIU NARZĘDZI IT KONTROLA ZARZĄDCZA PRZY. Szczyrk, 2-3 czerwiec 2016

Zestawy zagadnień na egzamin dyplomowy (licencjacki) dla kierunku ZARZĄDZANIE (studia I stopnia)

Staże i praktyki zagraniczne dla osób kształcących się i szkolących zawodowo

Wykład Zarządzanie projektami Zajęcia 7 Zarządzanie ryzykiem. dr Stanisław Gasik s.gasik@vistula.edu.pl

SKUTECZNE ZARZĄDZANIE PROJEKTEM

Jak przygotować dobry projekt w programie Leonardo da Vinci?

Metodyka zarządzania projektami

MANAGER INNOWACJI MODUŁY WARSZTATOWE

Transkrypt:

Ryzyko w projektach informatycznych Andrzej Kiesz Gdańsk, 26 kwietnia 2007 r.

Plan prezentacji Teoretyczne wprowadzenie do zarządzania ryzykiem na bazie metodyki PMI Omówienie zagrożeń występujących w poszczególnych obszarach zarządzania projektami informatycznymi: budowanie zespołu specyfikowanie wymagań harmonogramowanie problemy z zespołem projektowym różnorodne środowiska uruchamiania aplikacji problemy z partnerami zewnętrznymi kwestie prawne wdrożenie 2

Zarządzaj projektem, zarządzaj dzając c ryzykiem, jakie się z nim wiąż ąże. Tom de Marco Zdążyć przed terminem 3

Czym jest ryzyko? Ryzyko jest możliwością poniesienia straty Ryzyko to niepewne wydarzenie, które - jeśli zajdzie - może mieć negatywny albo pozytywny wpływ na projekt Ryzyko to niepewność wyniku (rezultatu) Wartość ryzyka w projekcie można określić jako: Prawdopodobieństwo zdarzenia x Wpływ na projekt 4

Procesy zarządzania ryzykiem wg PMI: Planowanie zarządzania ryzykiem Identyfikacja ryzyka Jakościowa analiza ryzyka Ilościowa analiza ryzyka Planowanie reakcji na ryzyko Monitorowanie i kontrola ryzyka 5

Planowanie zarządzania ryzykiem Określamy jak podchodzimy do zarządzania ryzykiem w projekcie i jak planujemy działać w tym zakresie Plan zarządzania ryzykiem obejmuje: metodyka przydział ról i odpowiedzialności budżet na zarządzanie ryzykiem realizacja procesów zarządzania ryzykiem w czasie projektu wyniki i ich interpretacja kryteria progowe raportowanie śledzenie/kontrolowanie Wynik: plan zarządzania ryzykiem 6

Identyfikacja ryzyka (1/3) Określenie jakie ryzyka mogą wpływać na projekt oraz dokumentowanie ich charakteru Kategorie ryzyka Ryzyko może e dotyczyć zasobowe harmonogramu organizacyjne zewnętrzne kosztów jakości zakresu prac zarządzania projektem zasobów satysfakcji klienta 7

Identyfikacja ryzyka (2/3) Techniki zbierania informacji: Burza mózgów (dwa etapy: zielony i czerwony) Diagram Ishikawy Listy kontrolne SWOT (ang. strengths, weaknesses, opportunities, threats) Wyniki: Lista ryzyk symptomy ryzyka 8

Identyfikacja ryzyka diagram Ishikawy (3/3) 9

Jakościowa analiza ryzyka (1/2) Subiektywna analiza prawdopodobieństwa i skutku w kategoriach intuicyjnych typu mały-duży Technika: ustalenie kilkustopniowej skali określającej poziomy prawdopodobieństwa i skutku wyznaczenie granic tolerancji ryzyka przygotowanie macierzy oceny ryzyka Wyniki: lista ryzyk uszeregowana wg priorytetów lista ryzyk wymagających dalszej analizy oraz tych o mniejszym znaczeniu 10

Jakościowa analiza ryzyka macierz ryzyka (2/2) skutek krytyczny średni nieistotny małe średnie duże prawdopodobieństwo 11

Ilościowa analiza ryzyka (1/2) Liczbowa analiza prawdopodobieństwa i konsekwencji. Techniki analizy ryzyka: Expected Monetary Value drzewo decyzyjne symulacja Monte Carlo Wyniki: lista ryzyk wg priorytetów (w ujęciu liczbowym) wyznaczenie optymalnych ścieżek dla projektu prognoza przewidywanych kosztów i harmonogramu projektu lista ryzyk o mniejszym znaczeniu 12

Ilościowa analiza ryzyka EMV w węźle decyzyjnym (2/2) Koszty Wartość sprzedaży skutek decyzja - 150 000 PLN zdarzenie A P1 = 0,2 300 000 PLN P2 = 0,6 200 000 PLN P3 = 0,2 250 000 PLN EMV(A) = - 150 000 + 0,2 * 300 000 + 0,6 * 200 000 + 0,2 * 250 000 80 000 (węzeł decyzyjny) - 200 000 PLN B C P1 = 0,4 320 000 PLN P2 = 0,5 250 000 PLN P3 = 0,1 310 000 PLN EMV(B) = - 200 000 + 0,4 * 320 000 + 0,5 * 250 000 + 0,1 * 310 000 84 000 (węzeł losowy) (węzeł informacyjny) Źródło: Jacek Jamroż 13

Planowanie reakcji na ryzyko Określenie sposobu zmniejszenia lub eliminacji ryzyka. Sposoby reakcji na ryzyko: unikanie zmiany w planie projektu transfer przesunięcie skutków ryzyka na innych (np. na firmy ubezpieczeniowe) łagodzenie ryzyka ograniczenie prawdopodobieństwa wystąpienia negatywnego zdarzenia oraz jego wpływu akceptacja ryzyka pozostawienie planu projektu bez zmiany, aktywna akceptacja ryzyka, np. przez przygotowanie środków na pokrycie strat 14

Monitoring i kontrola ryzyka ciągła obserwacja zdarzeń w kontekście ryzyka weryfikacja planu reakcji na ryzyko rozpoznanie nowych ryzyk i tworzenie dla nich nowych planów reakcji Wyniki: zmodyfikowany plan reakcji na ryzyko zmiany w projekcie 15

Zagrożenia związane z zarządzaniem ryzykiem ;) Próba identyfikacji ryzyka bez dostatecznej wiedzy na temat projektu Ogólna i szybka identyfikacja ryzyka, przy wykorzystaniu jednej metody Wyodrębnione ryzyka są zbyt ogólnie określone. Przeoczenie ukrytych zagrożeń Negatywne zdarzenie, które zajdzie na 100% to fakt, a nie ryzyko Pominięcie całych grup ryzyka, np. czynnik ludzki Brak monitoringu ryzyka podczas realizacji projektu Kluczowe ustalenia (np. dotyczące harmonogramu) zapadają zazwyczaj przed analizą ryzyka 16

Budowanie zespołu (1/4) Zagrożenia: zatrudnienie niewłaściwego kandydata podczas rekrutacji: osoba niedostatecznie bystra dobre rozwiązania są lepsze od średnich brak kompetencji brak zorientowana na cel nie ma sensu realizować zadań, które nie mają końca, określonego celu, ani praktycznego zastosowania nieodpowiednie cechy osobowe (np. konfliktowość) rewelacyjny programista, który nie potrafi współpracować z resztą zespołu przyniesie więcej szkody niż pożytku utrata bardzo dobrego kandydata podczas rekrutacji utrata pracownika niedługo po zatrudnieniu konflikty w zespole 17

Budowanie zespołu (2/4) Zapobieganie: rekrutacja: pytania pozwalające zbadać bystrość kandydata podczas rozmowy rekrutacyjnej zlecanie rozwiązywania zadań testowych w ramach rekrutacji analiza roli i zachowania kandydata podczas realizacji poprzednich projektów wywiad środowiskowy prowadzenie rozmów rekrutacyjnych przez kilka osób dopasowanie kompetencji osoby przeprowadzającej rozmowę rekrutacyjną i osoby kandydującej szybki kontakt z kandydatami, wobec których jesteśmy pewni szczera rozmowa upewnienie się, że nowy pracownik nie poszukuje w dalszym ciągu pracy, zapewnienie satysfakcjonujących obie strony warunków 18

Budowanie zespołu (3/4) Zapobieganie: budowanie zespołu z osób już zatrudnionych: nie warto niszczyć zespołów, które są zgrane należy dobrać osoby (w miarę możliwości) o odpowiednich stanowiskach i cechach osobowościowych 19

Budowanie zespołu (4/4) Lepiej odrzucić dobrego kandydata niż przyjąć kiepskiego 20

Specyfikowanie wymagań (1/3) Zagrożenia: zbyt ogólne i niejasne sformułowanie zadań różna interpretacja tych samych zapisów przez klienta i wykonawcę specyfikacja nie obejmuje wszystkich funkcjonalności ustalenia nie są rejestrowane ciągłe zmiany, brak ostatecznej wersji 21

Specyfikowanie wymagań (2/3) Zapobieganie: rozmowy z klientem przed opisaniem konkretnych funkcjonalności eliminacja wszystkich niezrozumiałych dla wykonawcy fragmentów specyfikacji tworzenie klikalnych/graficznych prototypów i włączanie ich do specyfikacji zatwierdzenie (pisemne, bądź mailowe) ostatecznej wersji specyfikacji oddzielenie funkcjonalności technicznej od funkcjonalnej 22

Specyfikowanie wymagań (3/3) Niejasna specyfikacja świadczy o nierozwiązanym zanym konflikcie między stronami zainteresowanymi budową systemu To, co zostało o zapisane to jest. To, co nie zostało o zapisane, tego nie ma 23

Harmonogramowanie (1/3) Zagrożenia: daty narzucone z góry (system został sprzedany przed analizą) strach lub ambicja prowadzące do deklaracji nierealnych terminów zbyt ogólne sformułowane zadania brak konsultacji terminów z podwykonawcami brak dostatecznej wiedzy na temat systemu, harmonogramowanie przez nieodpowiednie osoby błędne oszacowanie liczby dni pracujących 24

Harmonogramowanie (2/3) Zapobieganie: szacowanie poszczególnych zadań powinno być powierzone osobom, które faktycznie będą realizować te zadania zadania konsultacje harmonogramu ze wszystkimi zainteresowanymi analiza planów urlopowych członków zespołów, weryfikacja dni ustawowo wolnych od pracy w harmonogramowanym okresie warto poświęcić więcej czasu na dokładne projektowanie, co pozwoli zredukować czas potrzebny na usuwanie błędów duże zadania należy dzielić na kilka mniejszych rezerwacja bufora czasowego 25

Harmonogramowanie (3/3) Optymizm jest u informatyków w chorobą nieuleczalną Pamiętaj, że e każdy dzień stracony na początku projektu szkodzi tak samo, jak dzień stracony na jego końcu cu Jest nieskończenie wiele sposobów w na to, by stracić dzień... ale nie ma żadnego, by go odzyskać Dziewięć kobiet nie urodzi dziecka w 1 miesiąc 26

Problemy z zespołem projektowym (1/3) Zagrożenia: odejście z firmy cennych ludzi brak motywacji i identyfikacji z zadaniami konflikty personalne groźby jako metoda motywowania ludzi 27

Problemy z zespołem projektowym (2/3) Zapobieganie: rozmowy okresowe przydział odpowiednich zadań do poszczególnych osób podział długofalowych prac na podprojekty cel powinien być osiągalny zapewnienie poczucia bezpieczeństwa zespołowi pozwolenie na proponowanie i realizację (w odpowiednim zakresie) pomysłów swoich ludzi pozostawienie swobody członkom zespołu (wzmocnienie odpowiedzialności) warto najpierw wysłuchać, a potem mówić czujność i szybka reakcja na konflikty należy zrozumieć indywidualnie każdą osobę, jej oczekiwania i potrzeby, aby porwać za sobą cały zespół 28

Problemy z zespołem projektowym (3/3) Pamiętaj: jesteśmy obaj po tej samej stronie; to problem jest po drugiej stronie Ludzie pod presją wcale nie myślą szybciej Złość jest efektem lękul ku 29

Różnorodne środowiska uruchamiania aplikacji (1/2) Zagrożenia: błędne działanie systemów w różnych środowiskach (brak zapewnienia jakości): niejednorodne warunki sieciowe różne systemy operacyjne różne wersje przeglądarek zróżnicowanie innych środowisk uruchamiania aplikacji, np. wirtualna maszyna Javy konieczność usuwania błędów (niedotrzymanie harmonogramu) 30

Różnorodne środowiska uruchamiania aplikacji (2/2) Zapobieganie: zebranie doświadczenia od ekspertów wygospodarowanie czasu na: zbadanie zachowania się aplikacji w różnych środowiskach (testy) usuwanie błędów 31

Współpraca z partnerami zewnętrznymi (1/2) Zagrożenia: partner nie jest dostatecznie kompetentny partner nie dotrzymuje terminów problemy w komunikacji z partnerem realizacja prac bez podpisanej umowy 32

Współpraca z partnerami zewnętrznymi (2/2) Zapobieganie: weryfikacja partnera przed podpisaniem umowy umowa powinna obejmować co najmniej (np. w formie załączników): harmonogram zapisy na temat SLA (ang. service level agreement) zdefiniowane sposoby reakcji na błędy i awarie specyfikację (funkcjonalną i/lub techniczną) listę osób i odpowiadające im zakresy odpowiedzialności stałe monitorowanie postępu prac podczas realizacji projektu 33

Kwestie prawne (1/2) Zagrożenia: regulamin usługi może zmienić kształt produktu zmiana obowiązującego prawa podczas realizacji projektu problemy z licencjami do wykorzystywanych modułów lub elementów graficznych pominięcie kosztów i brak analizy problemów związanych z rejestracją znaków towarowych konstrukcja umowy o dzieło w kontekście autorskich praw majątkowych 34

Kwestie prawne (2/2) Zapobieganie: odpowiednio wczesne konsultacje z prawnikami analiza wymagań licencyjnych 35

Wdrożenie (1/3) Zagrożenia: brak oficjalnej akceptacji na wdrożenie produktu w określonym kształcie problem z dostępnością decydentów (nieobecność, brak czasu), którzy muszą wyrazić zgodę na wdrożenie (mogą je też zablokować) kłopot z dostępem do ludzi o niezbędnych kompetencjach problemy techniczne 36

Wdrożenie (2/3) Zapobieganie: wczesne przedkładanie systemów do akceptacji akceptacje tylko na piśmie lub via email nic na słowo rezerwacja czasu niezbędnych specjalistów oraz ustalanie z nimi terminów wdrożenia stworzenie planu wdrożenia krok po kroku symulacja wdrożenia (weryfikacja mechanizmów) przygotowanie planu awaryjnego 37

Wdrożenie (3/3) Nie uda się nawet wtedy, gdy właściwiew nie powinno się nie udać.. Wszystko wali się naraz. Wszystko zabiera znacznie więcej czasu, niż by się wydawało. o. 38

O czym warto pamiętać? (1/2) archiwizacja emaili, okresowy backup dysku pomysł piszemy wszystko od nowa to bardzo zły pomysł żadne zmiany nie przyniosą nagłego podniesienia wydajności, usprawnienia procesów do inwestycje długofalowe negatywne skutki układów politycznych w firmie 39

O czym warto pamiętać? (2/2) Najbardziej zabójcze dla Ciebie nie jest to, czego nie wiesz, ale to, co wydaje Ci się, że e wiesz, choć w istocie nie jest prawdą "Jeżeli eli wszystko idzie dobrze, to jest to symptom, że e będzie b źle" 40

Dziękuję za uwagę akiesz@wp-sa.pl 41