Praktyczny przegląd metodyk zarządzania projektami

Transkrypt

1 Praktyczny przegląd metodyk zarządzania projektami INFORMATION TECHNOLOGY CONSULTANTS MARCIN LEDWOROWSKI Dyrektor Pionu Rozwoju Aplikacji w Grupie ANTARES

2 Agenda 1. O firmie GRUPA ANTARES 2. Definicje pojęć z zakresu PM 3. Metodyki prowadzenia przedsięwzięć 4. Prowadzenie przedsięwzięcia projektu zgodnie z metodyką 5. Firma doradcza jako Katalizator 6. Wnioski

3 1. Grupa Antares INFORMATION TECHNOLOGY CONSULTANTS

4 Grupa Antares sp. z o.o. (1993) Doradztwo strategiczne i informatyczne (zarządzanie projektami) Prezes i założyciel Andrzej Gogolewski Zatrudnia na stałe 11 osób oraz około 100 współpracowników (body shopping, freelancer s) Firma sieciowa członek Econsen.net INFORMATION TECHNOLOGY CONSULTANTS

5 ANTARES - doświadczenia zarządzanie projektami informatycznymi o różnej skali (Pekao S.A., PAP, BRE, PKO BP) wdrażanie informatyki w dużych organizacjach (Poczta Polska) zarządzanie projektami, zarządzanie pracą biurową i obiegiem dokumentów, analizy strategiczne (Poczta Polska, URTiP, MPiPS) systemy MIS/EIS (Bank Światowy, firmy doradcze z UE) tworzenie oprogramowania dla portali i zaawansowanych systemów internetowych (Idea Centertel, znalezione.pl )

6 Marcin Ledworowski o sobie 37 lat, dwie córki, MBA, mgr inż. Dyrektor Pionu Rozwoju Aplikacji Bankowość» Programista SABA Bydgoszcz (obecnie Softbank) 3 lata Oprogramowanie FK do obsługi firm» Programista, udziałowiec FIN s.c. 1 rok Bankowość» szef programistów, z-ca dyrektora IT,» dyrektor bankowości pocztowej Centrum Giro,» Bank Pocztowy 7 lat Usługi Internetowe ISP» Wiceprezes Zarządu, współzałożyciel» TopNet (sprzedane jako Internetia) 2 lata Usługi finansowe,» Zastępca Dyrektora Biura Informatyki» Poczta Polska - centrala - 3 lata Biznes internetowy» Dyrektor zarządzający, współtwórca» Znalezione.pl 1 rok Usługi doradcze» Konsultant, Dyrektor Pionu Rozwoju Aplikacji» Grupa Antares obecnie

7 Zmiany, zmiany Jedyną stałą rzeczą w życiu jest zmiana.

8 2. Definicje pojęć z zakresu PM

9 Definicje pojęć Projekt (przedsięwzięcie) (ang. Project) Zbiór uporządkowanych działań prowadzących do realizacji założonych celów (wytworzenia produktów, usług) w określonym czasie (harmonogram), za pomocą środków określonych w budżecie (z wykorzystaniem określonych zasobów). Projekt ma początek, etap realizacji i ma swój koniec!

10 Definicje pojęć Metodyka Zarządzania Projektami Zbiór zasad, technik, reguł, dokumentów, zaleceń, procesów itp. uporządkowanych i zestawionych dla realizacji pewnej kategorii projektów. Metodologia Zarządzania Projektami Nauka o metodykach zarządzania projektami. Nadzbiór wszystkich metodyk, uwypuklający ich wspólne cechy, rozwijający nowe zagadnienia itp. (zwykle mylona z Metodyką Zarządzania Projektami)

11 Definicje pojęć Zarządzanie Projektami - Project Management interdyscyplinarna dziedzina wiedzy wywodząca się z teorii organizacji i zarządzania. Program PM to opracowanie zasad, metod i technik umożliwiających sprawne prowadzenie przedsięwzięć przez grupy ludzi, prowadzących do uzyskania sukcesu: oczekiwanych rezultatów - wyników projektu. zestaw różnych celów, wielu projektów i działań

12 3. Metodyki prowadzenia przedsięwzięć

13 Zamkniete Klasyfikacja metodyk Sformalizowane, twarde zalecenia Realizowane wg ścisłych procedur Otwarte stosunkowo luźne zalecenia do stosowania elastyczne

14 Klasyfikacja metodyk postępowania Uniwersalne (Chestra,, PMI, Prince 2) Dziedzinowe Budownictwo» Architektoniczny projekt domu» Budowa autostrady Informatyka» projektowanie systemów i baz danych,» tworzenie oprogramowania,» wdrażanie systemów IT Wojskowość» Bitwa morska» Budowa bunkra atomowego Kosmiczne» Lot człowieka poza Ziemię» Loty wahadłowców Muzyczne» Wydanie nowej płyty muzycznej

15 Twórcy metodyk zarządzania projektami Organizacje rządowe i międzynarodowe NATO, UE, Np. rząd brytyjski Firmy na własny użytek Np. Microsoft, IBM, Oracle, Siemens BS, Inne Project Management Institute (PMBok) PRINCE 2 Rational Unified Process (RUP) Chestra (Siemens BS), Catalyst

16 Zarządzanie zmianami Każda zmiana w firmie napotyka opór Zmiana jest naruszeniem status quo Umowa Klienta z Dostawcą powoduje naturalny konflikt Istota konfliktu Klienta z Dostawcą Terminy, Zakres zadań Ścisłe definicje zakresu projektu Łatwiejsze zarządzanie zmianą - gdy mamy arbitra, zaufaną trzecią stronę,

17 Metodyki zarządzania zmianą Catalyst (CSC) Life Cycle Management Vision & Strategy Architecture Development Integration Deployment Operational Services Architectural Engineering Management Infrastructure Project Management Service Management Program Management Enterprise & Account Management Project management is a disciplined process for identifying, coordinating, and continuously focusing people and other resources to achieve project/contractual objectives within time, cost, resource, and quality constraints.

18 Metodyki zarządzania zmianą CHESTRA (przygotowana na podstawie Catalyst) Chestra zajmuje się rozpoczynaniem, motywowaniem, wdrożeniem, zarządzaniem i koordynowaniem zmian w instytucji. Chestra przygotowuje zmiany w instytucji w sześciu różnych obszarach, takich jak :» Procesy Biznesowe» Organizacja» Lokalizacja» Aplikacje» Technologia» Dane

19 Domains of Change Business Process Application Organization Technology Books Location Data Pr og ra m M g mt Framework (Methods, Approaches, Techniques) Vision and Strategy En Pr ab oc le es m s en Architecture Or ga Ch niz an ati ge on al Inf Te ra ch str nic uc al tur e Development Integration Deployment Operation Inf Fa ra cili str tie uc s tur e De ve lo p m en t Co or Pr oj ec t M an ag e m en Activities F Design Business Process Design Application Architecture... Activities and Work Products Work Products Models Plans Procedures Reports Workpapers Other Business Process Model View Application Architecture Model View... Training Support Reading Lists CBTs Instructor Led Training Tool Support Hypertext Office Project Management, (CASE) Productivity Support Templates Check Lists Examples Best Practice Database

20 Chestra Chestra traktuje przedsiębiorstwo jako sumę jego procesów biznesowych. Rozpoczyna od określenia pożądanych celów instytucji i zamienia je na pożądane cele procesów biznesowych Etap Zakres Cel Wizja i strategia - określenie celów biznesowych Instytucja - nakreślenie przyszłości - zdefiniowanie i ustalenie priorytetów obszarów biznesowych Architektura Obszar biznesowy/ - zaprojektowanie głównych procesów program - stworzenie struktury dla rozwoju aplikacji - zaplanowanie sposobu budowy kolejnych wersji Budowa wersja, pakiet do - całkowity projekt procesu opracowania - zbudowanie lub zakup aplikacji i infrastruktury dla wsparcia procesu Integracja wersja - potwierdzenie rozwiązania biznesowego Wdrożenie wersja miejsca instalacji za pomocą działającego pilota - wdrożenie wszystkich aspektów rozwiązania biznesowego w docelowych lokalizacjach Eksploatacja instytucja - używanie rozwiązania

21 Metodyki wdrażania systemów IT MICROSOFT - Microsoft Business Solutions ICL - system MAX (metodyka MAXIM) IFS - IFS Applications (metodyka AIM) Intentia-Vimex - system Movex (metodyka Implex) JBA - system JBA System 21 (metodyka JBA Advantage) QAD - system MFG/Pro (metodyka Q-Managment) Quantum - system MEGA (metodyka MEGA) Qumak - system Platinum/MMRP (metodyka Epicor i Kewill) SAP - system R/3 (metodyka AcceleratedSAP - ASAP) Scala - system Scala Global Series (metodyka Signature) TCH Systems - system Baan IV (metodyka Target) Digitland - system Digitland Enterprise i TE (metodyka własna) Exact Software - Exact (metodyka Extract II) Normax - system JDEdwards (metodyka REP) Hogart - system Fourth Shift (metodyka Fourth Shift) (źródło

22 Metodyki wdrażania systemów IT Microsoft Business Solutions Dostarczanie oprogramowania oraz usług wdrożeniowych dla małych i średnich przedsiębiorstw oraz dla oddziałów dużych korporacji. Realizacja za pośrednictwem partnerów. Wdrażanie głównie istniejących rozwiązań.

23 Metodyki tworzenia oprogramowania inżynieria oprogramowania Tradycyjne podejścia do tworzenia oprogramowania : Cykle życia systemu Podejście kaskadowe Podejście spiralne Szybkie wytwarzanie aplikacji (RAD) CASE - Modelowanie procesów i danych Lekkie (zwinne, sprawne) metodyki tworzenia oprogramowania

24 Zasady lekkich,zwinnych,, sprawnych metod(yk) ) tworzenia oprogramowania Adaptacja a nie predykcja Kod źródłowy jest dokumentem projektowym. Wymagania są nieprzewidywalne, niemniej jednak tą nieprzewidywalnością można i należy sterować. Adaptacja wymagań klienta i kosztu w zamian za dokładną kontrolę procesu wytwarzania. Najpierw ludzie potem procesy Programiści są odpowiedzialnymi profesjonalistami Proces wytwarzania powinien być zaakceptowany, a nie narzucony Programiści są w stanie podejmować wszystkie decyzje techniczne.

25 Lekkie metody(ki) ) tworzenia oprogramowania XP (Extreme Programming); Cristal Family; ADS (Adaptive Software Development); FDD (Feature Driven Development). DSDM (Dynamic System Development Method) (zespoły do 10 osób)

26 4. Prowadzenie projektu zgodnie z metodyką

27 Przykład nr 1 wzajemne zrozumienie DUŻY BANK POLSKI Z WŁOSKIM AKCJONARIUSZEM Do wykonania był system do raportowania złożonej sprawozdawczości ci obowiązkowej. Dostawca przygotował slajd z obrazkami, wyobrażenie dostawcy o procesie. Bank obejrzał, pytał, pokiwał głową z aprobatą. Następnego dnia oddał Dostawcy inny rysunek... Dostawca rozpoczął żmudny proces poprawiania własnego schematu czyli poprawiania swojej wizji na podstawie wizji klienta, Propozycja doradcy dla Dostawcy - zapomnijcie o swoim rysunku - zostawcie to tak, jak klient narysował (zrozumiał).

28 Metodyka a zdrowy rozsądek Praktyka zaleca używanie zdrowego rozsądku Brzytwa Ockhama Ockhama: Nie należy mnożyć bytów bez potrzeby - odrzucajmy to co zbędne Najprostsze wyjaśnienia bywają słuszne.. Quidquid agis, prudenter agas,, et respice finem. Cokolwiek czynisz, czyń roztropnie i zwracaj uwagę na zakończenie. e. Najpierw słuchajmy klienta..

29 Wykaz zadań Przygotowanie do Rozpoczęcia Projektu PRP1- Przygotowanie do rozpoczęcia PRP2- Opracowanie wizji projektu PRP3- Opracowanie planów projektu PRP4- Uzyskanie akceptacji PRP5- Przygotowanie zespołu PRP6- Ustalenie wsparcia

30 Dokument otwarcia, definicja projektu, metryczka Kontekst Przedmiot, opis Cel Kryteria osiągnięcia sukcesu Zakres Wyniki Harmonogram (etapy) Sposób realizacji Budżet Organizacja projektu i zespół projektowy Uwarunkowania i ograniczenia Ryzyko Niezbędny sprzęt i wyposażenie, inne zasoby Zakres (IT:zadania systemu, funkcje, dane, użytkownicy, lokalizacja, istotne wymagania niefunkcjonalne Budżet (analiza kosztów i korzyści, płatności i źródła finansowania)

31 Sponsor Typowe role w projekcie osoba na kierowniczym stanowisku (zwykle członek zarządu firmy) najbardziej zainteresowana w przeprowadzeniu przedsięwzięcia, odpowiadająca za jego realizację. Komitet sterujący (ang. Steering Committee) przedstawiciele obu stron podejmujący kluczowe decyzje w projekcie. Kierownicy projektu organizują pracę, czuwają nad realizacją, oddają projekt klientowi, kierują i odpowiadają za wszystkie obszary projektu (organizacja, finanse, terminy, produkty i ich jakość, zmiany i ryzyko, pracownicy, podwykonawcy itp.). Zespoły realizacyjne wykonują zdefiniowane części prac, pod ogólnym nadzorem kierownika ka projektu i zwykle pod bezpośrednim zarządem kierownika zespołu. Zespoły zapewniania jakości działają dla uzyskania produktów zgodnych ze specyfikacją i zatwierdzonymi zmianami (m.in. testerzy) Zespół kontroli zmian decyduje o zmianach ustaleń, np. poprawkach do kontraktu. Odbiorcy produktów przedstawiciele klienta odbierający uzyskane produkty i wykonujący codzienną ich eksploatację.

32 Przykład nr 2 znalezione.pl

33 Cel biznesowy Znalezione.pl Przygotować i wdrożyć nową usługę w Polsce Metodyka pracy w projekcie Specyfikacja wymagań Opis biznesowy usługi Projekt baz danych + ogólny projekt systemu Zespół 2 młodych programistów, 6-10 testerów, plastyk Dokumentacja w kodzie źródłowym + procedury organizacyjne tworzone w trakcie testowania Realizacja projektu Częste zmiany głównych wymagań biznesowych, rozszerzanie zakresu Precyzowanie niektórych obszarów w kolejnych iteracjach 6 miesięcy (zamiast zakładanych 4 miesięcy) Projekt zrealizowany z powodzeniem, z niewielkim odchyleniem budżetu

34 5. Doradca jako KATALIZATOR

35 Przykład nr 3 Brak chęci zrozumienia Bank zamierza uruchomić obsługę swoich produktów bankowych we wszystkich okienkach pocztowych. Bank posiada własnego Dostawcę systemu bankowego. Dostawcą okienkowego systemu IT dla operatora pocztowego jest spółka zależna wspólna z ogromną firma IT. Umowa jest prowadzona od wielu lat, system jest przestarzały i silnie zdecentralizowany (lokalne bazy danych). Bank posiada nowoczesny system scentralizowany z technologią umożliwiającą zdalny dostęp do swojego systemu. Dostawca systemu pocztowego nie e zgadza się na wdrożenie bezpośrednie systemu Banku w okienkach pocztowych. Bank, widząc brak możliwości technicznych realizacji swoich zadań ń zmusza swojego właściciela do akceptacji planu pośredniego umożliwiającego realizację strategii banku a polegającego na akceptacji podejścia mieszanego (bez systemu, ze starym systemem off-line i z nowym systemem on-line line). Ani Dostawca Banku ani Dostawca operatora pocztowego nie chce się ę podjąć roli integratora systemów. Projekt napotyka na ogromne trudności techniczne, trwa nadal od kilku lat bez sukcesu ani efektu rynkowego. Możliwe rozwiązanie powierzenie roli integratora niezależnej od Dostawców firmie, która pomoże w realizacji projektu biznesowego negocjując pomiędzy Dostawcami a ich klientami.

36 Przykład nr 4 - pomóżcie nam Ministerstwo zamówiło portal informacyjny, wielojęzyczny, który miał wspomagać ć realizację krajowego eksportu. Umowa z Dostawcą była podporządkowana zamówieniom publicznym. Do realizacji projektu wybrano firmę informatyczna z dobrymi referencjami jednak bez doświadczeń w zakresie kreowania biznesu internetowego. W zadanym czasie i budżecie uruchomiono wersję systemu. Politycy ogłosili szumnie start nowej inicjatywy na konferencji prasowej Podczas realizacji projektu wystąpiły problemy ze strony Ministerstwa z określeniem rzeczywistych potrzeb z uwagi na nowatorski charakter projektu. Ministerstwo zaczęło myśleć o sobie jak o firmie biznesowej, która ma zarabiać na swoich działaniach, aniach, czym wywołało konfuzję wśród portali komercyjnych. Dostawca zaniedbał etap analizy biznesowej ograniczony terminami kontraktu publicznego. Po jakimś czasie pojawiły się krytyczne opinie i artykuły. Portal był bojkotowany przez polskie placówki dyplomatyczne w innych krajach, które wolały używać dotychczasowych metod.. Propozycja Doradcy dla Klienta wróćmy do celów biznesowych projektu oraz oceńmy błędy realizacyjne projektu. Zmobilizuje to Ministerstwo do przemyślenia swojej roli wśród portali komercyjnych i być może skłoni Dostawcę do poprawy jakości portalu albo przygotowane zostaną założenia do nowej wersji portalu. Podczas ponownej analizy wymagań prowadzonej przez Doradcę Dostawca przyspieszył tempo zmian, poprawił znacznie wydajność przetwarzania systemu, błyskawicznie realizował uwagi zgłaszane przez doradcę już na etapie wywiadu Ministerstwo uzyskało nowe przełożenie na realizacje celu podstawowego promocji eksportu i zrezygnowało z chęci konkurowania z portalami komercyjnymi.

37 Firma doradcza jako katalizator Wizja Klienta Produkt Dostawcy Wizja dostawcy doradca Projekt Dostawcy i Klienta

38 Katalizator Doradca Ma pomagać, przyspieszać, zainicjować Doradca prowadzi Klienta w zrozumieniu Jego własnych problemów» przeprowadza Klienta za rękę przez mgłę Pomaga Klientowi zrozumieć postawę Dostawcy Pomaga Dostawcy zrozumieć rzeczywiste cele Klienta

39 Ewolucja metodyczna w Grupie ANTARES Początek - szybkie zastosowanie Zachłyśnięcie się (próba realizacji własnej metodyki GAME) Zniechęcenie (zarzucenie stosowania!) Dojrzałość niektóre elementy w praktyce, (m.in.używamy terminologii PRINCE 2)

40 Przykład nr 5 - pomóżcie mi DUŻA FIRMA PAŃSTWOWA W firmie prowadzono ponad 100 projektów na różnych szczeblach. Wiele W z projektów odbywało się wg zasad znanych jeszcze z epoki socjalizmu. Dyrektor generalny powoływał zespół, który działał kilkanaście miesięcy, od spotkania do spotkania. Po jakimś czasie zmieniało się kierownictwo firmy i projekty kończyły się niczym.. Wprowadzenie zasad prowadzenia projektów do regulaminu firmy oraz z jasne zasady finansowania projektów mogło spowodować uporządkowanie i racjonalizację prowadzonych zadań. Menedżerowie średniego szczebla w firmie, które dostrzegały taką potrzebę nie znajdowali zrozumienia w kierownictwie firmy. Ich propozycje były traktowane e jak wybujałe ambicje lub zagrożenie pozycji kierownictwa w firmie. Wypuszczono więc sygnał ł do doradcy Propozycja doradcy dla Klienta przygotujemy Firmie zbiór zasad prowadzenia projektów ściśle wg wskazówek kierownictwa i menedżerów średniego szczebla. Projekt został zrealizowany i wdrożony, gdyż znalazł zrozumienie w kierownictwie po tym kiedy doradca zewnętrzny zaproponował istotne zmiany w regulaminie ie firmy.

41 6. Wnioski Brzytwa Ockhama Nie należy mnożyć bytów bez potrzeby Stosuj tyle metodyki prowadzenia projektu ile jest potrzebne do sukcesu.. kontrakt - dokument otwarcia!!) Słuchaj klienta, a będzie Ci to wynagrodzone stokrotnie..

42 Kontakt tel