Składowe zespołu projektowego. 1. MenedŜer projektu 2. Zespół podstawowy 3. Pracownicy na zlecenie

Transkrypt

1 Zespół projektowy

2 Składowe zespołu projektowego 1. MenedŜer projektu 2. Zespół podstawowy 3. Pracownicy na zlecenie

3 MenedŜer projektu cechy 1. Wiedza i doświadczenie 2. Umiejętności przywódcze 3. Umiejętności interpersonalne 4. Umiejętności menedŝerskie 5. Umiejętności techniczne

4 MenedŜer projektu a kierownik liniowy 1. Zespół projektowy pochodzi w większości z komórek firmy kierowanych przez kierowników liniowych 2. MenedŜer projektu cel: ukończenie projektu w wyznaczonym terminie, bez przekraczania budŝetu, zgodnie ze specyfikacją 3. Kierownik liniowy jeden z celów: rozwijanie podnoszenie kwalifikacji pracowników 4. Potencjalny konflikt rozwijanie kwalifikacji nie jest celem menedŝera projektu: a) menedŝer projektu oczekuje doświadczonych pracowników b) kierownik liniowy chętnie przydzieli pracowników, dla zdobycia przez nich nowych umiejętności

5 Dobór członków podstawowego zespołu projektowego Cechy członków zespołu projektowego 1. ZaangaŜowanie 2. Elastyczność 3. Umiejętność pracy w trybie zadaniowym 4. Zdolność do pracy zgodnie z harmonogramem 5. Umiejętność wspierania innych i korzystania ze wsparcia 6. Myślenie w kategoriach zespołu

6 Zlecenia zewnętrzne Rodzaje ryzyka związane ze zleceniami zewnętrznymi: 1. Priorytety członków zespołu pracujących na zlecenie mogą leŝeć poza projektem zaangaŝowanie nie będzie pełne 2. Jakość pracy moŝe być niska chęć ukończenia zlecenia i podjęcie następnego 3. Członkowie zespołu pracujący na zlecenie nie będą dobrze zorientowani, jak ich działania są powiązane z innymi działaniami 4. Utrudnione monitorowanie postępu prac

7 Zlecenia zewnętrzne Zawartość umowy: 1. Opis zadania 2. Wytyczne dotyczące wykonania zadania 3. Jakość wykonania 4. Termin 5. Zakres odpowiedzialności stron 6. Wynagrodzenie 7. Kary za opóźnienia 8. Premie za wcześniejsze wykonanie 9. Metody monitorowania zaawansowania 10.Procedury wprowadzania zmian do zadania 11.Warunki zamknięcia zadania 12.Warunki odstąpienia od umowy

8 Typowe sytuacje występujące w zespole projektowym 1. Pokonywanie problemów 2. Podejmowanie decyzji 3. Rozwiązywanie konfliktów 4. Budowanie konsensusu 5. Burza mózgów 6. Spotkania zespoły

9 Pokonywanie problemów Etapy pokonywania problemów Lp. Opis 1 Definiowanie problemu 2 Łączenie właściwych informacji 3 Generowanie pomysłów (np. burza mózgów) 4 Ocena pomysłów 5 Tworzenie planu wdrożenia rozwiązania

10 Podejmowanie decyzji Etapy podejmowania decyzji Lp. Opis 1 Definiowanie sytuacji opisanie sytuacji i uzgodnienie czego ma dotyczyć decyzja 2 Stworzenie listy możliwych decyzji (np. burza mózgów) 3 Przekształcenie pomysłów w praktyczne rozwiązania 4 Przygotowanie i wdrożenie planu działania 5 Ocenianie podjętej decyzji 6 Ocenianie rezultatów i procesu podjęcia dycyzji

11 Rozwiązywanie konfliktów Konflikty pojawiają się, gdy kilku członków zespołu ma sprzeczne opinie Style rozwiązywania konfliktów: 1. Unikanie ukrywanie własnych przekonań w celu uniknięcia konfrontacji w zespole niedopuszczalne; kaŝdego członka zespołu skłonić do przedstawieniea swoich poglądów 2. Walka najgorsze rozwiązanie; naleŝy zidentyfikować konfliktowych członków zespołu i ograniczyć prawdopodobieństwo wystąpienia zatargów 3. Współpraca próba doprowadzenia do sytuacji, w której skonfliktowane strony podejmą współpracę

12 Budowanie konsensusu Wspólne podjęcie decyzji i zaplanowanie zadania wszyscy członkowie zespołu nie mają większych wątpliwości co do podjętych decyzji KaŜdy członek zespołu powinie przedstawić swój osąd

13 Burza mózgów Technika odkrywania rozwiązań w drodze twórczego myślenia. 1. Grupa podsuwa pomysły jeden pod drugim w luźnym ciągu logicznym. Nawet najbardziej absurdalne pomysły nie mogą są krytykowane 2. Dyskusja nad pomysłami, zebranie opinii 3. Ewolucja pomysłów, próby połączenia róŝnych pomysłów 4. Ocena pomysłów 5. Wybór

14 Spotkania zespołu 1. Cele spotkań: a) definiowane problemów b) znajdowanie rozwiązań c) planowanie prac d) podejmowanie decyzji e) kontrola i monitoring 2. Problemy a) częstotliwość b) plan spotkania c) koordynacja spotkania d) protokoły ze spotkania współtworzone przez uczestników

15 Komunikacja w zespole kanały komunikacyjne 1. Spotkania bezpośrednie a) zalety: natychmiastowe uzyskiwanie odpowiedzi, moŝliwość obserwacji sygnałów niewerbalnych b) wady: czasochłonne 2. Wideokonferencje a) zalety: natychmiastowe uzyskiwanie odpowiedzi, w pewnej mierze moŝliwość obserwacji sygnałów niewerbalnych b) wady: czasochłonne

16 Komunikacja w zespole kanały komunikacyjne 3. Telefon a) zalety: natychmiastowe uzyskiwanie odpowiedzi, b) wady: brak moŝliwości obserwacji sygnałów niewerbalnych, ryzyko niedodzwonienia się 4. a) zalety: pochłaniający mało czasu b) wady: opóźniona odpowiedź, brak moŝliwości obserwacji sygnałów niewerbalnych, ryzyko utopienia w setkach innych maili 5. Komunikatory a) zalety: zazwyczaj natychmiastowe uzyskiwanie odpowiedzi b) wady: brak moŝliwości obserwacji sygnałów niewerbalnych, stosunkowo czasochłonne

17 Komunikacja w zespole kanały komunikacyjne 6. Materiały pisane a) zalety: uŝycie tej formy wskazuje na wagę informacji b) wady: ryzyko odłoŝenia na półkę, długi czas przygotowywania i dystrybucji

18 Komunikacja poza zespołem 1. MenedŜer projektu odpowiada za komunikację z nadzorującymi projekt 2. Osoby nadzorujące mają prawo Ŝądać dowolnych informacji 3. Zniekształcanie informacji przekazywanych nadzorującym projekt i klientom zamienia informacje w dobre informacje 4. Zniekształcanie czy wstrzymywanie informacji nie przynosi Ŝadnych korzyści

19 Co po tej części wykładu student powinien umieć 1. Wymienić składowe zespołu projektowego 2. Wskazać cechy skutecznych menedŝerów projektu 3. Wyjaśnić zaleŝności między menedŝerem projektu a kierownikiem liniowym 4. Wskazać cechy skutecznych członków zespołu projektowego 5. Przedstawić typowe elementu umowy z członkiem zespołu działającym na zlecenie 6. Omówić typowe sytuacje występujące w zespole projektowym 7. Omówić wady i zalety róŝnych kanałów komunikacji w zespole

20 Monitorowanie i kontrola

21 Realizacja projektu z punktu widzenia menedŝera projektu 1. Monitorowanie i kontrola przebiegu projektu 2. Wykrywanie odchyleń od planu (harmonogramu, budŝetu) i wprowadzanie działań regulujących 3. Wprowadzanie zmian do projektu 4. Zarządzanie problemami

22 Realizacja planu projektu 1. Plan projektu to pewien układ znajdujący się w równowadze (zakres projektu, jakość, budŝet, zasobu, czas patrz złoty trójkąt projektu) 2. Układ moŝe zostać wytrącony z równowagi na wiele sposobów, np. a) zmiana warunków satysfakcji zazwyczaj zmiana zakresu projektu b) niedoszacowanie kosztów lub czasu trwania działań c) opóźnienia w realizacji projektu d) itd. 3. Stan zaawansowania projektu powinien być monitorowany

23 Narzędzia wykorzystywane przy monitorowaniu i kontroli 1. Raporty 2. Kamienie milowe trend 3. Krzywa S 4. Wskaźniki kosztów i wydajności 5. Spotkania monitorujące

24 Raporty cele 1. Wczesne wykrywanie odchyleń od planu 2. Monitorowanie wydajności pracy 3. Wczesne podejmowanie działań korygujących 4. Zapobieganie sytuacji, w której projekt wymyka się spod kontroli

25 Poziom kontroli 1. Wysoki poziom kontroli duŝo, często tworzonych raportów wyŝsze koszty niŝsze ryzyko przeoczenia niekorzystnych zjawisk 2. Niski poziom kontroli niewielka liczba raportów niŝsze koszty większe ryzyko przeoczenia niekorzystnych zjawisk i wyŝsze koszty likwidacji ich skutków

26 Ustalanie poziomu kontroli koszty poziom kontroli ryzyko

27 Ustalanie poziomu kontroli 1. Poziom kontroli nie musi być identyczny dla wszystkich działań w projekcie 2. Biorąc pod uwagę termin realizacji wysoki poziom kontroli powinien dotyczyć działań znajdujących się na ścieŝce krytycznej projektu i ścieŝkach bliskich ścieŝce krytycznej Im większy zapas czasu, tym poziom kontroli moŝe być niŝszy 3. Biorąc pod uwagę koszty wysoki poziom kontroli powinien dotyczyć działań stanowiących znaczące pozycje w budŝecie 4. Biorąc pod uwagę zasoby wysoki poziom kontroli powinien dotyczyć działań związanych z wykorzystaniem zasobów unikalnych i trudno dostępnych, a takŝe działań poprzedzających wykorzystanie takich zasobów

28 System raportowania cechy System raportowania powinien: 1. dostarczać aktualne i niezbędne informacji o stanie projektu 2. generować sygnały ostrzegawcze przed pojawiającymi się problemami 3. być zrozumiałym i akceptowanym przez zespół projektowy 4. nie powodować nadmiernego wzrostu kosztów

29 Postać raportów 1. Nie istnieje skodyfikowana postać raportów o realizacji projektu 2. O postaci raportu decyduje menedŝer projektu 3. W raportach naleŝy podawać przede wszystkim wartości liczbowe (np. procent zaawansowania ze wskazaniem miary, odchylenia od harmonogramu, odchylenia od budŝetu) 4. Zazwyczaj podstawowa część raportu ma postać tabelaryczną i/lub graficzną wykres

30 Klasyfikacja raportów Ze względu na treść: 1. Raporty bieŝące 2. Raporty skumulowane 3. Raporty o odchyleniach Ze względu na przeznaczenie: 1. dla menedŝerów działań 2. dla menedŝera projektu 3. dla nadzorujących projekt

31 Raporty bieŝące 1. Raporty obejmują tylko ostatni okres sprawozdawczy dotyczą działań, które zostały rozpoczęte, zakończone lub teŝ trwały w ostatnim okresie. 2. Powinny teŝ zawierać informację o działaniach, które miały zostać rozpoczęte, zakończone lub teŝ miały trwać w ostatnim okresie, a z róŝnych przyczyn do tego nie doszło (odchylenia od planu) 3. W przypadku wystąpienia odchyleń od planu naleŝy wskazać przyczyny, skutki i ewentualne działania korygujące

32 Raporty skumulowane 1. Raporty skumulowane zawierają historię projektu (lub działania) od początku realizacji projektu (działania) do końca okresu sprawozdawczego 2. Raporty skumulowane pokazują nie tylko bieŝący stan projektu, ale takŝe trendy zachodzące przy realizacji projektu (np. narastanie opóźnienia)

33 Raporty o odchyleniach 1. Raporty o odchyleniach przedstawiają wyłącznie informacje o odchyleniach od planu (harmonogramu, budŝetu) 2. Raport ma zazwyczaj postać tabelaryczną a) działanie b) wartość planowana c) wartość rzeczywista d) róŝnica

34 Raporty ze względu na przeznaczenie 1. Raporty kierowane do menedŝerów działań wysoki poziom szczegółowości 2. Raporty kierowane do menedŝera projektu raporty o działaniach powinny pokazywać wpływ realizacji działania na realizację całego projektu 3. Raporty kierowane do nadzorujących projekt krótkie, podsumowujące wykonaną pracę w działaniach wchodzących w skład projektu, występujących odchyleniach i działaniach korygujących

35 Aktualność i rzetelność informacji 1. Informacje w raportach powinny być aktualne menedŝer projektu ustala częstotliwość składania raportów, najlepiej w postaci: data (i godzina) 2. Informacje w raportach powinny być rzetelne naleŝy na to uczulić raportujących częstym zjawiskiem jest pułapka nadziei ukrywanie opóźnień w nadziei, Ŝe w przyszłości uda się je nadrobić. W przypadku istnienie ryzyka pułapki nadziei moŝliwa jest kontrola raportów, nie tylko ich akceptacja

36 Kamienie milowe pojęcie 1. Kamienie milowe to sytuacje (zdarzenia) powstałe jako rezultat zakończenia pewnej liczby działań 2. Kamienie milowe podsumowują etapy pracy nad projektem (np. dla budynku moŝe to być stan surowy zamknięty) 3. Osiągnięcie kamienia milowego zazwyczaj warunkuje przejście do kolejnych działań 4. Kamienie milowe ustala się (data) na etapie tworzenia planowania 5. Kamienie milowe powinny być rozmieszczone w moŝliwie równych odstępach czasu 6. Kamienie milowe stanowią punkty kontrolne w realizacji projektu 7. Badanie odchyleń kamieni milowych od planu pozwala na wykrywanie trendów w realizacji projektu

37 Kamienie milowe A B C D E F G H I

38 Kamienie milowe sposób wykorzystania wyprzedzenie opóźnienie kamień milowy

39 Przebieg normalny wyprzedzenie opóźnienie kamień milowy

40 Narastające opóźnienie wyprzedzenie opóźnienie kamień milowy

41 Gwałtowne odchylenia wyprzedzenie opóźnienie kamień milowy

42 Zmiana harmonogramu wyprzedzenie opóźnienie kamień milowy

43 Krzywa S wykorzystanie 1. Krzywa S prezentuje stopień zaawansowania prac, często wyraŝone w jednostkach pienięŝnych 2. Obok krzywej planowanej nanosi się jedną lub kilka krzywych rzeczywistych

44 Krzywa S wykorzystanie zaawansowanie plan odchylenie wykonanie czas

45 Wskaźniki kosztów i wydajności 1. Wartość planowana (PV Planned Value) zaplanowany koszt pracy 2. Wartość uzyskana (EV Earned Value) planowany koszt rzeczywiście wykonanej pracy 3. Koszt rzeczywisty (AC Actual Cost) rzeczywisty koszt rzeczywiście wykonanej pracy 4. Odchylenie harmonogramu (SV Schedule Variance) róŝnica między EV i PV; jeŝeli jest ujemna wskazuje na opóźnienie harmonogramu 5. Odchylenie kosztu (CV Cost Variance) róŝnica między AC i EV; jeŝeli jest dodatnia wskazuje na przekroczenie budŝetu

46 Wskaźniki kosztów i wydajności (przykład) 1. W określonym terminie naleŝało zakończyć pięć działań, kaŝde o wartości 100. Zatem wartość planowana (PV) w tym momencie wynosi Wykonano cztery działania, zatem wartość uzyskana (EV) wynosi w tym momencie 400. Odchylenie harmonogramu SV = EV PV jest ujemne, zatem mamy do czynienia z opóźnieniem harmonogramu 3. Z kaŝdym z zakończonych działań związane były koszty w wysokości 120. Odchylenie kosztów CV = AC EV jest dodatnie zatem mamy do czynienia takŝe z przekroczeniem budŝetu.

47 PV, EV, AC przykład zaawansowanie PV odchylenie harmonogramu AC odchylenie kosztów EV wykonanie czas

48 Wskaźniki kosztów i wydajności (cd) 1. Wskaźnik realizacji harmonogramu (SPI Schedule Perfomance Index) EV : PV SPI większe od 1 wskazuje na wyprzedzanie harmonogramu 2. Wskaźnik realizacji kosztów (CPI Cost Perfomance Index) EV : AC CPI większe od 1 wskazuje na niŝsze koszty od zaplanowanych

49 Spotkania monitorujące element monitorowania i kontroli 1. Celem spotkań monitorujących jest zapewnienie przepływu informacji do zespołu projektowego i między członkami tego zespołu 2. Wskazane jest sporządzenie protokołu i przesłanie go uczestnikom w celu naniesienia zmian 3. Wskazane jest unikanie dyskusji nie interesujących wszystkich członków zespołu

50 Spotkania monitorujące zakres 1. Przedstawienie zmian w projekcie (menedŝer projektu) 2. Przedstawienie stanu projektu (menedŝer projektu) 3. Omówienie stanu działań rozpoczętych i tych, które miały się rozpocząć od ostatniego spotkania (menedŝerowie działań) 4. Przedstawienie nierozwiązanych problemów (menedŝer projektu i menedŝerowie działań)

51 Wprowadzanie zmian do projektu 1. Zmiany w projekcie (zakres, czas) zachodzą często, szczególnie w projektach dłuŝszych 2. Wprowadzanie zmian do projektu musi być udokumentowane za pomocą wniosku o wprowadzenie zmiany 3. Wniosek o wprowadzenie zmiany powinien zawierać: a) tytuł projektu b) określenie wnioskodawcy c) datę wniosku d) opis zmiany e) uzasadnienie f) określenie osoby zatwierdzającej g) datę zatwierdzenia

52 Opis wpływu zmiany na projekt 1. Po wprowadzeniu zmiany do projektu powstaje kolejny dokument: Opis wpływu zmiany na projekt 2. Opis wpływu zmiany na projekt powinien zawierać warianty wprowadzenia zmiany w projekcie, np. zmianę terminu wykonania projekty, zmianę jakości, zmianę budŝetu 3. Wnioskodawca na tej podstawie wybiera jeden z zaproponowanych wariantów

53 Rodzaje zmian Przykład konkluzji zawartej w Opisie wpływu zmiany na projekt 1. Nie zmieniająca budŝetu ani czasu realizacji projektu 2. Zmieniająca czas realizacji projektu 3. Zmieniająca czas realizacji projektu i zapotrzebowanie na zasoby 4. Zmieniająca zapotrzebowanie na zasoby 5. Wymagająca modyfikacji planu projektu 6. Wymagająca wprowadzenia zasadniczych zmian w projekcie

54 Co po tej części wykładu student powinien umieć 1. Podać przykłady narzędzi stosowanych przy monitorowaniu 2. Podać klasyfikację raportów 3. Omówić zawartość typowych raportów 4. Omówić wykorzystanie kamieni milowych do monitorowania postępu prac nad projektem 5. Określić i zinterpretować najprostsze wskaźniki kosztów i wydajności 6. Omówić krzywą S 7. Omówić sposób wprowadzania zmian w projekcie

55 Zamykanie projektu

56 Etapy zamykania projektu 1. Akceptacja wyników projektu przez klienta (odbiór projektu) 2. Dostarczenie wyników projektu (jeŝeli jest potrzebne) 3. Skompletowanie dokumentacji projektu 4. Raport podsumowujący projekt 5. Audyt powdroŝeniowy

57 Akceptacja klienta Dwa rodzaje akceptacji 1. Akceptacja nieformalna przyjęcie przez klienta wyników projektu bez formalnych procedur; oświadczenie klienta powinno mieć jednak formę pisemną akceptacja nieformalna nie oznacza na gębę 2. Akceptacja formalna przyjęcie przez klienta wyników projektu po przeprowadzeniu formalnej procedury akceptacji rezultatów projektu

58 Akceptacja formalna lista sprawdzająca 1. Projekt procedury akceptacji formalnej powstaje, w uzgodnieniu z klientem, na etapie planowania projektu lub w początkowym etapie jego realizacji 2. Zazwyczaj tworzy się listę sprawdzającą zawierającą wszystkie zakładane efekty realizacji projektu 3. Lista sprawdzająca powinna być jednoznaczna warto wykorzystać wynegocjowane wcześniej warunki satysfakcji 4. W procedurze biorą udział przedstawiciele klienta i wykonawcy 5. Procedura polega na sprawdzeniu zgodności poszczególnych rezultatów ze specyfikacją projektu 6. Sprawdzaniu rezultatów mogą towarzyszyć testy 7. JeŜeli część pozycji listy sprawdzającej nie zostanie zaakceptowana, wówczas ostateczna akceptacja następuje po wprowadzeniu poprawek

59 Akceptacja wymuszona Akceptacja wymuszona występuje w sytuacji, gdy ze względu na datę zakończenia projektu, jego rezultaty muszą zostać przyjęte: Przykład: organizacja konferencji Takie sytuacje mogą zrodzić komplikacje juŝ po odebraniu projektu (np. płatności)

60 Dostarczenie zamówionych elementów Ten etap zamykania projektu moŝe, ale nie musi wystąpić. Występuje zazwyczaj w przypadku projektów o rezultatach materialnych (np. budowa prototypu urządzenia), informatycznych (np. instalacja oprogramowania). W projektach budowlanych ma formę przekazania obiektu (budynku, wiaduktu, drogi)

61 Skompletowanie dokumentacji projektu 1. RóŜne elementy dokumentacji projektu powstają na całym etapie jego realizacji 2. Etap ten jest często pomijany lub bagatelizowany, jako mało istotny, Ŝmudny i nieefektowny 3. Kompletowanie będzie prostsze, jeŝeli w trakcie realizacji projektu będzie prowadzone na bieŝąco

62 Skompletowanie dokumentacji dlaczego warto to robić? 1. Do zamkniętych projektów czasami się powraca (np. remont instalacji w budynku, modyfikacja programu komputerowego) dokumentacja pomoŝe we wprowadzaniu zmian 2. Dokumentacja zawiera doświadczenia pomocne przy realizacji kolejnych projektów moŝna się do nich odwoływać prognozując np. czasy trwania działań, koszty, zagroŝenia itp. 3. Z tych samych względów dokumentacja moŝe być pomocna dla innych zespołów projektowych 4. Dokumentacja to dobry materiał szkoleniowy dla przyszłych menedŝerów projektów 5. Dokumentacja moŝe stanowić podstawę oceny pracowników zaangaŝowanych w projekt

63 Zawartość dokumentacji projektu (minimum) 1. Statut projektu 2. Definicja projektu (jeŝeli ją stworzono) 3. Propozycja projektu wraz ze wszystkimi załącznikami 4. Wszystkie zaakceptowane wersje harmonogramu 5. Projekty i rysunki techniczne 6. Raporty o stanie projektu 7. Protokoły ze spotkań monitorujących 8. Wnioski o wprowadzenie zmian 9. Raporty o sytuacjach wyjątkowych 10.Dokumenty związane z procesem akceptacji przez klienta 11.Wyniki audytu powdroŝeniowego 12.Raport zamykający projekt

64 Skompletowanie dokumentacji projektu uwagi 1. Część z wymienionych dokumentów moŝe występować jako oryginały lub kopie 2. Ze względu na koszty przechowywania dokumentacji i łatwość dostępu wskazana jest forma elektroniczna 3. Szczególnie w formie elektronicznej istotne jest zachowanie hierarchii i struktury archiwum oraz bieŝące porządkowanie 4. Odpowiedzialność za skompletowanie dokumentacji spoczywa na menedŝerze projektu 5. JeŜeli w zespole projektowym występuje asystent menedŝera, to zazwyczaj jemu zleca się bieŝącą archiwizację dokumentów zgodnie z instrukcjami menedŝera projektu

65 Audyt powdroŝeniowy 1. Audyt powdroŝeniowy przeprowadza się po zaakceptowaniu rezultatów projektu przez klienta, czasami po dłuŝszym okresie czasu (nawet do kilku lat) od tego momentu 2. W trakcie audytu warto nawiązać kontakt z klientem (jeŝeli został przerwany)

66 Audyt powdroŝeniowy Audyt powdroŝeniowy powinien odpowiedzieć na pytania: 1. Czy został osiągnięty cel projektu? a) punkt widzenia wykonawcy czy osiągnięty rezultat jest taki, jaki zespół projektowy zamierzał osiągnąć? b) punkt widzenia klienta czy osiągnięty rezultat jest tym, czego Ŝyczył sobie klient? 2. Czy klient jest usatysfakcjonowany rezultatami projektu? (np. w trakcie realizacji projektu zmieniły się warunki satysfakcji)

67 Audyt powdroŝeniowy 3. Czy projekt został zrealizowany w określonym czasie, bez przekraczania budŝetu i zgodnie ze specyfikacją (patrz złoty trójkąt projektu)? 4. Czy projekt przyniósł ekonomiczną korzyść? (w przypadku niektórych projektów trzeba odczekać kilka lat, aby to stwierdzić) 5. Jakie wnioski z projektu moŝna wyciągnąć? (chodzi tu głównie o wnioski dotyczące zarządzania projektami) 6. Co się powiodło, co się nie powiodło?

68 Audyt powdroŝeniowy 1. W praktyce audyt powdroŝeniowy prowadzony jest rzadko; przyczyny: a) nacisk na rezultaty po zakończeniu projektu naleŝy jak najszybciej przejść do następnego b) niski priorytet c) koszty audytu

69 Audyt powdroŝeniowy dlaczego warto przeprowadzić 1. Zamknięte projekty mogą być kopalnią informacji dla przyszłych projektów wyniki audytu powinny być dołączone do dokumentacji projektu 2. Odpowiedzi na pytania audytu (szczególnie ostatnie) zmniejszają ryzyko przy realizacji przyszłych projektów

70 Raport podsumowujący Raport podsumowujący to końcowy dokument zamykający projekt. Powinie zawierać: 1. Ocenę rezultatów projektu z uwzględnieniem wyników audytu 2. Ocenę organizacji projektu (planowanie, zespół projektowy, zarządzanie zasobami, monitorowanie projektu) 3. Ocenę działań podjętych dla realizacji projektu

71 Co po tej części wykładu student powinien umieć 1. Znać i opisać etapy zamykania projektu 2. RozróŜniać akceptację formalną i nieformalną 3. Opisać procedurę akceptacji formalnej 4. Omówić znaczenie skompletowania dokumentacji projektu 5. Podać przykładowy elementy składające się na dokumentację projektu 6. Określić, na jakie pytania na leŝy odpowiedzieć podczas audytu powdroŝeniowego