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

Wielkość: px
Rozpocząć pokaz od strony:

Download "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

Lekkie metodyki. tworzenia oprogramowania

Lekkie metodyki. tworzenia oprogramowania Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz

Bardziej szczegółowo

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

Agile Project Management

Agile Project Management Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...

Bardziej szczegółowo

Dopasowanie IT/biznes

Dopasowanie IT/biznes Dopasowanie IT/biznes Dlaczego trzeba mówić o dopasowaniu IT-biznes HARVARD BUSINESS REVIEW, 2008-11-01 Dlaczego trzeba mówić o dopasowaniu IT-biznes http://ceo.cxo.pl/artykuly/51237_2/zarzadzanie.it.a.wzrost.wartosci.html

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

Bardziej szczegółowo

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 1 Zbigniew Misiak (BOC IT Consulting) Podyplomowe Studia Menedżerskie Zarządzanie projektami informatycznymi Czym się będziemy zajmować?

Bardziej szczegółowo

Optymalizacja Automatycznych Testów Regresywnych

Optymalizacja Automatycznych Testów Regresywnych Optymalizacja Automatycznych Testów Regresywnych W Organizacji Transformującej do Agile Adam Marciszewski adam.marciszewski@tieto.com Agenda Kontekst projektu Typowe podejście Wyzwania Cel Założenia Opis

Bardziej szczegółowo

Leszno 14.03.2013. Jakie są i będą oczekiwania biznesu wobec IT?

Leszno 14.03.2013. Jakie są i będą oczekiwania biznesu wobec IT? Leszno 14.03.2013 Jakie są i będą oczekiwania biznesu wobec IT? Banki stoją w obliczu zmian Uwarunkowania ekonomiczne Regulacje prawne Trendy społeczne Nowe technologie Dzisiaj otoczenie oczekuje innego

Bardziej szczegółowo

Tematy prac magisterskich Rok akademicki 2013/2014

Tematy prac magisterskich Rok akademicki 2013/2014 Dr hab. inż. Jan Werewka, prof. n. AGH Wydział EAIiIB AGH E-mail: werewka@agh.edu.pl www: http://home.agh.edu.pl/werewka Tematy prac magisterskich Rok akademicki 2013/2014 Temat 1 Architektura przedsięwzięcia

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo

Agile Project Management WHITEPAPER

Agile Project Management WHITEPAPER 1 Wstęp... 2 Historia... 2 DSDM ATERN... 3 Agile w zarządzaniu projektami... 4 Szkolenia i certyfikacja... 6 Certyfikaty Agile Project Management Foundation i Practitioner... 6 Szkolenie Agile Project

Bardziej szczegółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

Bardziej szczegółowo

Wyzwania Biznesu. Co jest ważne dla Ciebie?

Wyzwania Biznesu. Co jest ważne dla Ciebie? Wyzwania Biznesu Zarabianie pieniędzy Oszczędzanie pieniędzy i poprawa wydajności Szybsze wprowadzanie produktów na rynek Maksymalizacja zwrotu z inwestycji portfelowych Trzymać się harmonogramu, budżetu

Bardziej szczegółowo

Skuteczność => Efekty => Sukces

Skuteczność => Efekty => Sukces O HBC Współczesne otoczenie biznesowe jest wyjątkowo nieprzewidywalne. Stała w nim jest tylko nieustająca zmiana. Ciągłe doskonalenie się poprzez reorganizację procesów to podstawy współczesnego zarządzania.

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

Bardziej szczegółowo

Jednolity Model Zarządzania Portfelami

Jednolity Model Zarządzania Portfelami Jednolity Model Zarządzania (The Unified Portfolio Management Model, UPMM) Stanisław Gasik Referat pierwotnie prezentowany w ramach PMI Global Congress North America, październik 2007, Atlanta Rodzaje

Bardziej szczegółowo

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A. Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration

Bardziej szczegółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Rozdział 4 Planowanie rozwoju technologii - Aleksander Buczacki 4.1. Wstęp 4.2. Proces planowania rozwoju technologii

Rozdział 4 Planowanie rozwoju technologii - Aleksander Buczacki 4.1. Wstęp 4.2. Proces planowania rozwoju technologii Spis treści Wprowadzenie Rozdział 1 Pojęcie i klasyfikacja produktów oraz ich miejsce w strategii firmy - Jerzy Koszałka 1.1. Wstęp 1.2. Rynek jako miejsce oferowania i wymiany produktów 1.3. Pojęcie produktu

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012 STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI Edycja 2011/2012 Program studiów opracował: Grzegorz Karpiuk CEL STUDIÓW 1. Zdobycie przez uczestników wiedzy i kompetencji z zakresu zarządzania projektami oraz

Bardziej szczegółowo

Metodyki zwinne wytwarzania oprogramowania

Metodyki zwinne wytwarzania oprogramowania Metodyki zwinne wytwarzania oprogramowania Wykład 1 Marcin Młotkowski 7 października 2014 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski

Bardziej szczegółowo

Katalog rozwiązań informatycznych dla firm produkcyjnych

Katalog rozwiązań informatycznych dla firm produkcyjnych Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

OFERTA SZKOLEŃ BIZNESOWYCH

OFERTA SZKOLEŃ BIZNESOWYCH OFERTA SZKOLEŃ BIZNESOWYCH Przywództwo i zarządzanie zespołem Szkolenie z zakresu przywództwa, kompetencji liderskich i zarządzania zespołem. Podniesienie kompetencji zarządczych w zakresie przywództwa,

Bardziej szczegółowo

Podstawy zarządzania projektami

Podstawy zarządzania projektami Podstawy zarządzania projektami Zakres Definicja projektu Rola projektów w organizacji Definicja zarządzania projektami Role interesariuszy i kierownika projektu Zarządzanie programami i portfelami projektow

Bardziej szczegółowo

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

Bardziej szczegółowo

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach Wsparcie narzędziowe zarządzania ryzykiem w projektach Prezentacja dodatkowa: PMBOK a zarządzanie ryzykiem Podyplomowe Studia Menedżerskie erskie Zarządzanie projektami informatycznymi PMBOK a zarządzanie

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje

Bardziej szczegółowo

www.omec.pl 1 Konferencja "Bezpieczny Projekt" Wrocław 22 czerwca 2010

www.omec.pl 1 Konferencja Bezpieczny Projekt Wrocław 22 czerwca 2010 Od kartki i ołówka do systemu informatycznego, czyli jak wdrażano zarządzanie projektami u klienta Rinf Sp. z o.o. www.omec.pl 1 Co my rozumiemy pod pojęciem: PROJEKT Projekt: Ciąg zadań nastawionych na

Bardziej szczegółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

Zarządzanie projektami w NGO

Zarządzanie projektami w NGO Zarządzanie projektami w NGO Warsztaty dla Grupy Nowe Technologie Federacja Organizacji Służebnych MAZOWIA 4 września 2012 Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów

Bardziej szczegółowo

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r. Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne

Bardziej szczegółowo

Zarządzanie projektami a zarządzanie ryzykiem

Zarządzanie projektami a zarządzanie ryzykiem Ewa Szczepańska Zarządzanie projektami a zarządzanie ryzykiem Warszawa, dnia 9 kwietnia 2013 r. Agenda Definicje Wytyczne dla zarządzania projektami Wytyczne dla zarządzania ryzykiem Miejsce ryzyka w zarządzaniu

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Cena: 980 zł netto (1 osoba / 2 dni

Bardziej szczegółowo

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010. Autor: Jolanta Łabędzka-Benisz. www.omec.

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010. Autor: Jolanta Łabędzka-Benisz. www.omec. PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010 Autor: Jolanta Łabędzka-Benisz www.omec.pl W A R S Z A W A R Z E S Z Ó W W R O C Ł A W 1 Agenda Wstęp

Bardziej szczegółowo

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r.

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r. Zarządzanie ryzykiem teoria i praktyka Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r. Zarządzanie ryzykiem - agenda Zarządzanie ryzykiem - definicje Ryzyko - niepewne

Bardziej szczegółowo

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 Odpowiada na pytania: Jaka część projektów IT kończy się w Polsce sukcesem? Jak wiele projektów sponsorowanych jest przez instytucje publiczne? Czy kończą się

Bardziej szczegółowo

Extracted from web page

Extracted from web page Extracted from web page Page 1 Inwestycje w PLM Wiem jak ważna jest opłacalność? Punkt widzenia analityka Punkt widzenia inżyniera Punkt widzenia Zarządu Różne punkty widzenia Page 2 Pierwszy krok do Inwestycji

Bardziej szczegółowo

Rodziny - narzędzie dynamicznej analizy projektów

Rodziny - narzędzie dynamicznej analizy projektów Rodziny Narzędzie dynamicznej analizy Stanisław Gasik Sybena Consulting www.sybena.pl Software Project Management GigaCon, Warszawa, 23.09.2009 Portfele Zbiór, programów i innych prac, połączonych żeby

Bardziej szczegółowo

Zarządzanie Projektami IT. - Nowoczesny Project Manager Nowość

Zarządzanie Projektami IT. - Nowoczesny Project Manager Nowość Zarządzanie Projektami IT - Nowoczesny Project Manager Nowość Unikalność studiów Zarządzanie Projektami IT polega nie tylko na zgodności programu standardem PMI ale również na kompleksowym ujęciu problematyki

Bardziej szczegółowo

AGILE PROJECT MANAGEMENT

AGILE PROJECT MANAGEMENT AGILE PROJECT MANAGEMENT Agile Project Management oparte jest o metodę DSDM Atern (Dynamic Systems Development Method) najstarsze (1995r.) z usystematyzowanych podejść typu Agile na świecie. 1 CTPartners

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

Bardziej szczegółowo

Scaling Scrum with SAFe. Małgorzata Czerwińska

Scaling Scrum with SAFe. Małgorzata Czerwińska Scaling Scrum with SAFe Małgorzata Czerwińska Agenda 1. Wstęp 2. Współpraca zespołów scrumowych 3. Zarządzanie Programem 4. Podsumowanie Wstęp Skuteczność zespołów developerskich, realizujących projekty

Bardziej szczegółowo

Zmiana zasad rynkowych. Duża dynamika zmian. Brak ograniczeń związanych z lokalizacją organizacji. Brak ograniczeń w dostępie do technologii

Zmiana zasad rynkowych. Duża dynamika zmian. Brak ograniczeń związanych z lokalizacją organizacji. Brak ograniczeń w dostępie do technologii Strategiczna Karta Wyników jako element systemu zarządzania efektywnością przedsiębiorstwa Piotr Białowąs Dyrektor Departamentu Strategii Pełnomocnik Zarządu EnergiaPro Koncern Energetyczny SA Przyczyny

Bardziej szczegółowo

MANAGER INNOWACJI MODUŁY WARSZTATOWE

MANAGER INNOWACJI MODUŁY WARSZTATOWE MANAGER INNOWACJI MODUŁY WARSZTATOWE WARSZTAT I-A PRAWNO-TEORETYCZNE PODSTAWY PROJEKTÓW INNOWACYJNYCH Czym jest innowacja? Możliwe źródła Wewnętrzne i zewnętrzne źródła informacji o innowacji w przedsiębiorstwie.

Bardziej szczegółowo

Program Poprawy Efektywności Zakupów. Jak kupować, aby poprawiać rentowność?

Program Poprawy Efektywności Zakupów. Jak kupować, aby poprawiać rentowność? Program Poprawy Efektywności Zakupów Jak kupować, aby poprawiać rentowność? Oferta Zakupy Celem każdej firmy jest zdobycie dominującej pozycji na rynku, która przekłada się na poziom obrotów i zysków firmy.

Bardziej szczegółowo

CTPARTNERS W LICZBACH ~100% 4,9 >500. kompleksowe obszary zarządzania IT w ofercie. osób przeszkolonych z zakresu IT

CTPARTNERS W LICZBACH ~100% 4,9 >500. kompleksowe obszary zarządzania IT w ofercie. osób przeszkolonych z zakresu IT CTPARTNERS W LICZBACH 15 osób przeszkolonych z zakresu IT lat na rynku 40 000 4 kompleksowe obszary zarządzania IT w ofercie ~100% Zdawalności egzaminów po naszych szkoleniach szkoleń otwartych i zamkniętych

Bardziej szczegółowo

SKUTECZNE ZARZĄDZANIE PROJEKTAMI. Przeznaczenie zajęć, podstawowe cele i korzyści dla studentów:

SKUTECZNE ZARZĄDZANIE PROJEKTAMI. Przeznaczenie zajęć, podstawowe cele i korzyści dla studentów: SKUTECZNE ZARZĄDZANIE PROJEKTAMI Przeznaczenie zajęć, podstawowe cele i korzyści dla studentów: Celem cyklu wykładów i ćwiczeń jest opanowanie wiedzy i praktycznych umiejętności w zakresie zarządzania

Bardziej szczegółowo

COBIT 5 WHITE PAPER WSTĘP

COBIT 5 WHITE PAPER WSTĘP COBIT 5 1 CTPartners 2014 Dokument stanowi przedmiot prawa autorskiego przysługującego CTPartners S.A. z siedzibą w Warszawie. Zwielokrotnianie i rozpowszechnianie publikacji jest dozwolone wyłącznie za

Bardziej szczegółowo

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

Planowanie i realizacja zadań w zespole Scrum

Planowanie i realizacja zadań w zespole Scrum MetaPack IT Academy Uniwersytet Zielonogórski Planowanie i realizacja zadań w zespole Scrum Paweł Przybyła Professional Scrum Master (www.scrum.org) Planowanie i realizacja zadań w zespole Scrum Agenda:

Bardziej szczegółowo

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki: Rozdział pochodzi z książki: Zarządzanie projektami badawczo-rozwojowymi. Tytuł rozdziału 6: Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście adaptacyjne

Bardziej szczegółowo

Podstawy Zarządzania Projektami w Organizacjach

Podstawy Zarządzania Projektami w Organizacjach Podstawy Zarządzania Projektami w Organizacjach JAK DOBRZE ROZPOCZĄĆ PROJEKT 2010-05-14 Krzysztof Kamiński Przemysław Kotecki AGENDA Wprowadzenie do Zarządzania Projektami Rola rozpoczynania projektów

Bardziej szczegółowo

Compuware Changepoint. Portfolio Management Tool

Compuware Changepoint. Portfolio Management Tool Compuware Changepoint Portfolio Management Tool Compuware Changepoint Zintegrowane Zarządzanie Portfelem IT W dzisiejszym świecie czołowi użytkownicy IT podejmują inicjatywy dopasowania IT do strategii

Bardziej szczegółowo

Rok akademicki: 2014/2015 Kod: ZIE-2-307-s Punkty ECTS: 3. Poziom studiów: Studia II stopnia Forma i tryb studiów: -

Rok akademicki: 2014/2015 Kod: ZIE-2-307-s Punkty ECTS: 3. Poziom studiów: Studia II stopnia Forma i tryb studiów: - Nazwa modułu: Narzędzia informatyczne w zarządzaniu portfolio projektów Rok akademicki: 2014/2015 Kod: ZIE-2-307-s Punkty ECTS: 3 Wydział: Zarządzania Kierunek: Informatyka i Ekonometria Specjalność: -

Bardziej szczegółowo

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing ZARZĄDZANIE MARKĄ Doradztwo i outsourcing Pomagamy zwiększać wartość marek i maksymalizować zysk. Prowadzimy projekty w zakresie szeroko rozumianego doskonalenia organizacji i wzmacniania wartości marki:

Bardziej szczegółowo

Organizacyjny aspekt projektu

Organizacyjny aspekt projektu Organizacyjny aspekt projektu Zarządzanie funkcjonalne Zarządzanie między funkcjonalne Osiąganie celów poprzez kierowanie bieżącymi działaniami Odpowiedzialność spoczywa na kierownikach funkcyjnych Efektywność

Bardziej szczegółowo

Dyplom Post-MBA Strategiczne Zarządzanie Projektami. Post-MBA Diploma in Strategic Project Management

Dyplom Post-MBA Strategiczne Zarządzanie Projektami. Post-MBA Diploma in Strategic Project Management Dyplom Post-MBA Strategiczne Zarządzanie Projektami Post-MBA Diploma in Strategic Project Management Warszawa, listopad 2012 kwiecień 2013 Dyplom Post-MBA: Strategiczne Zarządzanie Projektami Uczestnicy

Bardziej szczegółowo

Asynchroniczne interfejsy WWW

Asynchroniczne interfejsy WWW Asynchroniczne interfejsy WWW Metodyki zwinnego wytwarzania oprogramowania mgr inż. Rafał Grycuk Strona służbowa: http://iisi.pcz.pl/~rgrycuk/ Kontakt: rafal.grycuk@iisi.pcz.pl Konsultacje: Środa, 12-14

Bardziej szczegółowo

Rola technologii w strategicznych transformacjach organizacji. Borys Stokalski

Rola technologii w strategicznych transformacjach organizacji. Borys Stokalski Rola technologii w strategicznych transformacjach organizacji Borys Stokalski 2011 Wiodący dostawca usług doradczych i rozwiązań IT w Polsce Połączenie doświadczenia i wiedzy ekspertów branżowych i technologicznych

Bardziej szczegółowo

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu Zarządzanie ryzykiem w projektach informatycznych Marcin Krysiński marcin@krysinski.eu O czym będziemy mówić? Zarządzanie ryzykiem Co to jest ryzyko Planowanie zarządzania ryzykiem Identyfikacja czynników

Bardziej szczegółowo

Zastosowania informatyki w gospodarce Projekt

Zastosowania informatyki w gospodarce Projekt Zastosowania informatyki w gospodarce Projekt dr inż. Marek WODA 1. Wprowadzenie Czasochłonność 2h/tydzień Obligatoryjne konto na portalu Assembla Monitoring postępu Aktywność ma wpływ na ocenę 1. Wprowadzenie

Bardziej szczegółowo

Screening i ranking technologii

Screening i ranking technologii Screening i ranking technologii Maciej Psarski Uniwersytet Łódzki Centrum Transferu Technologii Screening i ranking Selekcja idei, technologii, opcji, możliwości, rynków, Na wczesnych etapach rozwoju przedsięwzięcia

Bardziej szczegółowo

USPRAWNIANIE, DORADZTWO, KONSULTING

USPRAWNIANIE, DORADZTWO, KONSULTING USPRAWNIANIE, DORADZTWO, KONSULTING LEAN MANAGEMENT All we are doing is looking at a time line from the moment the customer gives us an order to the point when we collect the cash. And we are reducing

Bardziej szczegółowo

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla

Bardziej szczegółowo

BADANIE DOJRZAŁOŚCI PROJEKTOWEJ FIRM Z PÓŁNOCNEJ POLSKI

BADANIE DOJRZAŁOŚCI PROJEKTOWEJ FIRM Z PÓŁNOCNEJ POLSKI BADANIE DOJRZAŁOŚCI PROJEKTOWEJ FIRM Z PÓŁNOCNEJ POLSKI PODSUMOWANIE WYNIKÓW MAŁGORZATA KUSYK, KRZYSZTOF KAMIŃSKI - agenda AGENDA 1. Cel badania 2. Metoda 3. Wyniki 4. Wnioski - cel Celem badania było:

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)

Bardziej szczegółowo

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Konfiguracja modelowania w procesie wytwarzania oprogramowania Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na

Bardziej szczegółowo

Studium przypadku Bank uniwersalny

Studium przypadku Bank uniwersalny Studium przypadku Bank uniwersalny Przedsiębiorstwo będące przedmiotem studium przypadku jest bankiem uniwersalnym. Dominującą strategią banku jest przywództwo produktowe. Cele banku koncentrują się, zatem

Bardziej szczegółowo

Trwałość projektów 7 osi PO IG

Trwałość projektów 7 osi PO IG Warszawa, 6 października 2015 r. Konferencja podsumowująca wdrażanie 7 i 8 osi priorytetowej PO IG Trwałość projektów 7 osi PO IG Paweł Oracz Departament Strategii Systemu Informacyjnego Ministerstwo Finansów

Bardziej szczegółowo

STUDIA PODYPLOMOWE Zarządzanie Projektami

STUDIA PODYPLOMOWE Zarządzanie Projektami STUDIA PODYPLOMOWE Zarządzanie Projektami (Program studiów) Opracowanie: dr inż. Jacek Jakieła Program studiów Zarządzanie projektami 2 CEL STUDIÓW, ADRESAT I PROFIL ABSOLWENTA Studia podyplomowe Zarządzanie

Bardziej szczegółowo

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI Sprawne zarządzanie projektami Tworzenie planów projektów Zwiększenie efektywności współpracy Kontrolowanie i zarządzanie zasobami jak również pracownikami Generowanie raportów Zarządzaj projektami efektywnie

Bardziej szczegółowo

Korzyści z integracji danych klienta. Seminarium PIU Jakość danych w systemach informatycznych ZU Warszawa 25.03.2009 Przygotowała Ewa Galas

Korzyści z integracji danych klienta. Seminarium PIU Jakość danych w systemach informatycznych ZU Warszawa 25.03.2009 Przygotowała Ewa Galas Korzyści z integracji danych klienta Seminarium PIU Jakość danych w systemach informatycznych ZU Warszawa 25.03.2009 Przygotowała Ewa Galas Definicje CDI ( Customer Data Integration) koncepcja integracji

Bardziej szczegółowo

Projektowe Zarządzanie Jakością

Projektowe Zarządzanie Jakością Projektowe Zarządzanie Jakością Zarządzanie Projektami vs Jakość Marcin Koziorowski Cel wykładu Wspólny język Projekt Projekt? Projekt Przedsięwzięcie ograniczone w czasie, podjęte dla wytworzenia

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki. Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.

Bardziej szczegółowo

PODSTAWY ZARZĄDZANIA PROJEKTAMI

PODSTAWY ZARZĄDZANIA PROJEKTAMI Bogdan Miedziński PODSTAWY ZARZĄDZANIA PROJEKTAMI Dorocie żonie, wiernej towarzyszce życia 1 SPIS TREŚCI Wstęp................................................. 9 1. Zarządzanie projektami z lotu ptaka....................

Bardziej szczegółowo

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE OFERTA WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE W TWORZENIU MODELU AS-IS /Jest to przykład (wzór) oferty treść jest wypełniana na podstawie nie zobowiązujących rozmów i spotkań z Klientem, pracownikami

Bardziej szczegółowo

PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ

PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ Wykład 4. PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ 1 1.Ogólna charakterystyka koncepcji zarządzania jakością i kierunki ich zmian w czasie: W historycznym podejściu do zarządzania jako- ścią można wyróżnić

Bardziej szczegółowo

Rekomendacja D w obszarze zarządzania projektami na przykładzie rozwiązań w Banku Polskiej Spółdzielczości S.A.

Rekomendacja D w obszarze zarządzania projektami na przykładzie rozwiązań w Banku Polskiej Spółdzielczości S.A. Rekomendacja D w obszarze zarządzania projektami na przykładzie rozwiązań w Banku Polskiej Spółdzielczości S.A. Rekomendacja D UKNF SPIS TREŚCI Rekomendacja Nr 4: Zasady współpracy obszarów biznesowych

Bardziej szczegółowo

Komputerowe wspomaganie procesu planowania i kontroli projektu

Komputerowe wspomaganie procesu planowania i kontroli projektu \ Komputerowe wspomaganie procesu planowania i kontroli projektu Komputerowe wspomaganie procesu planowania i kontroli projektu Atrybuty operacyjne projektów: lista zadań WBS (struktura podziału pracy)

Bardziej szczegółowo

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

Bardziej szczegółowo

dialog przemiana synergia

dialog przemiana synergia dialog przemiana synergia SYNERGENTIA. Wspieramy Klientów w stabilnym rozwoju, równoważącym potencjał ekonomiczny, społeczny i środowiskowy przez łączenie wiedzy, doświadczenia i rozwiązań z różnych sektorów.

Bardziej szczegółowo

Zarządzanie projektami IT

Zarządzanie projektami IT Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie

Bardziej szczegółowo

Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16. Miejsce: Eureka Technology Park, Innowatorów 8

Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16. Miejsce: Eureka Technology Park, Innowatorów 8 Szkolenie Scrum w projektach IT (Agile) METRYCZKA: Szkolenie Scrum Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Temat: Zwinne Zarządzanie

Bardziej szczegółowo

Egzamin ITIL Foundation

Egzamin ITIL Foundation Egzamin ITIL Foundation Przykładowy arkusz egzaminacyjny A, wersja 5.1 Test wielokrotnego wyboru (tylko jedna odpowiedź jest prawidłowa) Instrukcja 1. Należy udzielić odpowiedzi na wszystkie 40 pytań.

Bardziej szczegółowo