Zarządzanie Projektami

1

Krzysztof Skubis PMP®MSF Practitioner

Agenda Podstawy Zarządzania

Projektami Najpopularniejsze standardy Definicja Projektu Definicja Zarządzania Projektem (zadania) Trójkąt ograniczeń (ang. triple constraint) Cykl życia Projektu Obszary wiedzy

Microsoft Solutions Framework v.4 Główne przyczyny niepowodzeń Model Zespołu Model Zarządzania

Mentalność Podstawowe Zasady Zarządzanie procesem

Zarządzanie ryzykiem Zarządzanie gotowością

2

Standardy w Zarządzaniu ProjektamiProjects in a Controlled Environment (PRINCE 2)

• Brytyjski de facto standard• Formalny, „wodospadopodobny” (ang. „waterfall” like)• Pierwsza wersja: Simpact System Limited (około 1975

roku)• Znany jako PRINCE od roku 1989 (publikacja przez

CCTA)• PRINCE2 opublikowany w 1996, ostatnia aktualizacja:

rok 2006• http://www.prince2.com/

Project Management Book of Knowledge (PMBOK)• Zaaprobowane w USA przez ANSI jako standard

narodowy• Najlepsze praktyki - nie jest to metodyka• Opracowywany przez Project Management Institute

(PMI), 1969 • Ostatnia aktualizacja (PMBOK v.4) w roku 2008• Ponad 390000 certyfikowanych specjalistów

(październik 2010)• http://www.pmi.org/

3

Definicja Projektu

4

Projekt to czasowe przedsięwzięcie podjęte w celu stworzenia unikalnego produktu, usługi albo wyniku

Czasowe – ma początek i koniecUnikalne – nie jest prostą reprodukcją czegokolwiek istniejącego

Stopniowe uszczegółowianie – rozwijane w krokach, przyrostowo

Projekty, a Działalność Operacyjna

5

Cechy wspólne• Wykonywane przez ludzi• Ograniczone przez limitowane zasoby• Planowane, wykonywane, kontrolowane

Inne cele• Osiągnij cel i zakończ• Utrzymuj biznes

Zarządzanie ProjektemZarządzanie Projektem to zastosowanie

wiedzy, umiejętności, narzędzi i technik w ramach aktywności projektowych

w celu osiągnięcia celów projektuZadania

• Identyfikacja zadań dla aktualnego projektu• Ustanowienie jasnych i osiągalnych celów• Zbalansowanie sprzecznych oczekiwań dotyczących

jakości, zakresu, czasu oraz kosztów• Adaptacje specyfikacji, planów i sposobu realizacji do

różnych oczekiwań wszystkich współwłaścicieli (ang. stakeholders) 6

Funkcjonalność Harmonogram Zasoby

7

Gdzie jest jakość?

Trójkąt ograniczeń

Cykl życia Projektu Inicjacja

Definicja projektu Zakres prac

Część środkowa Plan Ustanowienie fundamentu Rozwój Akceptacja

Zakończenie Odbiór Przekazanie

8

Obszary wiedzy w Zarządzaniu Projektem

9

Zarządzanie Integracją Zarządzanie Zakresem Zarządzanie Czasem Zarządzanie Kosztami Zarządzanie Jakością Zarządzanie Ludźmi Zarządzanie Komunikacją Zarządzanie Ryzykiem Zarządzanie Dostawcami

Który obszar jest najważniejszy?

Pytania?

10

Agenda MSF v.4

Główne przyczyny niepowodzeń projektów IT

Model Zespołu Model Zarządzania (ang. Governance)

Mentalność (ang. Mindset) Podstawowe Zasady Zarządzanie Procesem

Zarządzanie ryzykiem Zarządzanie gotowością

11

2000 28%23% 49%

1998 26%28% 46%

1995 27%40% 33%

1994 16%31% 53%

Powyższy diagram przedstawia rezultaty 30000 projektów budowy aplikacji w dużych, średnich i małych przedsiębiorstwach w USA. Badane przez The Standish Group od roku 1994.

Źródło: The Standish Group International, “10th Annual (2003) CHAOS Report,” CHAOS Chronicles 3 (2003): 406.

UdaneWątpliweNieudane

2003 34%15% 51%

Projekty IT: Sukcesy nie przychodzą łatwo

12

Główne przeszkody

13

Utrata jasności celu biznesowego danego rozwiązania

Brak wspólnego języka Nieporozumienia Niejasne cele Zmiany zakresu

Nieumiejętność działania i komunikowania się z biznesem jako Zespół

Nieelastyczne procesy (w kontekście zmian)

Ochrona interesów (ang. advocacy)

Dostarczenie rozwiązania

Budowa rozwiązania

Testowanie

Wersja/Zarządzanie operacyjne

Edukacja użytkownika

Zarządzanie produktem

Zarządzanie programem Architektura

Projekt rozwiązania

Opis rozwiązania

Sprawdzenie rozwiązaniaUżyteczność rozwiązaniaGotowość użytkowników

Budowa i weryfikacja rozwiązania

Wdrożenie rozwiązania

Model Zespołu

14

Zespół równorzędnych partnerów

15

Zespół, w którym wszyscy są równi Każdy chroni specyficzne interesy i ma

ustalony zakres odpowiedzialności

Zwiększa uprawnienia członków zespołu w zakresie ochrony odpowiednich interesów Utrzymuje odpowiedzialność członków

zespołu za ochronę odpowiednich interesów Prowadzi do podejmowania decyzji

bazujących na powszechnej zgodzie Daje każdemu udział w sukcesie projektu

Planowanie to praca Zespołowa

16

Każda Grupa Ochrony Interesów dostraja podejście do planówTypowe Plany Wiodąca Grupa Ochrony

InteresówPlan Komunikacji Zarządzanie produktemPlan Budowy Rozwiązania Budowa rozwiązaniaPlan Szkoleń Edukacja użytkownikaPlan zapewnienia bezpieczeństwa

Budowa rozwiązaniaWersja/Zarządzanie Operacyjne

Plan Testów TestowaniePlanowany Budżet Zarządzanie programemPlan wdrożenia Wersja/Zarządzanie

OperacyjnePlan zakupów i przygotowania pomieszczeń

Wersja/Zarządzanie Operacyjne Zarządzanie programem

Plan wdrożenia pilotowego Wersja/Zarządzanie Operacyjne

Grupa Ochrony Interesów

Chroni interesy Cele jakościowe Zleceniodawca Obszar funkcjonalny

Zarządzanie produktem

Definicja rozwiązania

o Satysfakcja współwłaścicielio Zdefiniowanie rozwiązania w

ramach istniejących ograniczeń

o Współwłaściciele o Marketing/Komunikacja korporacyjna

o Analiza biznesowao Planowanie produktuo Zarządzanie wersją

Zarządzanie programem

Dostarczenie rozwiązania

o Koordynacja, identyfikacja i optymalizacji ograniczeń projektowych

o Dostarczenie rozwiązania w ramach istniejących ograniczeń projektowych

o Sponsorzy projektu o Zarządzanie projektemo Zarządzanie programemo Zarządzanie zasobamio Zapewnienie istnienia procesówo Zarządzanie jakościąo Zarządzanie operacyjne projektem

Architektura Projekt rozwiązania

Projekt rozwiązania w ramach istniejących ograniczeń

o Architekci danej technologii i rozwiązań

o Architektura rozwiązaniao Architektura technologiczna

Budowa rozwiązania Budowa i weryfikacja rozwiązania

Budowa rozwiązania zgodnie ze specyfikacją

Testowanie Sprawdzenie rozwiązania

Zatwierdzenie rozwiązania do wdrożenia tylko po upewnieniu się, że wszystkie aspekty rozwiązania osiągnęły (lub przewyższyły) odpowiednie, wcześniej zdefiniowane poziomy jakości

o Testy funkcjonalneo Testy systemu

Edukacja użytkownika Użyteczność rozwiązaniaGotowość użytkownika

o Maksymalizacja użyteczności rozwiązania

o Zwiększenie gotowości i efektywności użytkowników

o Użytkownicyo Wsparcie

operacyjneo Dostępnośćo Lokalizacja (językowa)o Komunikacje ze Wsparciem

Technicznymo Szkoleniao Użytecznośćo Projekt graficzny

Wersja / Zarządzanie operacyjne

Wdrożenie rozwiązania

Gładkie wdrożenie i przekazanie do zarządzania operacyjnego

o Zarządzanie operacyjne

o Infrastruktura związana z rozwiązaniem

o Zarządzanie operacyjneo Zarządzanie wersją (Build)o Zarządzanie wersją komercyjnąo Zarządzanie narzędziami

Atrybuty Różnych Grup Ochrony Interesów

17

Zarządzanie

Aktywności

Mentalność

Zasady

Warstwy Modelu Zarządzania

18

Mentalność: Pomaga członkom Zespołu zorientować się jak należy podchodzić do dostarczenia rozwiązania

Zasady: Radzi jak Zespół powinien ze sobą współpracować żeby dostarczyć rozwiązanie

Aktywności: Jak zrealizować rozwiązanie (process enactment)

Zarządzanie: Optymalne wykorzystanie zasobów projektowych, zbalansowanie ograniczeń projektowych i organizacja pracy w projekcie w celu dostarczenia rozwiązania

MSF-owa mentalność

19

Sprzyjaj budowie zespołu równorzędnych partnerów

Koncentruj się na wartości biznesowej Stale pamiętaj o końcowym rozwiązaniu Bądź dumny ze swojej fachowości Ucz się nieustannie Przyswajaj standardy jakości usług Praktykuj cnoty obywatelskie Dotrzymuj zobowiązań

Podstawowe Zasady MSF

20

Sprzyjaj otwartej komunikacji Pracuj na wspólną wizją Zwiększaj upoważnienia członków Zespołu Ustal jasną odpowiedzialność, ale także

współodpowiedzialność Zespołu Zwiększaj wartość stopniowo Bądź elastyczny (agile), oczekuj zmiany i

adaptuj się do zmian Inwestuj w jakość Ucz się z każdego doświadczenia Bądź Partnerem dla Klienta

Model Zarządzania MSFZarządzanie procesem (ang. Enactment Tracks)

Wdrożenie

Wizja

Planow

anie

Budowa

Stab

iliza

cja

Wizja/Zakres zatwierdzone

Plan projektu zatwierdzony

Zakres dostarczony

Gotowość wersji

zatwierdzona

Wdrożenie wersji zakończone

21

Punkt kontrolny Grupa OchronyInteresów

Wizja/zakres Zarządzanie ProduktemZatwierdzonePlan projektu Zarządzanie Programemzatwierdzony ArchitekturaZakres dostarczony Budowa rozwiązania

Edukacja użytkownikaGotowość wersji Testowaniezatwierdzona Wersja/Zarządzanie

Operacyjne

Wdrożenie wersji Wersja/Zarządzanie zakończone Operacyjne

Różne Grupy Ochrony Interesów przewodzą w różnych fazach

22

Grupa Ochrony Interesów Wizja Planowanie Budowa Stabilizacja Wdrożenie

Zarządzanie produktem

Ogólne cele Identyfikacja wymagań

Klienta Dokument wizja/zakres

Analiza wymagań biznesowych Plan komunikacji

Oczekiwania Klienta Realizacja/egzekwowanie planu komunikacji

Planowanie uruchomienia

Informacja zwrotna od Klienta, ocena, zamknięcie projektu (signoff)

Zarządzanie programem

Struktura projektu Identyfikacja graniczeń

Ogólny plan projektu Ogólny harmonogram

projektu Budżet

Zarządzanie specyfikacją funkcjonalną

Monitorowanie projektu Aktualizacja planu

Monitorowanie projektu Kompromis pomiędzy

zakresem, a ograniczeniami

Zarządzanie stabilizacją

Architektura Cel i sens przygotowania projektu technicznego (design)

Koncepcja rozwiązania

Koncepcyjny i logiczny projekt rozwiązania

Ocena technologii Specyfikacja funkcjonalna Wstępne szacunki związane z

budową rozwiązania

Ocena architektury Eliminacja problemów Porównanie rozwiązania z zakresem

Budowa rozwiązania

Prototypy Opcje związane z

technologią i budową Analiza wykonalności

Logiczny i fizyczny projekt rozwiązania

Plan i harmonogram budowy rozwiązania

Budowa rozwiązania Dokumentacja konfiguracji

Rozwiązywanie problemów

Optymalizacja rozwiązania

Rozwiązywanie problemów

Wsparcie w przypadku eskalacji

Testowanie Oczekiwania użytkowników związane z wydajnością i związane z tym uwarunkowania

Scenariusze korzystania z rozwiązania

Wymagania użytkowników Wymagania związane z

dostępnością i lokalizacją Dokumentacja dla

użytkownika, plan i harmonogram szkoleń

Szkolenia Aktualizacja planu szkoleń Testy użyteczności Projektowanie grafiki

Stabilizacja dokumentacji dla użytkownika

Materiały szkoleniowe Akceptacja

użytkowników

Szkolenia Zarządzanie

harmonogramem szkoleń

Edukacja użytkownika

Sposób testowania Kryteria akceptacji testów

Ocena projektu rozwiązania Wymagania związane z testami Plan i harmonogram testów

Testy technologiczne i testy funkcjonalne (ograniczone)

Identyfikacja problemów Sprawdzenie dokumentacji Aktualizacja planu testów

Testy funkcjonalne, systemowe i integracyjne

Raportowanie i status problemów

Testy konfiguracji

Testy wydajności Rozwiązywanie

problemów

Wersja / Zarządzanie operacyjne

Konsekwencje wdrożenia Zarządzanie operacyjne i

możliwości wsparcia Kryteria akceptacji przez

Zarządzanie Operacyjne

Ocena projektu rozwiązania Wymagania zarządzania

operacyjnego Plan i harmonogram wdrożenia

pilotowego i pełnego Definicja i budowa środowisk

projektowych

Listy kontrolne wdrożenia (checklists)

Aktualizacja planu pilota i wdrożenia

Listy kontrolne przygotowania miejsca wdrożenia (checklists)

Przygotowanie i wsparcie wdrożenia pilotowego

Planowanie wdrożenia Szkolenia zespołów

zarządzania operacyjnego i wsparcia

Zarządzane wdrożeniem w danym miejscu

Aprobata zmian

Odpowiedzialności różnych Grup Ochrony Interesów w różnych fazach projektu

23

Czas

Wersja 1

Minimalizacja ryzyk przez rozbicie dużych projektów na wiele wersji

Ro

zwią

zani

e uk

ończ

one

Wersja 2

Wersja 3

Ryzy

ko

Wie

dza

Model Zarządzania MSF zakłada iteracje

24

Podstawowe zasady iteracji

25

Twórz „żyjące” dokumenty Ustal bazę wcześnie, „zamrażaj” późno Dostarczanie wersjonowane

Stwórz strategię dostarczania wersji Stwórz plan zakładający wiele wersji Najpierw dostarczaj funkcjonalność bazową Ustalaj harmonogram bazując na ryzykach Szybko dostarczaj nowe wersje Ustanów zarządzanie konfiguracją Ustanów kontrolę zmian

Kluczowe elementy reżimu zarządzania ryzykiem

26

Załóż, że ryzyko jest nieodłączną częścią każdego projektu lub procesu

Patrz na identyfikację ryzyka jako działalność pozytywną

Najpierw identyfikuj ryzyka, potem nimi zarządzaj

Oceniaj ryzyko w sposób ciągły Zarządzaj ryzykiem proaktywnie (identyfikuj, analizuj, adresuj)

Nie oceniaj wartości projektu przez liczbę ryzyk

Analizuj i ustal priorytety

Główna lista ryzyk

Top n ryzyk

Plan i harmonogram

Identyfikuj

Opisryzyka

Kontroluj

Proces zarządzania ryzykiem

Ucz sięBaza wiedzy o ryzykach,koncepcjei procesy

Śledź i raportuj

27

Proces zarządzania gotowością

Zdefiniuj: Identyfikuj i dopasowuj wymagane kompetencje zespołu i indywidualne poziomy biegłości niezbędne do pomyślnego planowania, budowania i zarządzania rozwiązaniami

Porównaj:Porównaj obecną indywidualną gotowość z wymaganą gotowością żeby ocenić poziom rozbieżności

Zmień: Podejmij kroki żeby poprawić gotowość i zminimalizować rozbieżność pomiędzy obecną, a oczekiwaną gotowością (szkolenie/mentoring)

Oceń: Oceń efektywność wprowadzonych działań mających poprawić gotowość

WiedzaUmiejętności Uzdolnienia

Porównaj

Zmień

Zdefiniuj

Oceń

28

Pytania?

29

Zafiksowane Wybrane Dostrajalne

Zasoby

Harmonogram

Funkcjonalność

Tabela kompromisów projektu

30

Tabela kompromisów MSF to wczesna umowa pomiędzy zespołem a Klientem

Mając zafiksowany harmonogram, wybierzemy zasoby i dostroimy funkcjonalność zgodnie z potrzebami.

Standaryzacja stacji roboczychPolska

Zakres: 25000 stacji, 2000+ lokalizacji Zespół: 120+ osób, 3 Partnerów Wyzwanie: Klient/Zakres Rozwiązanie: Model Zespołu, MSF-owa

mentalność

31

Zespół równorzędnych partnerów

32

Zespół, w którym wszyscy są równi Każdy chroni specyficzne interesy i ma

ustalony zakres odpowiedzialności

Zwiększa uprawnienia członków zespołu w zakresie ochrony odpowiednich interesów

Utrzymuje odpowiedzialność członków zespołu za ochronę odpowiednich interesów

Prowadzi od podejmowania decyzji bazujących na powszechnej zgodzie

Daje każdemu udział w sukcesie projektu

MSF-owa mentalność

33

Sprzyjaj budowie zespołu równorzędnych partnerów

Koncentruj się na wartości biznesowej Stale pamiętaj o końcowym rozwiązaniu Bądź dumny ze swojej fachowości Ucz się nieustannie Przyswajaj standardy jakości usług Praktykuj cnoty obywatelskie Dotrzymuj zobowiązań

Infrastruktura PKIŁotwa

Zakres: możliwość wystawiania certyfikatów do podpisu elektronicznego dla wszystkich obywateli kraju

Zespół: 40+ osób (z 4 krajów), 2 Partnerów

Wyzwanie: kontekst polityczny/termin/zakres, różnice kulturowe

Rozwiązanie: model Zespołu, fundamentalne zasady MSF

34

Zespół równorzędnych partnerów

35

Zespół, w którym wszyscy są równi Każdy chroni specyficzne interesy i ma

ustalony zakres odpowiedzialności

Zwiększa uprawnienia członków zespołu w zakresie ochrony odpowiednich interesów

Utrzymuje odpowiedzialność członków zespołu za ochronę odpowiednich interesów

Prowadzi od podejmowania decyzji bazujących na powszechnej zgodzie

Daje każdemu udział w sukcesie projektu

Podstawowe Zasady MSF

36

Sprzyjaj otwartej komunikacji Pracuj nad wspólną wizją Zwiększaj upoważnienia członków Zespołu Ustal jasną odpowiedzialność, ale także

współodpowiedzialność Zespołu Zwiększaj wartość stopniowo Bądź elastyczny (agile), oczekuj zmiany i

adaptuj się do zmian Inwestuj w jakość Ucz się z każdego doświadczenia Bądź Partnerem dla Klienta

Więcej informacji na temat MSF:• http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx

• „Microsoft Solutions Framework essentials” (ISBN-10: 0-7356-2353-8)

• „Microsoft Solutions Framework - a pocket guide” (ISBN: 9077212167)

Informacje na temat MOF:• http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx

• „Microsoft Operations Framework – a pocket guide (ISBN: 9077212108) 37

Przygotowanie Bazowego Harmonogramu

1

2

34

5

Ustal kiedy Zadanie będzie wykonane

Proces przygotowywania harmonogramuwedług MSF

Identyfikuj zależności między

zadaniami

Identyfikuj Zadania

Oceń ilość pracy na wykonanie Zadania

Identyfikuj kto wykona Zadanie

38

Konrad Lorenc

39

Powiedziane nie jest jeszcze usłyszaneUsłyszane nie jest jeszcze zrozumianymZrozumiane nie jest jeszcze tym, z czym się zgadzamyTo z czym się zgadzamy nie jest jeszcze zastosowanymOd zastosowania czegoś raz, czy drugi jest jeszczedaleka droga do stałej praktyki

40

DziękujęDane kontaktowe:Krzysztof SkubisE-mail: skubis@skris.pl Telefon: +48 602 500 772Blog: http://skris.pl

https://www.linkedin.com/in/krzysztofskubis https://www.facebook.com/krzysztof.skubis.77 https://twitter.com/krzysztofskubis