Wsparcie narzędziowe zarządzania ryzykiem w projektach. Spotkanie 3 Zbigniew Misiak (BOC IT Consulting)

Transkrypt

1 Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 3 Zbigniew Misiak (BOC IT Consulting) zbigniew.misiak@gmail.com

2 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

3 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

4 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

5 Metodyki Wybór metodyki zarządzania procesami Kluczowe pytanie: co to wnosi?

6 Metodyki Wybór metodyki zarządzania procesami Skąd jeszcze moŝna czerpać inspirację? Microsoft Solutions Framework Hermes Agile Unified Process

7 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.: isk_principles.html

8 Certyfikaty PMI (CAPM, PMP, PgMP), SPMP/IPMA (IPMA A-D), OGC (PRINCE2 Foundation/Practitioner), Computing Technology Industry Association (CompTIA Project+) A nawet PTI ;) Co to daje? $$$ Wiarygodność Wspólny język (z punktu widzenia organizacji)

9 Narzędzia IT Dla zespołu Wsparcie komunikacji (lokalne vs. zdalne) Mind Mapping

10 Motywowanie zespołu Spełnienie osobistych celów Zaufanie Rozwój Satysfakcja

11 Modelowanie dla specyfikacji Kryptoreklama ;) pdf Dla równowagi dobre wprowadzenie do BPMN: Ogólne zasady modelowania na potrzeby specyfikacji Agile Modeling:

12 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

13 Co na spotkaniu 4 Propozycja: Krótkie powtórzenie najwaŝniejszych zagadnień Test (10 pytań 20 minut) Omówienie wybranych przez Państwa zagadnień

14 Test Przykład: Pytanie 1 Zagadnienia: Harmonogram projektu Integracja zespołu projektowego Wymienność ludzi

15 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

16 Kontekst projektów IT Gorący temat IT-business alignment Co moŝe wpływać na nasze projekty? Po co nam frameworki?

17 ITIL Information Technology Infrastructure Library OCG - 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

18 ITIL Service Strategy Service Design Service Transition Service Operations Continual Service Improvement

19 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

20 ITIL Źródło: ITIL Service Transition

21 ITIL Źródło: ITIL Service Transition

22 COBIT Control Objectives for Information and related Technology ISACA & ITGI - 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

23 COBIT Kostka COBIT Źródło: COBIT 4.1

24 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ń

25 COBIT 34 generyczne procesy IT Źródło: COBIT 4.1

26 COBIT 34 generyczne procesy IT Źródło: COBIT 4.1

27 COBIT 34 generyczne procesy IT Źródło: COBIT 4.1

28 COBIT 34 generyczne procesy IT Źródło: COBIT 4.1

29 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

30 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

31 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)

32 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

33 Podsumowanie Ewaluacja Materiały do wykładu:

34 Podsumowanie Dziękuję Pytania? Uwagi?