Przygotowano dla Uniwersytetu Wrocławskiego -- tylko do uŝytku wewnętrznego. 2009 Capgemini Polska Wszelkie prawa zastrzeŝone Zarządzanie projektami informatycznymi w Capgemini Software Solutions Center we Wrocławiu Wrocław, 1.12.2009 Andrzej Łączny andrzej.laczny@capgemini-sdm.com
Agenda Capgemini Software Solutions Center i Capgemini sd&m AG Dlaczego powinniśmy zarządzać projektami? Rola kierownika i menedŝera projektu epm, czyli Efficient Project Management Przykład projektu 2
Informacje o firmie - Capgemini to jedna z największych firm konsultingowych na świecie, - lider w świadczeniu zintegrowanych usług doradczych, informatycznych i outsourcingowych, - największa europejska firma konsultingowa. - We wrocławskim Software Solutions Center tworzymy zaawansowane systemy informatyczne dla branŝy motoryzacyjnej, ubezpieczeniowej, bankowej i logistycznej. - Przy realizacji projektów współpracujemy z firmą Capgemini sd&m AG, która jest niemieckim oddziałem Capgemini. - Obecnie w naszym oddziale pracuje ponad 150 osób - planujemy się dalej dynamicznie rozwijać 8,7 mld EUR przychodu w 2008 91 000 specjalistów w 300 biurach, w 30 krajach na całym świecie 2000 specjalistów w Polsce w biurach w Warszawie, Krakowie, Katowicach i Wrocławiu 3
Agenda Capgemini Software Solutions Center i Capgemini sd&m AG Dlaczego powinniśmy zarządzać projektami? Rola kierownika i menedŝera projektu epm, czyli Efficient Project Management Przykład projektu 4
Projekty informatyczne są trudne i często kończą się niepowodzeniem Typ Succeeded : Projekt został wykonany w zaplanownym czasie i budŝecie oraz ze wszystkimi przewidzianymi funkcjami. Typ Failed : Projekt został przerwany podczas rozwoju, nie był rentowny. Typ Challenged : Projekt zakończony, jednak przekraczający planowany budŝet oraz z mniejszą ilością funkcji niŝ zakładano w specyfikacji. Źródło: CHAOS Report 2004 Standish Group www.standishgroup.com 5
Problemów w projekcie moŝna uniknąć wcześnie je identyfikując i zapobiegając im nim zdąŝą zaistnieć Niejasno sprecyzowany cel Niesprecyzowane wymagania i specyfikacja Realizacja nadmiaru wymagań Brak zaangaŝowania uŝytkowników Brak zaangaŝowania Top-Managementu Nierealne terminy, zły plan Brak / niedoświadczeni pracownicy 6
Niejasno sprecyzowany cel, niejasne i błędne wymagania Skutki Nadmierne skupianie się na funkcjonalności Luki w specyfikacji Niespójność systemu Przeciwdziałania Spojrzenie na cele w kontekście procesów biznesowych Analiza wymagań Przeprowadzenie fazy stabilizacji 7
Brak zaangaŝowania Top-Managementu klienta Skutki Lista Ŝyczeń Brak priorytetów Zbędna funkcjonalność systemu Przeciwdziałania Ustalanie priorytetów Wspólne planowanie 8
Brak zaangaŝowania uŝytkowników Skutki Zbędne funkcjonalności systemu Wycofanie zleceń Nieporozumienia Niezadowolenie z końcowego produktu Przeciwdziałania Warsztaty analizy wymagań Specyfikacja z klientem Review dokumentacji przez klienta Testowanie systemu przez klienta 9
Nierealne terminy / zły plan Skutki Utrata zaufania klienta Firma staje się niewiarygodna Przeciwdziałania Rzetelna kalkulacja ceny oferty Wykorzystywanie narzędzi planowania Proces zarządzania ryzykiem 10
Niedoświadczeni pracownicy Skutki Mała efektywność Niedotrzymywanie terminów DuŜe koszty wdroŝenia DuŜe obciąŝenie pracowników Przeciwdziałania To ludzie realizują projekty Inwestowanie w pracowników Szkolenia Task force 11
Agenda Capgemini Software Solutions Center i Capgemini sd&m AG Dlaczego powinniśmy zarządzać projektami? Rola kierownika i menedŝera projektu epm, czyli Efficient Project Management Przykład projektu 12
Zarządzanie projektem to poszukiwanie optymalnego zakresu, terminu i budŝetu Więcej wymagań Mniej wymagań Zakres Jakość DłuŜszy czas realizacji Krótszy czas realizacji Termin BudŜet WyŜsze koszty NiŜsze koszty 13
MenedŜer i kierownik projektu Ogólna organizacja projektu Kierownik projektu Specjalista ds. zarządzania wiedzą Specjalista ds. zarządzania jakością Manager projektu Kierownik projektu Główny Analityk Główny Architekt Ponosi odpowiedzialność za wyniki, funkcjonalność, terminy, jakość oraz budŝet projektu Kieruje zespołem, kontroluje i ocenia jego uczestników. Aby zbudować z poszczególnych pracowników projektu efektywny team, planuje i kieruje zadaniami, daje instrukcje, nie wykonuje sam wszystkich zadań. Wykrywa problemy w odpowiednim czasie i eskaluje je w odpowiednim miejscu. Podprojekt 1 Kierownik podprojektu... Podprojekty n Manager projektu Manager projektu jest odpowiedzialny za cały projekt: przed klientem (termin, wynik) oraz przed zarzadem sd&m (wynik) Zespół Zespół Udostępnia projektowi do dyspozycji potrzebne zasoby: pracowników, budŝet, pomieszczenia itp. oraz mianuje PL, TCD, FCD und QB. Utrzymuje kontakt z osobami odpowiedzialnymi za podejmowanie decyzji, omawia z nimi postępy, terminy, negocjuje zmiany budŝetu ( Minister spraw zewnętrznych ) 14
Zadania kierownika projektu Cele Jasno i precyzyjnie definiować cele Organizacja Podejmowanie decyzji Struktura i procesy Zespół musi dobrze funkcjonować Lepsza jakakolwiek decyzja niŝ Ŝadna Kontrola Kontrola i ocena Wspieranie pracowników Feedback Rozwijać mocne strony, słabe czynić nieistotnymi 15
Przykładowa organizacja zespołu: projekt Catalog Editor MenedŜer projektu Kierownik projektu Główny architekt Specjalista ds. zarządzania jakością Realizacja Team I Monachium Realizacja Team II Wrocław Testy Integracyjne Szkolenia TL InŜynier oprogramowania InŜynier oprogramowania InŜynier oprogramowania InŜynier oprogramowania TL InŜynier oprogramowania InŜynier oprogramowania InŜynier oprogramowania TL InŜynier oprogramowania InŜynier oprogramowania Specjalista ds. szkoleń 16
Przykładowa organizacja zespołu: projekt eadmin Departament Manager Business Unit Manager Wrocław Mitglied LA Klient HAM / BLN Kierownik / MenedŜer projektu 33 Skeretariat Główny analityk Wrocław Testmgr. / QM Główny projektant 4 2 2 Główny architekt techniczny Szef zespołu realizacyjnego 21 Tester Projektant Developer PMO WRO Tester 5 Teamleader Zespół 1 Teamleader Zespół techniczny Teamleader Zespół 2 Teamleader Zespół 3 5 3 4 2 Teamleader Zespół 4 Tester Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer 17
Agenda Capgemini Software Solutions Center i Capgemini sd&m AG Dlaczego powinniśmy zarządzać projektami? Rola kierownika i menedŝera projektu epm, czyli Efficient Project Management Przykład projektu 18
Zarządzanie projektami według Capgemini sd&m Tworzenie indywidualnego oprogramowania Metodologia Kompatybilność z PMI Ciągły rozwój metody w ramach dedykowanej jednostki badawczej Zgodność z RUP, inkrementalny model projektu Wsparcie dla realizacji w rozproszonych lokalizacjach (Rightshore ) Procedura szacowania Sprawdzony model kosztów projektu Nieustanna kalibracja wynikami aktualnie kończonych projektów Szacowanie nakładów oparte o metodę ekspercką oraz metodę Use Case Points Edukacja Wieloetapowy program szkoleniowy Wsparcie certyfikacji PMI Quality Management System certyfikowany ISO Edukacja wbudowana w ścieŝkę kariery menedŝerów projektu Narzędzia Optymalny zestaw narzędzi oparty o standardy istniejące na rynku oraz o własne standardy firmowe Earned Value Analysis 19
Model zarządzania projektem epm opiera się na cyklu Oferta Kick-off Realizacja projekt Touch-down Powstawanie projeku Przeprowadzanie projektu Koniec projektu Hard facts Team Czynniki zewn. Weryfikacja Oferta Inicjalizacja Zakończenie Wykonanie Kierowanie projektem Obserwacja Planowanie Ocena W aŝne czynności Szacowanie Planowanie pracowników Kickof O bserwacja, ocena, planowanie, wykonywanie i weryfikacja Kierowanie zespołem Zarządzanie współpracą z klientem Touchdown Istotne w yniki Term inarz Analiza nakładu pracy W stępny plan projektu Aktualny plan projektu Raportowanie Bilans po zakończeniu projektu 20
Narzędzie planowania cztery spojrzenia na plan projektu Podstawa: Struktura projektu (Work Breakdown Structure) Plan nakładów (budŝet) Plan zespołu Plan terminowy 21
Struktura projektu to pełny, oparty o hierarchię podział projektu na zadania i pakiety robocze 22
Plan nakładów (budŝet) to widok na zadania wraz z informacją dotyczącą nakładu pracy 23
Model kosztów Projekt In Releases PI Projektinhalt UM Umsetzung 100% = Netto SP Spezifikation SP-IST IST-Systemanalyse KON Konstruktion KON-T Konstr. der T-Komponenten REA Realisierung REA-T Rea T-Komponenten INT Integration INT-TVO alle Testvorbereitungen IB Inbetriebn. IB-ABN Abnahme SP-ALLG Allg. Spezifizikationsaufwände SP-THEMA Spezifikation von Themen und Daten SP-NACH Nacharbeiten (FK V1.1) KON-A Konstr. der A-Komponenten KON-DB Konstruktion DB-Design & Datentypen KON-MIG Konzeption v. Migration etc. KON-ALLG Allg. Konstruktionsaufwand REA-A Rea A-Komponenten REA-DB Aufbau und Pflege DB REA-MIG Migration & Erstbefüllungen INT-SYS (Sub-) Systemtest INT-VBD Verbundtest INT-BUGFIX Felerbehebung INT-NFKT Nicht-Funktionale Tests IB-EIN Einführung & Betrieb IB-DOK Dokumentationen IB-SCHUL Schulungen SP-QS QS auf Spezifikation KON-QS QS in der Konstruktion REA-QS QS in der REA INT-QS Durchführung QS IB-QS Durchführung QS PQ Projektquerschnitt PK Projektkoordination PK-PL Projektleitung PK-CD Chefdesign PK-PM Projektmanagement PK-QK Qualitätsmanagement PK-MTG Meetings PT Projekttechnik PT-TI Technische Infrastruktur PT-KM Konfigurations-/ Releasemanagement PT-SEU Software- Entwicklungsumgebung PN Projektnebenaufwände CR Change Requests PN PN-EIN Einarbeitung, Teamaufbau PN-REISE Reisezeiten BERAT Beratung PN-STORT Mehrere Standorte 24
Procentowy udział kosztów zaleŝy od specyfiki projektu Klasa I (nowy projekt w nowym środowsku > 500 BT) PI PQ PN 7% SP 22% 40% PN 7% von PI KON 15% REA 32% PQ 40% von PI (32% PK + 8% PT) INT 26% IB 5% = 100% (Netto) Wszyskie (średnia wszyskich ukończonych projektów sd&m) PI PQ PN 6% SP 19% 34% PN 6% von PI KON 13% REA 40% PQ 34% von PI (28% PK + 6% PT) INT 24% IB 4% = 100% (Netto) Klasa II Nowy projekt / kolejny release w znanym środowisku < 1.000 BT PI PQ PN 5% SP 17% 30% PN 5% von PI KON 11% REA 45% PQ 30% von PI (24% PK + 6% PT) INT 24% IB 3% = 100% (Netto) 25
Plan zespołu zawiera dostępność oraz obciąŝenie wszystkich pracowników w projekcie 26
Plan terminów to widok na czasowy przebieg zadań wraz z realizującymi je pracownikami 27
Czas trwania projektu i wielkość zespołu Reguła Freda Brooks a Optymalna wielkość zespołu = Koszt w RM Czas t Okres realizacji Komunikacja w zespole Mniejsza moŝliwość paralelizacji zadań Większy nakład na koordynację Część produktywna Optymalna wielkość zespołu Liczba pracowników n 28
Budowa zespołu w projekcie TANGO Teoria Optymalna wielkość zespołu = Koszt w RM Praktyka Wskaźnik przekroczony 2,5 krotnie 29
Touchdown umoŝliwia sprawdzenie wyników oraz zweryfikowanie procesów Kalkulacja po zakończeniu projektu: porównanie rzeczywistych kosztów po zakończeniu projektu z kosztami oszacowanymi na początku dyskusja nad przyczynami powstałych róŝnic Touchdown: zabezpieczyć istotne wyniki zarchiwizować dokumenty projektu zorganizować workshop z teamem: refleksja nad tym co było dobre, a co złe, dyskusja, feedback, przedstawienie historii projektu, a przede wszystkim podkreślenie jego znaczenia i świętowanie sukcesu! 30
Agenda Capgemini Software Solutions Center i Capgemini sd&m AG Dlaczego powinniśmy zarządzać projektami? Rola kierownika i menedŝera projektu epm, czyli Efficient Project Management Przykład projektu 31
Zarządzanie projektem w sytuacjach trudnych Catalog Editor Stan wyjściowy Cel: Content Management System do zarządzania danymi o produktach, oparty o produkt ecls (RCP client) 2. Quartal 3. Quartal 4. Quartal 1. Quartal 2. Quartal 3. Quartal Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Jan Feb Mrz Apr Mai Jun Jul CatalogEditor-Neu, Gesamt Specyfikacja cz. 1 2007 2008 Konstrukcja i Implementacja cz.1 Migracja Testy Workflow / Aufgabenliste SST PRT > Office (Office-Output) Benutzer- und Rechteverwaltung Querschnitt Online-Hilfe Testy akceptacyjne Specyfikacja cz.2 Workflow Aufgabenerz. Datensichtbarkeit Berechtigungs -prüfung Konstr. Impl. Cz.2 Testy Testy akceptacyjne Migracja 32
Zarządzanie projektem w sytuacjach trudnych Catalog Editor Pierwszy problem przedłuŝenie się fazy specyfikacji części 1-szej o 4 tygodnie Powody DuŜo bardziej skomplikowana logika biznesowa, niŝ zakładano Niedoświadczony zespół specyfikatorów Niewystarczająca znajomość produktu, na którym miał opierać się system Przeciwdziałania Pertraktacje z klientem w celu okrojenia funkcjonalności, podzielenia części 1 systemu na części 1a i 1b zakończone sukcesem ZaangaŜowanie dwóch bardzo doświadczonych kolegów do projektu (specyfikacja i testy, implementacja) ZaangaŜowanie specjalisty w zakresie produktu, na którym opiera się system 33
Zarządzanie projektem w sytuacjach trudnych Catalog Editor Pierwszy problem przedłuŝenie się fazy specyfikacji części 1-szej o 4 tygodnie 2007 2008 2. Quartal 3. Quartal 4. Quartal 1. Quartal 2. Quartal 3. Quartal Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Jan Feb Mrz Apr Mai Jun Jul CatalogEditor-Neu, Gesamt Specyfikacja Część 1a Konstrukcja i Implementacja Część 1a Migracja Testy T. Akceptacyjne Spec. i Implemen. Część 1b Specyfikacja 2 Implementacja 2 Testy T. Akceptacyjne Migracja 34
Zarządzanie projektem w sytuacjach trudnych Catalog Editor Implementacja 1a jakość komponentów niezadowalająca, problemy techniczne, opóźnienia w realizacji Powody DuŜo bardziej skomplikowana technika od zakładanej Niewystarczające doświadczenie w technologii produktu bazowego i programowanie RCP Zbyt optymistyczne oszacowanie zadań Przeciwdziałania Pertraktacje z klientem zmniejszenie funkcjonalności w fazie 1a ZaangaŜowanie dodatkowych 3 pracowników do implementacji oraz 2 pracowników do testów integracyjnych PrzedłuŜenie fazy BugFixingu/stabilizacji systemu Efekt Część 1a oddana w terminie, ale z wieloma błędami Stabilność aplikacji na niskim poziomie 35
Zarządzanie projektem w sytuacjach trudnych Catalog Editor Implementacja 1a 2007 2008 2. Quartal 3. Quartal 4. Quartal 1. Quartal 2. Quartal 3. Quartal Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Jan Feb Mrz Apr Mai Jun Jul CatalogEditor-Neu, Gesamt Specyfikacja Część 1 Konstrukcja i Implementacja Część 1 Migracja Testy Stabilizacja T. Akceptacyjne Analiza wyników cz. 1a Spec. i Implemen. Część 1b 36
Zarządzanie projektem w sytuacjach trudnych Catalog Editor 1a zakończenie Release 1a - rezultat DuŜo większe nakłady pracy niŝ zakładano Dopasowywanie produktu bazowego do róŝnych wymagań fachowych moŝliwe, ale czasami bardzo kosztowne Zbyt krótka faza konstrukcji niektórych komponentów Podjęte działania przed realizacją kolejnych części systemu Program naprawczy przeprowadzony przez bardzo doświadczonych pracowników Dokładne oszacowanie, w jakim punkcie znajduje się projekt Sprawdzenie jakości wykonania poszczególnych komponentów Ponowne oszacowanie zadań dla kolejnych części systemu Maksymalne dopasowanie potrzebnej funkcjonalności do tego co oferuje ecls, przedstawienie wyników klientowi PrzedłuŜona faza konstrukcji przed rozpoczęciem implementacji poszczególnych komponentów 37
Zarządzanie projektem w sytuacjach trudnych Catalog Editor Zakończenie projektu Wynik Mocno przekroczony budŝet Mocno przekroczony termin części 1a Powolna odbudowa zaufania u uŝytkowników systemu (po części 1a uŝytkownicy nastawieni sceptycznie z powodu duŝej liczby błędów w systemie) Kolejne części systemu skończone w terminie, zgodnie z budŝetem i zaplanowanymi zasobami Zdobyte zaufanie u klienta, szansa na kolejne duŝe projekty 38
Zusammen. Für nachhaltigen Erfolg. 39