Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 3 Zbigniew Misiak (BOC IT Consulting) zbigniew.misiak@gmail.com
Czym się będziemy zajmować? Podsumowanie spotkania 2 Co będzie na spotkaniu 4 czyli trochę o egzaminie Kontekst projektów IT z czym warto się liczyć ITIL i COBIT Co moŝemy spotkać u Klienta (SOX, Basel II i inne frameworki) Michał Kossowski
Podsumowanie spotkania 2 Wishlist: -Agile w duŝych projektach; jak współpracują ze sobą poszczególne zespoły SCRUMowe; szacowanie; współpraca zespołu programistów z PMem i klientami -Certyfikacja dla zarządzania ryzykiem w projektach i ogólnie po co certyfikaty -Info o godnych polecenia programach z róŝnych dziedzin "projektowych" np. FreeMind (do ustalania zakresu prac). -systemy zarządzania projektami/ryzykami -motywowanie zespołu projektowego -Więcej informacji na temat specyfikowania np. BPMN -zarządzanie ryzykiem a wymagania -XPRINCE -Szersze omówienie faz APM; warianty APM -więcej informacji o zarządzaniu ryzykiem w lekkich metodykach -PMBOK; metodyka PMI -szersze omówienie ryzyk w poszczególnych metodykach -Wyostrzenie kontekstu ryzyka
Agile Agile -Agile w duŝych projektach; jak współpracują ze sobą poszczególne zespoły SCRUMowe; szacowanie; współpraca zespołu programistów z PMem i klientami -więcej informacji o zarządzaniu ryzykiem w lekkich metodykach Scrum of Scrums
Metodyki Wybór metodyki zarządzania procesami Kluczowe pytanie: co to wnosi?
Metodyki Wybór metodyki zarządzania procesami Skąd jeszcze moŝna czerpać inspirację? Microsoft Solutions Framework http://www.microsoft.com/technet/itsolutions/msf/ Hermes http://www.hermes.admin.ch/ Agile Unified Process http://www.ambysoft.com/unifiedprocess/agileup.html
Metodyki Dopasowując metodykę do swoich potrzeb warto zapoznać się z dostępnymi podejściami do zarządzania projektami/zarządzania ryzykiem w projekcie Dobre źródło - agendy rządowe np.: http://srmwww.gov.bc.ca/imb/3star/sdlc/8manage/risks/r isk_principles.html
Certyfikaty PMI (CAPM, PMP, PgMP), SPMP/IPMA (IPMA A-D), OGC (PRINCE2 Foundation/Practitioner), Computing Technology Industry Association (CompTIA Project+) A nawet PTI ;) http://www.pti.org.pl/certyfikaty/index.php Co to daje? $$$ Wiarygodność Wspólny język (z punktu widzenia organizacji)
Narzędzia IT Dla zespołu Wsparcie komunikacji (lokalne vs. zdalne) Mind Mapping
Motywowanie zespołu Spełnienie osobistych celów Zaufanie Rozwój Satysfakcja
Modelowanie dla specyfikacji Kryptoreklama ;) http://www.bocpl.com/specyfikacja_systemow_it_w_systemie_adonis. pdf Dla równowagi dobre wprowadzenie do BPMN: http://www.mgx.com.pl Ogólne zasady modelowania na potrzeby specyfikacji Agile Modeling: http://www.agilemodeling.com/principles.htm
Modelowanie dla specyfikacji Agile Modeling (Scott Ambler): Assume Simplicity Embrace Change Enabling the Next Effort is Your Secondary Goal Incremental Change Maximize Stakeholder ROI Model With a Purpose Multiple Models Quality Work Rapid Feedback Working Software Is Your Primary Goal Travel Light Content is More Important Than Representation Open and Honest Communication
Co na spotkaniu 4 Propozycja: Krótkie powtórzenie najwaŝniejszych zagadnień Test (10 pytań 20 minut) Omówienie wybranych przez Państwa zagadnień
Test Przykład: Pytanie 1 Zagadnienia: Harmonogram projektu Integracja zespołu projektowego Wymienność ludzi
Test Razem z zespołem właśnie skończyliście szacowanie pracochłonności nowego projektu. Twój projekt ma juŝ doświadczenia z projektami programistycznymi tego typu, więc w oparciu o dane z poprzednich projektów udało się ustalić, Ŝe na 90% skończycie w 8 miesięcy, a na 100% w 9 miesięcy. Wariant najbardziej optymistyczny to 7 miesięcy. Gdy zakomunikowałeś to swojemu szefowi wyraźnie sposępniał. Hmmmm Nie myślałem, Ŝe to zajmie aŝ tak długo i obiecałem klientowi, Ŝe będzie to za 3 miesiące. Mam pomysł - mamy sporo praktykantów z nowej rekrutacji. Jeśli dostaniesz 3 razy większy zespół to dasz radę?. Abstrahując od kwestii politycznych - czy mówisz: (Tak) zgodzisz się na skrócenie terminu i przyjęcie praktykantów (nie znasz tych ludzi, ale wiesz, Ŝe znajomość potrzebnej do tego projektu technologii nie jest zbyt powszechna) w nadziei, Ŝe więcej osób pozwoli szybciej zakończyć projekt (Nie) tłumaczysz, Ŝe większy zespół nie oznacza, Ŝe szybciej skończycie i proponujesz rozwiązanie, które pozwoli dostarczyć klientowi przynajmniej część potrzebych funkcjonalności w 3 miesiące, co pozwoli szefowi zachować twarz, Twojemu zespołowi oszczędzi niepotrzebnego stresu, a firmie na dłuŝszą metę utraty reputacji terminowych i solidnych dostawców
Kontekst projektów IT Gorący temat IT-business alignment Co moŝe wpływać na nasze projekty? Po co nam frameworki?
ITIL Information Technology Infrastructure Library OCG - http://www.itil-officialsite.com Najnowsza wersja v.3 Biblioteka dobrych praktyk dla zarządzania usługami IT Cel: dopasowanie IT do celów biznesowych Korzyści: Obie strony wiedzą czego się spodziewać Minimalizacja ryzyka, Ŝe zmiany inicjowane przez IT nie dostarczą wartości biznesowi Minimalizacja kosztów
ITIL Service Strategy Service Design Service Transition Service Operations Continual Service Improvement
ITIL Co to zmienia z punktu widzenia projektów IT? Wytyczne są w duŝym stopniu uniwersalne: Dokumentacja kluczowych decyzji Stosowanie technik optymalizacji ryzyka Tworzenie wartości w oparciu o potrzeby Klienta Techniki analizy wpływu zmian Usługa zamiast technologii Powiązanie Change Management z projektami
ITIL Źródło: ITIL Service Transition
ITIL Źródło: ITIL Service Transition
COBIT Control Objectives for Information and related Technology ISACA & ITGI - www.isaca.org/cobit.htm Najnowsza wersja 4.1 Zestaw dobrych praktyk z zakresu IT governance Silny nacisk na kontrolę Cel: zapewnienie ładu IT Korzyści: IT tworzy wartość poprzez wspieranie biznesu System kontroli zapewnia, Ŝe organizacja nie zostanie zaskoczona przez ryzyka IT
COBIT Kostka COBIT Źródło: COBIT 4.1
COBIT 4 domeny Źródło: COBIT 4.1 PO w jaki sposób IT przekłada się na realizację strategii organizacji AI włączanie IT w procesy biznesowe (w tym nowe projekty IT) DS zapewnianie wsparcia dla biznesu przez IT ME regularna ocena paramterów procesów IT pod względem spełniania stawianych im wymagań
COBIT 34 generyczne procesy IT Źródło: COBIT 4.1
COBIT 34 generyczne procesy IT Źródło: COBIT 4.1
COBIT 34 generyczne procesy IT Źródło: COBIT 4.1
COBIT 34 generyczne procesy IT Źródło: COBIT 4.1
COBIT Procesy są analizowane pod względem dojrzałości z wykorzystaniem następującej skali: 0 - Brak 1 Inicjalny/Ad hoc 2 Powtarzalny ale intuicyjny 3 Zdefiniowany 4 Zarządzany i mierzony 5 - Zoptymalizowany Źródło: COBIT 4.1
COBIT Stan idealny: Procesy IT ulegają ciągłemu doskonaleniu IT zapewnia narzędzia, które pozwalają biznesowi szybkie reagowanie na zmiany Strategia IT jest dostosowana do strategii organizacji Istnieje sprawna komunikacja między IT i biznesem Źródło: COBIT 4.1
COBIT Jak COBIT moŝe pomóc w zarządzaniu projektami? Procesy IT opisane w dokumentacji COBIT są mierzone za pomocą celów kontroli, które pozwalają na ocenę aktualnego stanu rzeczy Przykład: dokumentacja COBIT dla zarządzania projektami (PO 10)
Kontekst projektów IT Z czym jeszcze moŝemy się spotkać, czyli więcej o frameworkach i systemie kontroli organizacji (ICS) oraz o tym jak się to przekłada na wymagania wobec IT Michał Kossowski
Podsumowanie Ewaluacja Materiały do wykładu: http://ryzyko.wordpress.com/
Podsumowanie Dziękuję Pytania? Uwagi? zbigniew.misiak@gmail.com