Czy PRINCE2 może być pomocny w zamówieniach publicznych Roman Dmowski Best Practice Showcase, 10 czerwca 2011 PRINCE2 jest znakiem handlowym Office of Government Commerce zarejestrowanym w Zjednoczonym Królestwie i innych krajach. MSP jest znakiem handlowym Office of Government Commerce zarejestrowanym w Zjednoczonym Królestwie i innych krajach. P3O jest zarejestrowanym znakiem handlowym Office of Government Commerce Swirl logo jest znakiem handlowym Office of Government Commerce. Logo OMEC jest znakiem handlowym OMEC Sp. z o.o.
CUW powstało na początku 2011 r. w skutek przekształcenia gospodarstwa pomocniczego Centrum Obsługi Kancelarii Prezesa Rady Ministrów Zadania zapewnienie technicznych warunków pracy Kancelarii Prezesa Rady Ministrów poprzez administrowanie i opiekę nad budynkami, świadczenie usług informatycznych oraz transportowych. wydawanie dzienników urzędowych:dziennik Ustaw, Monitor Polski, Monitor Polski B Pełnienie funkcji Centralnego Zamawiającego: przygotowywanie i przeprowadzanie postępowań o udzielenie zamówień publicznych, zawieranie umów ramowych na potrzeby jednostek administracji rządowej. 2
Problemy Zamówienia publiczne Kluczowe wymagania, istotne zapisy umowy muszą zostać stworzone na długo przed rozpoczęciem wdrożenia, nie można ich zmieniać Rozwiązanie Stosowanie metodyki PRINCE2 ułatwia realizację projektów: pozwala na unikanie powszechnie spotykanych błędów umożliwia kompleksowe zarządzanie jakością: strategia, kryteria jakości, kryteria akceptacyjne, egzekwowanie jakości Podejście produktowe pozwala precyzyjnie opisać zakres i stworzyć realny plan wdrożenia 3
Nie ma projektów IT, są zmiany biznesowe Problemy Rozwiązania i procesy IT nie są zintegrowane ze wszystkimi obszarami firmy Powstają systemy nikomu nie potrzebne, które utrudniają życie Podczas wdrożenia pojawia się konflikt IT kontra użytkownicy, biznes zwalcza inicjatywy IT lub jest pasywny w ich realizacji Rozwiązanie Projekt nie może być postrzegany jako projekt informatyczny projekt jest dla całej firmy i wszyscy go wdrażają (jest biznesowy) IT nie powinno kierować projektami? Powszechna akcja popularyzująca właściwe sposoby realizacji projektów (także wśród wyższego kierownictwa) 4
Wdrożenie to zawsze dwa projekty: Wykonawcy i Klienta Różne cele Klient chce dostać dużo, a mało płacić, Wykonawca chce mało robić, a zarobić dużo 5
Wdrożenie to zawsze dwa projekty: Wykonawcy i Klienta Problemy Klient chce, aby wszystko wykonano za niego, nie angażuje się projekt, nie zarządza projektem, Klient nie ma swojego Kierownika Projektu Kierownik Projektu Wykonawcy jest bezradny w środowisku Klienta; nie ma szans na zaktywizowanie pracowników Klienta do współpracy Wykonawca może wykorzystać brak kierowania i nadzoru nad projektem po stronie Klienta Rozwiązanie Kompetentny Kierownik Projektu ze strony Klienta Postrzeganie przedmiotu zamówienia jako tylko części projektu Klienta (Grupy Zadań wg. PRINCE2) Postrzeganie Wykonawcy jako jednego z zespołów w projekcie Klienta Odrębne Komitety Sterujące Klienta i Wykonawcy 6
Problemy Kompetentny Kierownik Projektu Przypadkowy Kierownik Projektu (z łapanki albo honorowy Kierownik Projektu - np. Naczelnik Wydziału IT osoba na ważnym stanowisku, ale czy będzie miał czas na codzienne kierowanie projektem) Brak Kierownika Projektu (lub jest od zewnętrznego Wykonawcy) Wielu Kierowników Projektów Rozwiązanie Kierownik Projektu - kompetentna osoba, neutralna dla wszystkich stron projektu (niezwiązana z konkretnym działem), sojusznik użytkownika, informatyka, prezesa Kierownik Projektu z własnego działu Zarządzania Projektami lub z zewnętrz 7
Zakres projektu obejmujący wszystkie obszary Problemy Fragmentacja projektu po działach Pewne obszary niczyje lub powielają się 8
Ostrzeżenie przed fragmentacją projektu!!! DZIAŁ 3 DZIAŁ 2 DZIAŁ 1 DZIAŁ 5 DZIAŁ 4? A kto dostarczy pustą część? Dlaczego niektóre obszary się przecinają? 9
Zakres projektu obejmujący wszystkie obszary Problemy Fragmentacja projektu po działach Pewne obszary niczyje lub powielają się Rozwiązanie Całościowy obraz firmy po zakończeniu projektu - POTI (P procesy, O organizacja, T technologia i narzędzia, I Informacja) 10
Tak!!! Produkt 3 Produkt 2 Produkt 1 Produkt 5 Produkt 4 PRODUKT KOŃCOWY PROJEKTU 11
Zakres projektu obejmujący wszystkie obszary Problemy Fragmentacja projektu po działach Pewne obszary niczyje lub powielają się Rozwiązanie Całościowy obraz firmy po zakończeniu projektu - POTI (P procesy, O organizacja, T technologia i narzędzia, I Informacja) Planowanie oparte na produktach: produktem projektu jest zmieniona firma: nie tylko system IT, ale nowe sposoby funkcjonowania, nowe/zmienione stanowiska pracy, działanie marketingowe ) 12
Planowanie oparte na produktach NOWA USŁUGA Pracownicy przeszkoleni Kampania marketingowa przeprowadzona System informatyczny zmodyfikowany Analiza przeprowadzona Zmiany w systemie wprowadzone 13
Jakość nie jest za darmo (1) Problemy Uzyskujemy produkt, który nie spełnia faktycznych potrzeb, zwłaszcza tych subiektywnych (np. system ma być intuicyjny) Spory pomiędzy wykonawcą a klientem, czy przedmiot zamówienia został w pełni zrealizowany Rozwiązanie Pełna lista kryteriów jakości (np. większość przeszkolonej kadry radzi sobie z systemem) Konkretne kryteria akceptacyjne mierzalne, pozwalające jednoznacznie ocenić, czy dane kryterium zostało spełnione ( np. z poziomu menu głównego dotarcie do dowolnej funkcji w systemie nie wymaga więcej niż 3 kliknięć) 14
Problem Zapis w umowie Jakość nie jest za darmo (2) np. Dostarczony system objęty jest gwarancją producenta, każdy błąd zostanie naprawiony nie oznacza, że system będzie niezawodny, stabilny, dostępny do użycia Rozwiązanie Pełna lista kryteriów jakości Konkretne kryteria akceptacyjne (poziom zgłoszeń o pomoc na helpdesku wynosi co najwyżej 10 zgłoszeń w miesiącu) Egzekwowanie jakości (np. każde kolejne zgłoszenie powyżej 10-tego powoduje naliczenie kary; przekroczenie progu 20-stu zgłoszeń rodzi dodatkowo konieczność powtórzenia szkolenia przez Wykonawcę na jego koszt) 15
Jakość nie jest za darmo testy produktu (1) Problemy Klient nie ma działu kontroli jakości wszystkie testy przeprowadzają użytkownicy. Jeżeli testy trzeba wielokrotnie powtarzać pojawia się niechęć do projektu Wspólne testy przeprowadzane są na bazie planów testów opracowanych przez Wykonawcę. Plan testów może pomijać niedopracowane obszary. Nieuznawanie błędów wywoływanych czynnościami, które nie były zaplanowane do testów Rozwiązanie Klient musi mieć własny (lub zewnętrzny) zespół jakości lub należy wprowadzić system kar dla Wykonawcy ( np. 50 zł za każdy wykryty błąd w produkcie przekazanym do odbioru) Wykonawca najpierw musi przetestować u siebie produkt, zanim przekaże go do odbioru Klientowi 16
Jakość nie jest za darmo testy produktu (2) Problemy Wykonawca przekonuje, że system należy odebrać mimo błędów, bo w tak złożonym systemie zawsze muszą być błędy lub Klient nie chce podpisać protokołu odbioru, bo np. znalazł 1 błędny rekord w bazie danych zawierającej 24 miliony rekordów Rozwiązanie Precyzyjny opis poziomu jakości dla dokonania odbioru uzgodniony na początku projektu, np. w momencie odbioru system ma rozwiązane wszystkie znane błędy 17
Jakość nie jest za darmo testy produktu (3) Problemy Odbiór produktu zrealizowano na podstawie testów cząstkowych, przeprowadzonych na środowisku testowym. W środowisku produkcyjnym pojawiają się problemy z wydajnością, trudno się dodzwonić do serwisu. Użytkownicy mimo, że byli na szkoleniach nie potrafią korzystać z systemu. Rozwiązanie Wprowadzenie produktu Po Przejściu (potwierdzenie stabilności pracy w nowym stanie biznesowym np. 3 miesiące nowej, ustabilizowanej sytuacji). Dopiero odbiór tego produktu jest podstawą do wypłaty wynagrodzenia dla wykonawcy 18
Planowanie Produktowe jest najważniejsze (1) Pozwala ustalić zakres projektu obejmujący wszystkie obszary Produkt końcowy Analiza Sprzęt Prototyp systemu System Dokumentacja Szkolenia Marketing Przejście Po Przejściu Serwis 19
Planowanie Produktowe jest najważniejsze (2) Produkt końcowy i każdy jego produkt są dokładnie opisywane, m.in.: zawartość (np. wszystkie funkcje) kryterium jakości, akceptacyjne kompetencje osób zaangażowanych i osób dokonujących odbioru metoda odbioru Precyzyjny opis produktów pozwala ułożyć precyzyjny plan wdrożenia Czas (harmonogram) Koszty Zasoby (wszystkie niezbędne osoby) Działania jakości Odbieramy produkt końcowy dopiero wtedy, gdy wszystkie jego produkty składowe są prawidłowe i produkt końcowy spełnia oczekiwania jakościowe i kryteria akceptacyjne 20
Siła produktu końcowego Nie mogę odebrać przedmiotu zamówienia. System działa, pracownicy zaliczyli szkolenie, ale nie potrafią systemu obsłużyć. Ergo to nie jest ten produkt końcowy 21
Podsumowanie (1) Zamówienia publiczne to trudny obszar dla realizacji projektów (ograniczenia ustawowe) dlatego trzeba stosować strukturalne podejście Wykonawca zewnętrzny nie rozwiąże wszystkich naszych problemów Podejście PRINCE2 ułatwia realizację projektów, pozwala na unikanie powszechnie spotykanych błędów 22
Podsumowanie (2) Traktujemy projekt jako zmianę biznesową Klient musi mieć Kierownika Projektu Planujemy produktowo U zewnętrznego dostawcy przedmiotem zamówienia są Grupy Zadań z produktami, a nie cały projekt Troska o jakość: strategia, kryteria jakości, kryteria akceptacyjne, egzekwowanie jakości 23
Czy PRINCE2 może być pomocny w zamówieniach publicznych Roman Dmowski Best Practice Showcase, 10 czerwca 2011 PRINCE2 jest znakiem handlowym Office of Government Commerce zarejestrowanym w Zjednoczonym Królestwie i innych krajach. MSP jest znakiem handlowym Office of Government Commerce zarejestrowanym w Zjednoczonym Królestwie i innych krajach. P3O jest zarejestrowanym znakiem handlowym Office of Government Commerce Swirl logo jest znakiem handlowym Office of Government Commerce. Logo OMEC jest znakiem handlowym OMEC Sp. z o.o.