Zagadnienia integracji metod zwinnych i tradycyjnych w zarządzaniu projektami informatycznymi

Transkrypt

1 Computer Science Laboratory, Department of Automatics Zagadnienia integracji metod zwinnych i tradycyjnych w zarządzaniu projektami informatycznymi Dr hab. inż. prof. n. Jan Werewka, PMP Techniczny Uniwersytet Otwarty AGH 4 kwietnia 2009 Agenda (program wykładu) Projekty, programy i portfele w przedsiębiorstwie Porównanie tradycyjnych i zwinnych metod zarządzania Propozycja zasady skalowania zarządzania Strategie realizacji projektu PMBOK - Standard ANSI zarządzania projektami Propozycja skalowania dla małych projektów 1

2 Zwiększający się udział projektów w działalności ludzkiej Projekty należy traktować jako narzędzie do tworzenia wartości ekonomicznej lub konkurencyjnej korzyści. Coraz więcej działalności różnych typów formułowanych jest w postaci projektów Definicja projektu Chwilowe przedsięwzięcie z określonym początkiem i końcem. Projekty mają charakter tymczasowy. Wytwarzający niepowtarzalny produkt, usługę lub wynik. Stopniowe doprecyzowanie. Projekty ze względu na swój unikalny charakter w miarę rozwoju - wiedza o projekcie ulega poszerzeniu. 2

3 Praca operacyjna - praca ciągła Działania operacyjne Działania operacyjne adaptują nowy zbiór celów i kontynuują pracę Trwające i powtarzalne Celem jest utrzymanie biznesu (działalności gospodarczej) i ciągłości działania Projekty Projekt ulega zakończeniu, jeśli uzyskano cele Chwilowe i unikalne Celem jest spełnienie celi i zakończenie projektu Portfel projektów Zbiór projektów, programów i innych prac połączonych, żeby umożliwić zarządzanie tymi pracami tak, aby osiągnąć strategiczne cele organizacji (Standard Zarządzania Portfelami, PMI) Dowolny zbiór projektów, który jest istotny z punktu widzenia osoby tworzącej portfel (Primavera) Portfel główny zbiór projektów, za których zarządzanie określono jednoznaczną odpowiedzialność. Portfel analityczny portfel utworzony w celu uzyskania wiedzy o zbiorze projektów. 3

4 Program Grupa projektów powiązanych i zarządzanych w skoordynowany sposób tak, aby uzyskać korzyści i możliwości zarządzania niedostępne przy osobnym zarządzaniu nimi (standard Zarządzania Programem, PMI) Struktura nadzoru w organizacji bazującej na projektach Dobrze określony nadzór w przedsiębiorstwie odgrywa istotną rolę w jego działalności gospodarczej Nadzór (korporacyjny) może być wspomagany przez nadzór IT Nadzór IT pozwala na zwiększenie zysków o 20% 4

5 Struktura nadzoru w organizacji bazującej na projektach Dobrze określony nadzór w przedsiębiorstwie odgrywa istotną rolę w jego działalności gospodarczej Nadzór (korporacyjny) może być wspomagany przez nadzór IT Nadzór IT pozwala na zwiększenie zysków o 20% Struktura nadzoru proponowana dla organizacji bazującej na projektach Struktura nadzoru proponowana przez Project Management Institute (PMI), bazuje na zarządzaniu: Projektami, Programami projektów Portfelami projektów 5

6 Elementy nadzoru organizacji Struktura nadzoru organizacji 6

7 Cel definiowanie ogólnej ramy do zarządzania projektami Definiowanie ogólnej ramy do zarządzania projektami umożliwiającej skalowanie zarządzania odpowiednio dla różnych projektów Zakłada się, że istnieją elementy nadzoru i istnieje w pewnym zakresie system informatyczny do nadzoru projektów Zakłada się, że projekty są wykonywane według rozwiązań podobnych do proponowanych przez PMI w zakresie zarządzania portfelami, programami i projektami Założenia dotyczące zarządzania projektami informatycznymi Zakłada się, że proponowane rozwiązania dotyczą firm informatycznych, a główną działalnością gospodarczą jest realizacja projektów. W przedsiębiorstwie informatycznym istnieje środowisko do prowadzenia wielu projektów. W tym samym czasie może być wykonywanych wiele projektów. Przedsiębiorstwo jest małej lub średniej wielkości. Na niższych poziomach zarządzania, projektem mogą być prowadzone w różny sposób, stosując różne style zarządzania i technologie wytwarzania. Projekty mogą być realizowane przez zespoły wirtualne (rozproszone geograficznie lub czasowo). 7

8 Zarządzanie projektami przy równoczesnym użyciu metod bazujących na planowaniu i metodach zwinnych Przedsiębiorstwa informatyczne raportują zwiększoną produktywność i poprawę wskaźników biznesowej opłacalności dla metodyk zwinnych Zwiększeniu ulega tez popularność tradycyjnych metod zarządzania bazujących na planowaniu Niektóre projekty informatyczne muszą z różnych powodów być zorientowane na plan. Trudności zastosowania metod tradycyjnych w projektach informatycznych Oprogramowanie nie jest namacalne i trudno jest je łatwo wyjaśnić Rzadko dwa takie same systemy oprogramowania są budowane wielokrotnie (nie istnieje analogia do istniejących systemów) Przeprowadzenie projektu informatycznego jest działaniem złożonym i obciążonym dużym (np. zmiana technologii) Łatwość modyfikowania powiązana z problemami dokładnego definiowania wymagań 8

9 Różnice pomiędzy tradycyjnymi i zwinnymi metodami zarządzania Tradycyjne metody są zorientowane na plan. Dla dostarczanych produktów projektu definiowane są wymagania, na podstawie tego wyznaczany jest harmonogram i koszt projektu. Projekt ma dostarczyć produkty o zadanych wymaganiach. W metodyki zwinne bazują na wartości dostarczanych produktów, koszt i przedział czasowy jest ustalony wcześniej. Po tym przedziale czasowym ma powstać produkt, który daję największą wartość biznesową. Porównanie tradycyjnych i zwinnych metod zarządzania 9

10 Porównanie zarządzaniu bazującego na planowaniu (PMBOK) z ogólną postacią metodyk zwinnych PMBOK standard ANSI zarządzania projektami W PMBOK planowanie ogrywa centralną rolę, zadania do wykonania przekazywane są z procesów planowania do procesów wykonania (zarządzanie takie jakie zostało zaplanowane). Kierowanie wykonaniem projektu polega na metodzie termostatu, w którym postęp projektu jest sprawdzany względem planu. W przypadku odchyłek, planowane i wykonywane są czynności naprawcze. 10

11 Metodyki zwinne jako zarządzanie bazujące na wartości W metodach zwinnych istnieje lista właściwości (wymagań) produktu, która określa zmiany względem istniejącego prototypu produktu oprogramowania. Kierownik projektu maksymalizuje wartość dostarczenia poprzez odpowiednie wybranie właściwości dla aktualnej iteracji I usuwając ewentualne przeszkody stojące przed zespołem rozwojowym. Ten sposób postępowania umożliwi wczesne sprawdzenie (walidację wymagań). Metodyki zwinne rys historyczny Lean Manufacturing (Toyota Production System) lata 50te Scrum 1986 DSDM (Dynamic Systems Development), FDD (Feature-Driven Development), ASD (adaptive software Development) 1995 Crystal Clear, Extreme Programming utworzenie Agile Alliance 11

12 Agile manifesto Przedkładamy ludzi i interakcje pomiędzy nimi nad procesy i narzędzia Przedkładamy działający produkt nad rozbudowaną dokumentację Przedkładamy kooperacje z klientem nad sztywne trzymanie sie kontraktu Przedkładamy umiejętność dostosowywania się do zmian nad kurczowe trzymanie się planu Ogólne zasady skalowania Głównym celem skalowania jest minimalizacja czynności związanych z zarządzaniem projektu. Zagadnienie jakie zasady skalowania należy zastosować? Podstawowe przyjęte rozwiązanie, są zasady zaczerpnięte z szczupłego wytwarzania (Lean Manufacturing), w szczególności eliminacja marnotrawstwa. Marnotrawstwo, to wszystko co nie stanowi wartość dla klienta. 12

13 Szczupłe wytwarzanie oprogramowania Software Development (LSD) Mary i Tom Poppendieck zaadaptowali zasady i praktyki szczupłego wytwarzania (Lean Manufacturing) dla szczupłego wytwarzania oprogramowania (Lean Software Development -LSD) Koncepcja usuwania wszystkiego, co nadmiarowe i niepotrzebne W szczupłym wytwarzaniu oprogramowania wyróżnia się 7 zasad wspomaganych przez 22 narzędzia Szczupłe myślenie (Lean Thinking) zasady bazujące na: Wartości, czyli identyfikacji tego, co przedstawia rzeczywistą wartość dla klienta i koncentrowaniu się na tych wartościach. Strumieniu wartości, czyli na upewnieniu się, że wszystkie działania w procesach są niezbędne i powodują dodanie wartości. Przepływie, w którym wyjścia z działania przepływają do następnego etapu procesu bez opóźnień. Ciągnięciu (pull), czyli czekaniu na sygnał o potrzebach i nie tworzenie niczego co nie jest wymagane. Perfekcji, czyli zapobieganiu defektom i przeróbkom. 13

14 Zasady szczupłego wytwarzanie oprogramowania 1. Eliminacja marnotrawstwa Nie należy tworzyć niczego co nie ma wartości. Działania które nie zwrócą się, należy usunąć. Zalecane jest uczenie się rozpoznawania marnotrawstwa. Należy wykrywać największe źródła marnotrawstwa i je usuwać. 2. Wzmocnienie pozyskiwania wiedzy 3. Podejmowane decyzji najpóźniej jak to możliwe. Należy poprawiać sprzężenie zwrotne poprzez stosowanie częstych iteracji i regularne wydania w celu szybkiego uzyskania informacji zwrotnej. Zalecana jest praca w zintegrowanych zespołach. Nie należy podejmować pochopnych decyzji. W tym celu konieczne jest nauczenie się tak dużo na ile to możliwe, przed podjęciem nieodwracalnej decyzji. Należy rozważać różne możliwości, a decyzje podjęte powinny bazować na faktach. Zasady szczupłego wytwarzanie oprogramowania 4. Dostarczanie najwcześniej jak tylko to jest możliwe Zalecane jest dostarczanie w małych porcjach i szybko, w celu uniknięcia zmiany wymagań. Miarą dojrzałości organizacji jest szybkość odpowiedzi na potrzeby klienta. 5. Respektowanie osób Należy przekazać możliwości i uprawnienia zespołowi. Zaangażowani członkowie zespołu stanowią największą wartość. Osoby, które dostarczają wartość dodaną, powinny mieć możliwość pełnego wykorzystania swojego potencjału. 14

15 Zasady szczupłego wytwarzanie oprogramowania 6. Tworzenie jakości i spójności 7. Spojrzenie na całościowe cele produktu. Jakość i spójność produktu polega na uzyskaniu równowagi pomiędzy funkcjami, niezawodnością i wartością ekonomiczną zadawalająca klienta. Koncepcyjna spójność dotyczy jak dobrze produkt został zaprojektowany i wytworzony oraz uzyskanie zadowolenia klienta w momencie dostawy i potem przez długi okres czasu. Należy widzieć produkt jako całość. Rozwiązania technologiczne i szanse powinny być wyważone. Należy ustrzec się przed pokusą optymalizacji części systemu kosztem całości. Źródła marnotrawstwa zdefiniowane w szczupłym wytwarzaniu oprogramowana 1. Nieukończona praca (excess inventory) Niedokończone oprogramowanie, które może nigdy nie zostać wykorzystane. Oprogramowanie takie szybko się dezaktualizuje. Minimalizacja niedokończonego oprogramowania zmniejsza ryzyko związane z oprogramowaniem. 2. Dodatkowe procesy (extra processing steps) 3. Dodatkowe cechy (overproduction) Dodatkowe procesy jakim jest np. tworzenie nadmiernej dokumentacji, której części nie zostaną nigdy wykorzystane. Należy starać się uzyskać informację bezpośrednio u źródła, a nie przez pośredników. Dodatkowe cechy mogą dotyczyć niepotrzebnego kodu lub funkcjonalności (gold plating). Każda dodatkowa funkcjonalność podnosi złożoność systemu i jest miejscem potencjalnych błędów. Jeżeli kod tworzony nie jest aktualnie potrzebny, to jest marnotrawstwem zasobów. 15

16 Źródła marnotrawstwa zdefiniowane w szczupłym wytwarzaniu oprogramowania 4. Przełączanie zadań (unnecessary transportation) Przełączanie zadań między zadaniami w różnych projektach jest źródłem marnotrawstwa. Programista przełączając się pomiędzy zadaniami w różnych projektach traci czas na zastanowienie się, co ostatnio w tym projekcie zrobił i co ma aktualnie do zrobienia. Najszybszym sposobem ukończenia dwóch projektów jest zakończenie jednego, a potem drugiego. 5. Oczekiwanie (waiting) Oczekiwanie na pewne zdarzenie (np. na decyzję, przegląd, testowanie, wdrożenie) powoduje opóźnienia, które zmniejszają wartość systemu. Źródła marnotrawstwa zdefiniowane w szczupłym wytwarzaniu oprogramowania 6. Przemieszczanie (unnecessary movement) Przemieszczanie się ludzi przykładowo w celu poszukiwania informacji związanej z technicznym problemem. Duża część wiedzy pozostaje tylko o jego twórcy i nie jest ona przekazywana w sposób należyty dalej, na przykład dokumentacja, która nie zawiera wiedzy osoby, która ją tworzyła. 7. Defekty (niska jakość) Defekty, szczególnie te nie wykryte przez testy. Redukcja strat spowodowanych przez defekty polega na ich najszybszym ich wykrywaniu, częstej integracji i wczesnym przekazywaniu kolejnych wydań. 16

17 Skalowanie zarządzania projektem - wnioski Szczupłe wytwarzanie oprogramowania definiuje dobre praktyki, nie opisuje procesów. Szczupły rozwój oprogramowania bazuje na dobrze wyszkolonym zespole i zredukowanym narzucie związanym z zarządzaniem. Wydaje się, że skalowania zarządzania projektem wykorzystując zasady i narzędzia szczupłego myślenia, jest prawidłową decyzją. Możliwości skalowania zależą od: Strategii projektu, Typu dostarczanego produktu w projekcie, Rozmiaru projektu, Złożności projektu 17

18 Rola kierowników projektów Kierownicy projektów, powinni brać odpowiedzialność za wyniki biznesowe projektu. Sukcesu projektu jest ściśle powiązane z efektywnością organizacji i sukcesem w dłuższym horyzoncie czasowym. Szybkie zmiany i globalna (światowa konkurencja) wymaga od organizacji szybkiego reagowania i posiadania większej konkurencyjności, jak nigdy dotąd. W szybko zmieniającym się świecie nie ma czasu na dzielenie odpowiedzialności, na kierownikach projektu skoncentrowanych na uzyskaniu, ze zadanie zostanie zrobione, podczas gdy inni kierownicy są odpowiedzialni za zagadnienia biznesowe. Tradycyjne pojęcie sukcesu Związane z spełnieniem trzech ograniczeń dochowania terminów, kosztów i wymagań. Jednakże, nie zawsze tak jest: Wymownym przykładem jest budowa Opery w Sydney. Przekroczenie budżetu aż w 1500%, przekroczenie czasu zakończenia wynosiła 250%. Pierwsza wersja systemu Windows była dostarczona z opóźnieniem, wymagał zaangażowania dodatkowych zasobów. Okazał się projektem o nadzwyczajnym zysku dla firmy Microsoft, gdyż 90% komputerów posiada system Windows 18

19 Trójkąt ograniczeń projektowych Czas skrócenie czasu projektu może wiązać się z zwiększeniem kosztów projektu lub z zmniejszeniem zakresu. Koszty zmniejszenie kosztów projektu może pociągać konieczność redukcji zakresu lub wydłużenie czasu projektu. Zakres- zwiększenie zakresu projektu powoduje zwykle wzrost kosztów projektu i wydłużenie czasu trwania projektu. Koszt Czas Zakres Rozszerzony trójkąt ograniczeń projektowych Jakość zwiększenie jakości może powodować zwiększenie zakresu projektu, zwiększenia ryzyka projektowego, ale powiększenie satysfakcji klienta. Ryzyko zmniejszenie ryzyka jest związane z ponoszeniem zwiększonych kosztów. Zadowolenie klienta zwiększenie zadowolenia klienta może powodować poprawę jakości oraz zwiększenie ryzyka. 19

20 Komponenty strategii projektu Strategia Projektu Komponenty Opis Perspektywa Perspektywa biznesowa Motywacja biznesowa dla implementacji projektu lub wytworzenia produktów projektu Stanowisko (Position) Cel Definicja produktu Korzyść wobec konkurencji/ wartość Kryteria powodzenia i niepowodzenia Zasadniczy (ultimate) cel projektu Opis produktów projektu, wraz z ich specyfikacją Powód dlaczego produkty projektu są lepsze niż inne produkty i wartość która tworzy produkt Perspektywa i oczekiwania organizacji wobec projektu/produktu Komponenty strategii projektu Strategia Projektu Komponenty Opis Kierunki i wskazania Definicja projektu Ograniczenia projektowe, zakresu pracy, dostarczonych produktów projektu i typ projektu Cel strategiczny Sposób myślenia i wytyczne (mindset and guidelines) prowadzenia projektu w celu uzyskania korzyści konkurencyjnej i wartości. 20

21 Strategie projektu dla projektów bazujących na produkcie Przewaga produktu (Superiority) zespół kładzie nacisk na przewagę charakterystyk produktu wobec innych produktów. Rozwijany produkt nie tylko powinien spełniać, lecz jeszcze przewyższać oczekiwania klienta. Zespól koncentruje się na badaniach i rozwoju. Dodatkowy czas jest konieczny na uzyskanie wymaganych własności i funkcjonalności. Jakość produktu i wydajność powinna być często przeglądana. Strategie projektu dla projektów bazujących na produkcie Przewaga czasowa (Product time tomarket) Pierwszy produkt na rynku. Projekt jest zarządzany według harmonogramu. Wysiłki zespołu idą w kierunku zakończenia wewnątrz zadanego przedziału dostawy. Powinny być planowane krótkie nakładające się fazy. 21

22 Strategie projektu dla projektów bazujących na produkcie Koncentracja na klienta (customer intimacy) zaspokaja specyficzne potrzeby klienta. Zespół utrzymuje bliskie związki z klientem, który ma duży wpływ na korzyść biznesową firmy. Potrzeby klienta powinny być często przeglądane. Strategie projektu dla projektów bazujących na produkcie Przewaga kosztowa Produkt o najniższych kosztach. Tworzenie więcej za mniej. Zespół tworzy produkty, które są konkurencyjne kosztowo. Zespół ma rozwijać tani (low-cost) produkt, który powinien generować zysk w konkurencyjnym środowisku. Koszty produktu powinny być często przeglądane. 22

23 Definiowanie sukcesu projektu Wymiar sukcesu Miara 1. Efektywność projektu Spełnienie celów harmonogramu Spełnienie celów budżetowych 2. Wpływ na klienta Spełnienie wydajności funkcjonalnej Spełnienie specyfikacji technicznej Spełnienie potrzeb klienta Rozwiązanie problemów klienta Korzystanie przez klienta z produktu Zadowolenie klienta 3. Sukces biznesowy Sukces komercyjny Uzyskanie dużego udziału w rynku 4.Przygotowanie na przyszłość Tworzenie nowego rynku Tworzenie nowej linii produktów Rozwijanie nowej technologii Wymiary sukcesu w zależności od zaawansowania stosowanej technologii (od nisko zaawansowanej technologii do bardzo zaawansowanych technologii) nowatorstwa projektu (od projektu powtarzalnego, do radykalnej innowacji rynkowej) złożoności projektu kroku postępu projektu (regularny, szybki, krytyczny czasowo, błyskawiczny) 23

24 Wybrane elementy karty projektu Komponenty strategii Perspektywa biznesowa Pytanie Dlaczego to robimy? Jaka jest perspektywa biznesowa? Jak dopasować potrzeby w wczesnej fazie? Szczegóły Kto jest klientem/użytkownikiem? Jakie są potrzeby? W jaki sposób odpowiadamy na potrzeby? Jaka jest okazja biznesowa? Cel Co chcemy osiągnąć? Co jest jest podstawowym celem, który ma być osiągnięty na zakończenie projektu? Definicja produktu Czym jest produkt? Co wytwarzamy? Zasady operacji Główne charakterystyki produktu Wybrane elementy karty projektu Komponenty strategii Pytanie Szczegóły Korzyść wobec konkurencji/ wartość Kryteria powodzenia i niepowodzenia W jaki sposób jest on dobry? Dlaczego jest lepszy? Dlaczego klient będzie go kupował? Jaką wartość przedstawia dla nas? Jakie są oczekiwania? Jak osiągnąć sukces? Co może pójść źle? Jaka jest korzyść klienta/użytkownika nad: Konkurencja? Poprzednimi produktami? Rozwiązaniami alternatywnymi? Koszt/efektywność produktu W jaki sposób my skorzystamy? Wymiary sukcesów i metryki Główne ryzyka i ich konsekwencje 24

25 Wybrane elementy karty projektu Komponenty strategii Definicja projektu Cel strategiczny Pytanie W jaki sposób to zrobimy? Czym jest projekt? Jak sie zachowywać? Co robić by osiągnąć CA/V? Jak utworzyć nieustępliwy pościg za konkurencyjną korzyścią/wartością Szczegóły Zakres projektu Produkty projektu Klasyfikacja typu projektu Kierownik projektu, zespół projektu. Wytyczne dla zachowania Polityka zarządzania i działania w sposób efektywny: -Kompetencje firmowe (organizacji) -Wiedza specjalistyczna -Wewnętrzne (synergia) wzmocnienie -Zewnętrzne (alliances) powiązania Rozmiar projektu jest głównie opisany przez parametry: Dostępne sumaryczne fundusze Wielkość zespołu zaangażowana w projekcie Liczba i rozmiar dostarczanych produktów Złozoność dostarczanych produktów Przedziały czasowe dostawy 25

26 Złozoność techniczna projektu Mała złozoność techniczna: Proste procesy lub pojedynczo wątkowy system; Interaktywna wydajność ograniczona do pojedynczej platformy; Bazuje na wielu podobnych systemach; Może zawierać ponowne przetworzenie odziedziczonej aplikacji. Duża złożoność techniczna: Systemy wbudowane, rozproszone, czasu rzeczywistego, odporne na błędy; Systemy o wysokiej wydajności; Przedefiniowana architektura systemów odziedziczonych, nowe lub nowatorskie systemy. Propozycja skalowania zarządzaniem projektu 26

27 Powody wyboru takiego rodzaju skalowania Stosunkowo łatwo jest przygotować szablony, procedury i inne dokumenty dla kilku kategorii projektów. Wyższe kierownictwo przedsiębiorstwa potrzebuje podobnego widoku na różne projekty. Na różnych poziomach zarządzania w przedsiębiorstwie powinna istnieć możliwość porównania projektów. Łatwiej tego dokonać przy małej liczbie kategorii projektów. Rozmiar projektu wyprowadzony z liczby punktów funkcyjnych Project size Function Point Size SLOC (C++, Java) Costs, New development, GBP FTE days Distribution Small % Medium Large % Extra- Large 3000> > > 7.031> 11% 27

28 Prosta kategoryzacja projektów Czas trwania projektu. Projekty informatyczne nie powinny trwać zbyt długo, ze względu chociażby technologicznych. Przykładowe długości projektów: 6 miesięcy, 1 rok, 2 lata. Rozmiar zespołu: Istnieje prosta reguła; na każde 5 osób potrzebny jest nowy poziom w strukturze organizacyjnej. W tym przypadku zespoły 5, 25, 125, 626 osobowe wymagają dodatkowego poziomu zarządczego. Koszty: Koszty projektu. Zarządzanie małymi projektami na bazie standardu PMBOK Krótki okres trwania, zazwyczaj mniejszy niż 6 miesięcy, praca w niepełnym wymiarze godzin. Zespół 10 osobowy lub mniejszy Wymagana mała liczba obszarów umiejętności Ma pojedynczy cel a rozwiązanie może być w sposób klarowny osiągnięte Kierownik projektu jest pierwszym źródłem przywództwa Dostarcza dobrze okreslone produkty Koszt wynosi ponizej $75,000 I fundusze na realizację projektu są dostępne. 28

29 Waga zarządzania małymi projektami - wyzwania Planowanie daje projektowi dobrze zdefiniowany zakres, a pełzanie (creep) prjeku moze stać się pełzaniem wymagań. Małe projekty mają krótki czas trwania I są traktowane jako łatwe do dostarczenia, zespół często przystępuje natychmiast do wytwarzania produktów. Niski priorytet projektu w organizacji. Trudno jest zaangażować osoby oraz wykazać im ważność i pilność projektu. Ryzyko odwrócenia się do innych projektów jest wysokie, co moze spowodować utratę koncentracji na projekt przy naprowadzeniu na własciwy kierunek. Waga zarządzania małymi projektami - wyzwania Niedoświadczony zespół projektowy. Jest bardzo trudno uzyskać kluczowe osoby dla małych projektów. Procesy i narzędzia. Próba zastosowania procesów i narzędzi przeznaczonych dla dużych projektów nie funkcjonuje poprawnie, zabiera dużo czasu i jest frustrujące 29

30 Standard PMBOK dla małych projektów PMBOK 4-ta edycja posiada 42 procesy Skalowanie redukcja do 8 procesów, do procesów: Wytwarzających i przetwarząjacych dostarczane produkty Integracji projektu PMBOK możliwości skalowania For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process. Dla każdego projektu, kierownik projektu przy współpracy z zespołem projektowym, jest zawsze odpowiedzialny za określenie, które procesy są odpowiednie i za odpowiedni rygor (trzymanie się zasad) dla każdego procesu. 30

31 PMBOK produkty dostawy 31

32 Skalowanie aktywów organizacji Aktywa (zasoby) procesów organizacyjnych (Organizational Process Assets): Procesy i procedury organizacji dla prowadzonych prac Korporacyjna baza wiedzy Czynniki środowiskowe przedsiębiorstwa (EEFs - Enterprise Environmental Factors) Czynniki wewnętrzne lub zewnętrzne, które mogą zakłócić lub mieć bezpośredni wpływ na realizację projektu: Struktura organizacyjna i procesy przedsiębiorstwa. Kultura i styl organizacyjny przedsiębiorstwa Składniki infrastruktury Polityka administrowania personelem Dostępność zasobów ludzkich oraz ich poziomy kompetencji Nastawienie wobec ryzyka projektowego i tolerancji ryzyka 32

33 Środowisko wieloprojektowe przedsiębiorstwa Portfele projektów Programy projektów Projekty Projekt 1 Projekt 2 Projekt 3 Projekt...n Czynniki środowiskowe przedsiębiorstwa Aktywa procesów organizacyjnych Wnioski Zaprezentowana wizja łączy zarządzanie portfelem i programem z jednej strony z zarządzaniem projektem z drugiej, przy równoczesnym skalowaniu odpowiednim dla wielkości projektu i jego złożoności. Przyjęto, ze zasady skalowania będą bazować na metodach szczupłego myślenia, adaptowanego dla potrzeb projektów związanych z wytwarzaniem oprogramowania. Przedstawiona metoda dopuszcza stosowanie różnych metod prowadzenia projektów na niższych poziomach zarządzania. 33

34 Literatura [1] A Guide to the Project Management Body of Knowledge Third Edition (PMBOK Guide) an American National Standard ANSI/PMI , PMI 2004, pp. 390 [2] BRITTON W.C, IBM s Transformation from Project to Program and Portfolio Management. PMI Virtual Library, PMI 2007, pp. 4 [3] CHAPMAN J.R, Project Management Scalable Methodology Guide. 1997, [4] GRIFFITHS M., Using agile Alongside the PMBOK PMI Global Congress Proceedings, Anaheim, California [5] Mobilizing HP: Project Management as an Executive Priority. Benchmark Implementation: Primavera Case Study, 2004 Benchmarking Partners, pp. 9. [6] MORIEN R., Agile Management and the Toyota Way for Software Project Management, 3d Int. conf. On Industrial Informatics, 2005, p [7] POPPENDIECK M., & POPPENDIECK T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional, 2003 [8] POPPENDIECK M., & POPPENDIECK T. (2006). Implementing Lean Software Development: From Cocept to Cash. Addison-Wesley Professional, 2006 [9] ROWE S. F., Project Management for Small Projects, Management Concepts, 2007, p [10] SELIG G., J., WATERHOUSE P., IT Governance An Integrated Framework and Roadmap: How to Plan, Deploy and Sustain for Competitive Advantage. CA White Paper, 2006, pp. 19 Literatura [11] SHENHAR A. J., MILOSEVIC D., DVIR D., THAMHAIN H., Linking Project Management to Business Strategy, PMI, 2007, p [12] SLIGER M., A Project Manager s Survival Guide to Going Agile Rally Soft. Development Group, p.13. [13] Small project medium-size project and large project what do these terms mean. [14] STEINDL Ch., Lean Software Development, IBM Corporation, IT Architect and IT Specialist Institute central region in Herrenberg, 2005, p. 65 [15] The standard for Portfolio Management. PMI, 2006, pp. 60 [16] The standard for Program Management. PMI 2006, pp. 104 [17] THOMAS J.C., BAKER S.W., Establishing an Agile Portfolio to Align IT Investments with Business Needs, Agile 2008 Conf., IEEE Computer Society, p