ݺߣ

ݺߣShare a Scribd company logo

Wstęp do Zarządzania Projektami

•Download as PPTX, PDF•
•
Krzysztof Skubis
Krzysztof Skubis

Czym jest projekt? Czym zajmuje sie Kierownik Projektu? Różne metodyki prowadzenia projektu. Microsoft Solution Framework. Jest to prezentacja, która została zaprezentowana na spotkaniu dla Polskiego Związku Szachowego.

1 of 40
Downloaded 13 times
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 Projektami Projects 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 koniec Unikalne – 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 Projektem Zarządzanie Projektem to zastosowanie wiedzy, umiejętności, narzędzi i technik w ramach aktywności projektowych w celu osiągnięcia celów projektu Zadania • 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ązania Gotowość 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ów Typowe Plany Wiodąca Grupa Ochrony Interesów Plan Komunikacji Zarządzanie produktem Plan Budowy Rozwiązania Budowa rozwiązania Plan Szkoleń Edukacja użytkownika Plan zapewnienia bezpieczeństwa Budowa rozwiązania Wersja/Zarządzanie Operacyjne Plan Testów Testowanie Planowany Budżet Zarządzanie programem Plan wdrożenia Wersja/Zarządzanie Operacyjne Plan 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ścicieli o Zdefiniowanie rozwiązania w ramach istniejących ograniczeń o Współwłaściciele o Marketing/Komunikacja korporacyjna o Analiza biznesowa o Planowanie produktu o 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 projektem o Zarządzanie programem o Zarządzanie zasobami o Zapewnienie istnienia procesów o 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ązania o 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 funkcjonalne o Testy systemu Edukacja użytkownika Użyteczność rozwiązania Gotowość użytkownika o Maksymalizacja użyteczności rozwiązania o Zwiększenie gotowości i efektywności użytkowników o Użytkownicy o Wsparcie operacyjne o Dostępność o Lokalizacja (językowa) o Komunikacje ze Wsparciem Technicznym o Szkolenia o 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 operacyjne o 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 MSF Zarządzanie procesem (ang. Enactment Tracks) Wizja/Zakres zatwierdzone Plan projektu zatwierdzony Zakres dostarczony Gotowość wersji zatwierdzona Wdrożenie wersji zakończone 21
Punkt kontrolny Grupa Ochrony Interesów Wizja/zakres Zarządzanie Produktem Zatwierdzone Plan projektu Zarządzanie Programem zatwierdzony Architektura Zakres dostarczony Budowa rozwiązania Edukacja użytkownika Gotowość wersji Testowanie zatwierdzona 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 Rozwiązanieukończone Wersja 2 Wersja 3 Ryzyko Wiedza 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 Opis ryzyka Kontroluj Proces zarządzania ryzykiem Ucz się Baza wiedzy o ryzykach, koncepcje i 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ść Wiedza Umieję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 roboczych Polska  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/solutionacceler ators/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/solutionacceler ators/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 harmonogramu wedł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łyszane Usłyszane nie jest jeszcze zrozumianym Zrozumiane nie jest jeszcze tym, z czym się zgadzamy To z czym się zgadzamy nie jest jeszcze zastosowanym Od zastosowania czegoś raz, czy drugi jest jeszcze daleka droga do stałej praktyki
Dane kontaktowe: Krzysztof Skubis E-mail: skubis@skris.pl Telefon: +48 602 500 772 Blog: http://skris.pl https://www.linkedin.com/in/krzysztofskubis https://www.facebook.com/krzysztof.skubis.77 https://twitter.com/krzysztofskubis 40

More Related Content

Wstęp do Zarządzania Projektami

  • 2. 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
  • 3. Standardy w Zarządzaniu Projektami Projects 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
  • 4. 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 koniec Unikalne – nie jest prostą reprodukcją czegokolwiek istniejącego Stopniowe uszczegółowianie – rozwijane w krokach, przyrostowo
  • 5. 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
  • 6. Zarządzanie Projektem Zarządzanie Projektem to zastosowanie wiedzy, umiejętności, narzędzi i technik w ramach aktywności projektowych w celu osiągnięcia celów projektu Zadania • 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
  • 7.  Funkcjonalność  Harmonogram  Zasoby 7 Gdzie jest jakość? Trójkąt ograniczeń
  • 8. Cykl życia Projektu  Inicjacja  Definicja projektu  Zakres prac  Część środkowa  Plan  Ustanowienie fundamentu  Rozwój  Akceptacja  Zakończenie  Odbiór  Przekazanie 8
  • 9. 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?
  • 11. 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
  • 12. 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
  • 13. 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)
  • 14. 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ązania Gotowość użytkowników Budowa i weryfikacja rozwiązania Wdrożenie rozwiązania Model Zespołu 14
  • 15. 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
  • 16. Planowanie to praca Zespołowa 16 Każda Grupa Ochrony Interesów dostraja podejście do planów Typowe Plany Wiodąca Grupa Ochrony Interesów Plan Komunikacji Zarządzanie produktem Plan Budowy Rozwiązania Budowa rozwiązania Plan Szkoleń Edukacja użytkownika Plan zapewnienia bezpieczeństwa Budowa rozwiązania Wersja/Zarządzanie Operacyjne Plan Testów Testowanie Planowany Budżet Zarządzanie programem Plan wdrożenia Wersja/Zarządzanie Operacyjne Plan zakupów i przygotowania pomieszczeń Wersja/Zarządzanie Operacyjne Zarządzanie programem Plan wdrożenia pilotowego Wersja/Zarządzanie Operacyjne
  • 17. Grupa Ochrony Interesów Chroni interesy Cele jakościowe Zleceniodawca Obszar funkcjonalny Zarządzanie produktem Definicja rozwiązania o Satysfakcja współwłaścicieli o Zdefiniowanie rozwiązania w ramach istniejących ograniczeń o Współwłaściciele o Marketing/Komunikacja korporacyjna o Analiza biznesowa o Planowanie produktu o 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 projektem o Zarządzanie programem o Zarządzanie zasobami o Zapewnienie istnienia procesów o 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ązania o 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 funkcjonalne o Testy systemu Edukacja użytkownika Użyteczność rozwiązania Gotowość użytkownika o Maksymalizacja użyteczności rozwiązania o Zwiększenie gotowości i efektywności użytkowników o Użytkownicy o Wsparcie operacyjne o Dostępność o Lokalizacja (językowa) o Komunikacje ze Wsparciem Technicznym o Szkolenia o 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 operacyjne o Zarządzanie wersją (Build) o Zarządzanie wersją komercyjną o Zarządzanie narzędziami Atrybuty Różnych Grup Ochrony Interesów 17
  • 18. 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
  • 19. 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ń
  • 20. 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
  • 21. Model Zarządzania MSF Zarządzanie procesem (ang. Enactment Tracks) Wizja/Zakres zatwierdzone Plan projektu zatwierdzony Zakres dostarczony Gotowość wersji zatwierdzona Wdrożenie wersji zakończone 21
  • 22. Punkt kontrolny Grupa Ochrony Interesów Wizja/zakres Zarządzanie Produktem Zatwierdzone Plan projektu Zarządzanie Programem zatwierdzony Architektura Zakres dostarczony Budowa rozwiązania Edukacja użytkownika Gotowość wersji Testowanie zatwierdzona 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
  • 23. 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
  • 24. Czas Wersja 1 Minimalizacja ryzyk przez rozbicie dużych projektów na wiele wersji Rozwiązanieukończone Wersja 2 Wersja 3 Ryzyko Wiedza Model Zarządzania MSF zakłada iteracje 24
  • 25. 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
  • 26. 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
  • 27. Analizuj i ustal priorytety Główna lista ryzyk Top n ryzyk Plan i harmonogram Identyfikuj Opis ryzyka Kontroluj Proces zarządzania ryzykiem Ucz się Baza wiedzy o ryzykach, koncepcje i procesy Śledź i raportuj 27
  • 28. 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ść Wiedza Umiejętności Uzdolnienia Porównaj Zmień Zdefiniuj Oceń 28
  • 30. 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.
  • 31. Standaryzacja stacji roboczych Polska  Zakres: 25000 stacji, 2000+ lokalizacji  Zespół: 120+ osób, 3 Partnerów  Wyzwanie: Klient/Zakres  Rozwiązanie: Model Zespołu, MSF-owa mentalność 31
  • 32. 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
  • 33. 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ń
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. Więcej informacji na temat MSF: •http://www.microsoft.com/technet/solutionacceler ators/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/solutionacceler ators/cits/mo/mof/default.mspx •„Microsoft Operations Framework – a pocket guide (ISBN: 9077212108) 37
  • 38. Przygotowanie Bazowego Harmonogramu 1 2 34 5 Ustal kiedy Zadanie będzie wykonane Proces przygotowywania harmonogramu według MSF Identyfikuj zależności między zadaniami Identyfikuj Zadania Oceń ilość pracy na wykonanie Zadania Identyfikuj kto wykona Zadanie 38
  • 39. Konrad Lorenc 39 Powiedziane nie jest jeszcze usłyszane Usłyszane nie jest jeszcze zrozumianym Zrozumiane nie jest jeszcze tym, z czym się zgadzamy To z czym się zgadzamy nie jest jeszcze zastosowanym Od zastosowania czegoś raz, czy drugi jest jeszcze daleka droga do stałej praktyki
  • 40. Dane kontaktowe: Krzysztof Skubis E-mail: skubis@skris.pl Telefon: +48 602 500 772 Blog: http://skris.pl https://www.linkedin.com/in/krzysztofskubis https://www.facebook.com/krzysztof.skubis.77 https://twitter.com/krzysztofskubis 40