Wprowadzenie do prowadzenia projektów informatycznych. Prezentacja Michała Bukowskiego z 2009 r.

1. czyli... szczypta teorii i kocioł praktyki.czyli... szczypta teorii i kocioł praktyki.
Projekty internetowe: książka kucharskaProjekty internetowe: książka kucharska

2. Szczypta teorii
Koncepcja projektu informatycznego
Efektywne zarządzanie poprzez projekty
Kocioł praktyki
Receptury na skuteczne prowadzenie
projektów
Posłowie
czyli dlaczego projekty się nie udają...
Agenda prezentacjiAgenda prezentacji

3. Szczypta teoriiSzczypta teorii

4. Projekt to zbiór działań charakteryzujący się
następującymi cechami:
są ze sobą powiązane w złożony sposób,
zmierzają do osiągnięcia celu, często poprzez
wytworzenie unikalnego produktu, usługi bądź
rezultatu (np. pracownicy legitymujący się
certyfikatem ukończenia szkolenia),
posiadają zaplanowany z góry początek i koniec.
ProjektProjekt

5. W projekcie informatycznym - internetowym lub
mobilnym - istotne produkty lub znacząca liczba
produktów są systemami informatycznymi
dostępnymi przez następujące kanały dostępu:
sieć internetowa,
sieć telefoniczna.
Projekt IT: internetowy, mobilnyProjekt IT: internetowy, mobilny

6. System informatyczny (SI) jest zwykle skomplikowanym
zbiorem elementów przetwarzających dane, którego
zasad działania biznes w pełni nie rozumie.
Ze względu na unikalność i skomplikowanie SI bardzo
trudno przewidzieć, czy projekty IT zakończą się
sukcesem. Pełna wiedza: na końcu projektu.
Sukcesem: SI stworzony na czas, zgodny z
wymaganiami funkcjonalnymi i pozafunkcjo-
nalnymi, gdzie poniesiony koszt mieści się
w ramach przewidzianego budżetu.
Dlaczego trudno jest tworzyć systemy
informatyczne?
Dlaczego trudno jest tworzyć systemy
informatyczne?

7. Trójkąt ograniczeń projektowychTrójkąt ograniczeń projektowych

8. Trójkąt ograniczeń projektowych - praktykaTrójkąt ograniczeń projektowych - praktyka

9. Sukces projektu zależy od modelu organizacyjnego
i od procesu, w jakim jest wytwarzane oprogramowanie,
czyli od sposobu prowadzenia projektu na poziomach:
strategicznym (cele biznesowe),
zarządczym (zarządzanie zasobami - w tym ludźmi),
wytwórczym (tworzenie produktów takich, jak
oprogramowanie, dokumentacja, testy etc.).
Sukces projektu informatycznegoSukces projektu informatycznego

10. Geneza zarządzania projektamiGeneza zarządzania projektami

11. Historia realizacji projektów jest stara jak świat i
dotyczy wszystkich obszarach ludzkiej aktywności, np.
budowy miast, sztuki prowadzenia wojen,
organizowania wielkich przyjęć itd.
Metody i metodyki: Dobre Praktyki realizacji projektów
podlegają przeglądowi i Formalizacji, a następnie są
ponownie testowane w Praktyce Biznesowej.
Przykłady metodyk zarządczych i wytwórczych:
PMBoK, TenStep, PRINCE2, RUP, Scrum,
Extreme Project Management.
Geneza zarządzania projektamiGeneza zarządzania projektami

12. Reasumując – prowadząc projekty (w tym
informatyczne) znajdujemy się często w sytuacji
bohatera sztuki „Mieszczanin szlachcicem” autorstwa
Moliera, który rzekł do swojego nauczyciela filozofii:
„U licha! już przeszło 40 lat mówię prozą, nic o tym
nie wiedząc.”
Istnieje jednak duża różnica pomiędzy prowadzeniem
a skutecznym prowadzeniem projektu.
Prowadzenie projektówProwadzenie projektów

13. Efektem skutecznego zarządzania jest korzyść biznesowa
dla wszystkich zainteresowanych wynikami (sukcesem)
projektu:
Sponsora – wykłada pieniądze na projekt,
Dostawcy/wykonawcy zleconych prac,
Użytkowników projektu:
Zamawiający – nadzorujący i odbierający prace,
Beneficjenci – korzystający z wyników
projektu.
Efektywne zarządzanie poprzez projektyEfektywne zarządzanie poprzez projekty

14. Warunkiem koniecznym (choć niewystarczającym)
osiągnięcia korzyści biznesowych jest:
w ramach projektu - wytworzenie niepowtarzalnych
produktów (gdzie usługa też jest produktem), np.
stworzenie systemu informatycznego.
w ramach procesów ciągłych/działań operacyjnych –
ujęte w procesy wytwarzanie powtarzalnych
produktów lub świadczenie usług w sposób ciągły,
np. utrzymanie SI obsługującego zapytania
z urządzeń mobilnych.
Efektywne zarządzanie poprzez projektyEfektywne zarządzanie poprzez projekty

15. Kocioł praktykiKocioł praktyki

16. Trywialne? Tak... ale trywialne rzeczy trzeba powtarzać.
Hurraoptymizm - wróg realizacji projektów!
Wstępna analiza przedprojektowa:
Identyfikacja potrzeby i grupy docelowej.
Sprawdzenie, jakie rozwiązanie inni znaleźli dla takiej
potrzeby.
Analiza, czy wybrane medium jest
odpowiednie dla potrzeby.
#1: Działalność biznesowa to chłodna
kalkulacja
#1: Działalność biznesowa to chłodna
kalkulacja

17. Zaślepienie hurraoptymiznem:
"W najgorszym wypadku zarobimy na tym kupę
kasy!"
- członek zarządu jednej z małych firm
internetowych.
Chłodna kalkulacjaChłodna kalkulacja

18. I więcej niż projekty + bieżąca działalność operacyjna.
#2: Działalność biznesowa to więcej niż
projekt
#2: Działalność biznesowa to więcej niż
projekt
Projekt
Wymagania Prototyp Produkt
Koncepcja Cele biznesowe

19. Tworząc biznesplan należy opisać wszystkie procesy –
nie tylko te realizowane internetowo/mobilnie.
Należy uwzględnić:
Naszą infrastrukturę, zasoby, przepływ towarów.
Preferencje użytkowników – w tym kontakt off-line.
Brak dostępności usługi? Business continuity: awaria
serwera, łącz, bazy towarów i klientów...
#3: Mój biznes nie będzie dostępny jedynie
on-line
#3: Mój biznes nie będzie dostępny jedynie
on-line

20. Czy rozumiemy nasze potrzeby? Zobaczmy, czy
spisane założenia są rozumiane w ten sam sposób
przez decydentów i pracowników zamawiającego.
Czy rozumiemy się, gdy wspólnie mówimy, że się
rozumiemy? Analiza zakresu zamówienia (zlecenia)
wraz z wykonawcą. Wspólne czytanie dokumentacji.
Czy w firmie mamy dobrych, niepodlegających
naciskom analityków biznesowych? Jeżeli nie, to sami
dobrze nie sformułujemy wymagań.
#4: Zrozumieć, aby zwyciężyć#4: Zrozumieć, aby zwyciężyć

21. Zrozumieć, aby zwyciężyćZrozumieć, aby zwyciężyć
Sprzeczne i uzupełniające się obszary potrzeb (wymagań)
Beneficjenci
(Użytkownicy)
Zamawiający
Sponsor
(Finansujący)
Wykonawca
Konkurencja
Zamawiającego
Podwykonawcy
Konkurencja
Wykonawcy

22. Jeżeli analizę zakresu zrobi za nas wykonawca (o ile
zrobi ją dobrze), to i tak przygotuje ją pod budowę,
wdrożenie i eksploatację swojego systemu - niezależnie,
czy to system „z półki”, czy na zamówienie.
Obszary prac:
Analiza i określenie wymagań.
Budowa systemu i nadzór nad budową.
Utrzymanie systemu, rozwój systemu
oraz wsparcie.
Zrozumieć, aby zwyciężyćZrozumieć, aby zwyciężyć

23. Ogólnikowe określenie swoich wymagań wymusza na
wykonawcy przyjęcie buforu nakładu pracy na
nieprzewidziane zadania, a zatem - podnosi koszty
zamawiającego.
A co nie zostanie zdefiniowane przez zamawiającego,
będzie „domyślone” przez wykonawcę (zwykle spadnie w
piramidzie delegacji na programistę wykonawcy)...
Zrozumieć, aby zwyciężyćZrozumieć, aby zwyciężyć

24. Jednak - nie ulegać pokusie doprecyzowania
wszystkiego od razu: jest to pracochłonne,
nieprecyzyjne i obarczone dużym błędem szacowania –
zatem praktycznie niemożliwe.
Rozwiązaniem: podział projektu na etapy.
Zrozumieć, aby zwyciężyćZrozumieć, aby zwyciężyć

25. Analiza przedprojektowa: studium wykonalności – od
strony ekonomicznej, prawnej, operacyjnej,
technicznej, czasowej, dostępności oferty rynkowej.
Analiza projektowa (w trakcie projektu): zbieranie
informacji w celu wykrywania zmian w celach
biznesowych i odchyleń projektowych. Zarządzanie
ryzykiem (budowa i monitoring rejestru ryzyk).
Analiza poprojektowa: ocena korzyści projektu,
rejestr doświadczeń do wykorzystania
w następnych projektach.
#5: Przed projektem, w trakcie i po projekcie
należy prowadzić analizy
#5: Przed projektem, w trakcie i po projekcie
należy prowadzić analizy

26. Zamawiający i Wykonawca są partnerami: jeden płaci, a
drugi dostarcza produkty, usługi, wiedzę...
Jeżeli wykonawca mówi, że wszystko da się zrobić, to
oznacza, że – umyślnie lub nie - robi zamawiającego
„w konia”. Dzieje się tak, ponieważ wykonawca:
(ma dobre intencje, lecz) nie ma wiedzy albo
ma wiedzę, lecz nie przekazuje informacji o
działaniach, które szkodzą zamawiającemu.
#6: Stwierdzenie „Klient nasz Pan” należy
wyrzucić do kosza!
#6: Stwierdzenie „Klient nasz Pan” należy
wyrzucić do kosza!

27. Uwaga: Zamawiający chce słyszeć, że wszystko da
się zrobić, ponieważ: (jak każdy)
nie lubi w biznesie kłopotów,
ma już własne zmartwienia osobiste,
ma zobowiązania wobec przełożonych, kontrahentów i
chce raportować, że wszystko idzie w dobrą stronę.
„Klient nasz Pan”„Klient nasz Pan”

28. Dlaczego nie wszystko się da zrobić? (w ustalonym
zakresie, przy ustalonej jakości, przy określonym
budżecie i w określonym czasie). Ponieważ:
Wykonawca nie ma dostępnych zasobów dla naszego
projektu. W ogóle nie ma takich zasobów albo ma je
przypisane do innych zadań.
Klasyczny przykład z wymaganiem osób dedykowanych
do projektu – zazwyczaj nie da się ich zarezerwować
jedynie do naszego projektu (bo byłoby to
nieracjonalne).
„Klient nasz Pan”„Klient nasz Pan”

29. Dlaczego nie wszystko się da zrobić? Ponieważ:
Wykonawca ma zobowiązania o wyższym priorytecie,
ale nie dzieli się nami tą wiedzą.
Last but not least: Zadanie jest do wykonania, ale
wykonawca nie rozumie naszego modelu biznesowego
i chce stworzyć coś, co błędnie rozumie jako
odpowiedź na nasze potrzeby.
„Klient nasz Pan”„Klient nasz Pan”

30. Dlaczego nie wszystko się da zrobić? Ponieważ:
Last but not least #2: Zadanie jest do wykonania,
wykonawca rozumie nasz model biznesowy, jednak
nie poinformuje nas, że produkt/usługa nie pozwolą
zrealizować (w sposób optymalny) naszych celów
biznesowych. A wykonawca chce zarobić ;-)
Z kuluarów: Przedstawiciele sektora IT do administracji
publicznej „Za etykę nam nie płacą.” :-D
„Klient nasz Pan”„Klient nasz Pan”

31. Musimy mieć plan projektu i plany składających się nań
etapów, aby wiedzieć, czy realizujemy przynajmniej to,
co zaplanowaliśmy.
Bez monitoringu postępu prac i wskaźników, które
mieliśmy osiągnąć nie wiemy, gdzie jesteśmy...
#7: Projekt należy dzielić na etapy#7: Projekt należy dzielić na etapy

32. Dzięki podziałowi na etapy jest możliwa:
Kontrola: Sprawdzamy, czy nasze cele biznesowe są
cały czas aktualne. Podsumowujemy to, czy udało się
nam zrealizować dotychczasowy plan projektu i plan
upływającego etapu – uzyskać zaplanowane produkty.
Planowanie: Przygotowujemy szczegółowy plan
następnego etapu uwzględniając: plan projektu,
wyniki poprzednich etapów, oraz monitorując, czy
nie zmieniły się cele i otoczenie biznesowe.
W zależności od zmieniającej się sytuacji
zmieniamy także plan całego projektu.
Projekt należy dzielić na etapyProjekt należy dzielić na etapy

33. Podział projektu na etapy jest ważny także ze względów
psychologicznych:
Każdy uczestnik projektu potrzebuje co pewien czas
(poczucia) sukcesu. A jeżeli nie sukcesu, to
przynajmniej wiedzy, jaki jest stan przedsięwzięcia,
w którym uczestniczy.
Projekt należy dzielić na etapyProjekt należy dzielić na etapy

34. Sponsor decyduje o uruchomieniu projektu i
zabezpiecza budżet na jego realizację.
Komitet Sterujący czuwa nad zasadnością realizacji
projektu (cele biznesowe) i okresowo rozlicza KP.
Kierownik Projektu (KP) powinien być traktowany jak
pracownik najemny (menadżer), podpisujący kontrakt
z KS na wytworzenie określonych produktów. KP ma
wolną rękę w zakresie przyjętej tolerancji
(czasu, budżetu, zakresu). Pracuje z Zespołem.
Realizację projektu nadzoruje bieżąco Audyt.
#8: Organizacja projektowa#8: Organizacja projektowa

35. Rola Kierownika Projektu jest kreatywna,
odpowiedzialna, niewdzięczna i bardzo stresująca.
Wobec KP pretensje mają Sponsor, Komitet Sterujący,
Zespół, Audyt i Wykonawca.
Istotne cechy KP:
"Do tego, żeby móc zarabiać na życie jako goniec
konny, mawiał zwykle Aplegatt wstępującym do
służby młodzikom, potrzebne są dwie rzeczy - złota
głowa i żelazna dupa". - Andrzej Sapkowski
"Czas pogardy", rozdział I.
Organizacja projektowaOrganizacja projektowa

36. Pułapka mikrozarządzania - gdy Sponsor albo Komitet
Sterujący stara się w sposób nieustanny kontrolować
projekt i sterować nim - zamiast Kierownika Projektu.
Nie ma innego wyjścia w projektach jak delegować
pracę – również w obszarze kreatywnym - i tworzyć
struktury odpowiedzialności.
Zarządzanie przez wyjątki: Zlecamy projekt, a
bieżące prace pozostawiamy Kierownikowi Projektu.
Ingerujemy wtedy, gdy uzyskamy informacje
(najlepiej – od KP albo od Audytu)
o istotnych odchyleniach od przyjętego planu.
#9: Zarządzanie przez wyjątki#9: Zarządzanie przez wyjątki

37. Zatem - należy ufać ludziom, ale...
O prezesie Comarch SA, prof. Januszu Filipiaku:
„Ogromną wagę przywiązuje do zaufania. Jak sam
mówi o sobie: zarządza poprzez delegację zaufania,
choć wiele razy zawiódł się na ludziach.”, Gazeta
Wyborcza, Mój Biznes, wtorek, 10.11.2009 r.
Zarządzanie przez wyjątkiZarządzanie przez wyjątki

38. Cykliczne wytwarzanie produktów o zwiększającej się
funkcjonalności bądź jakości, które posiadają wartość
biznesową dla zamawiającego - w celu
przeprowadzenia oceny/testu i uzyskania opinii, która
wpłynie na wytwarzany produkt.
Dotyczy każdego elementu systemu: procesów,
oprogramowania, prototypów interfejsu, projektu
graficznego, dokumentacji...
#10: Wytwarzanie iteracyjne#10: Wytwarzanie iteracyjne

39. Dokumentacja – nie wytwarzać na koniec projektu (po
powstaniu oprogramowania), lecz na bieżąco.
Na koniec projektu nie będzie na to czasu...
W modelu iteracyjnym mamy otrzymywać w
poszczególnych fazach działające komponenty
oprogramowania – realizujące konkretne
funkcjonalności, zatem – do nich musi być
dokumentacja.
Wytwarzanie iteracyjneWytwarzanie iteracyjne

40. I nie chodzi tylko o świętowanie zakończonych sukcesem
etapów. ;-)
Chociaż wszyscy to lubimy (i robimy), to nie
można stosować zasady równi pochyłej.
Zawsze monitorujemy potrzeby biznesowe (cel) -
jeżeli zanikły albo zmieniły się radykalnie, to
przerywamy projekt.
Nie wyrzucamy pieniędzy w błoto!
#11: Są takie dni, gdy projekt trzeba
przerwać
#11: Są takie dni, gdy projekt trzeba
przerwać

41. Nie jest łatwo przerwać projekt, ponieważ:
Nie chcemy przyznać się przed sobą (i innymi)
do błędu, że źle wyznaczyliśmy cel albo źle
zaplanowaliśmy realizację projektu.
Nie lubimy porażek – nawet, gdy zmienia się wokół
nas wiele, nie chcemy przerwać rozpoczętej pracy.
„Zbyt dużo zainwestowaliśmy, aby teraz nie kończyć!”
Mamy zobowiązania wobec innych, których nie
chcemy zawieść (bo oni mogą nas zawieść,
a nawet zawiesić).
Są takie dni, gdy projekt trzeba przerwaćSą takie dni, gdy projekt trzeba przerwać

42. Ze wspomnianych powodów energia idzie czasami w
stronę udowadniania, że cele projektu zostały osiągnięte.
Wykazuje się czasami, że stworzyło się produkt/usługę
w 100% zgodnie z założeniami projektu - pomijając
fakt, że nie osiągnięto celów biznesowych.
Tłumaczenie dopuszczalne w pewnych sytuacjach dla
Kierownika Projektu, ale nie dla Przewodniczącego
Komitetu Sterującego czy Sponsora.
Trudne rozwiązanie: Wskazać brak merytory-
cznego uzasadnienia dla kontynuacji projektu.
Są takie dni, gdy projekt trzeba przerwaćSą takie dni, gdy projekt trzeba przerwać

43. Dwie główne przyczyny - Sponsorzy, Kierownicy
Projektów lub wytwarzający produkty:
Nie znają zasad prowadzenia projektów.
Znają zasady, ale nie mają czasu lub nie mają
dodatkowych sił na ich stosowanie...
Zwyciężają korzyści krótkoterminowe.
Pokutuje fałszywe założenie intelektualizmu
etycznego: „Jeżeli człowiek wie, co dobre, to będzie
działał dobrze.”
#12: Niewiele osób stosuje przedstawione
zasady
#12: Niewiele osób stosuje przedstawione
zasady

44. Udział czynników wpływających na sukces projektu:
Wsparcie kierownictwa: 18%
Zaangażowanie klienta: 16%
Doświadczony Kierownik Projektu: 14%
Jasno określone cele biznesowe: 12%
Dokładnie określony zakres projektu: 10%
Pozostałe pięć (łącznie): 30% (w tym metodyka 5%)
Źródło: „Recipe for Success: CHAOS Ten” w raporcie
„CHAOS” 2005, Standish Group
Podsumowanie: Dlaczego projekty się nie
udają?
Podsumowanie: Dlaczego projekty się nie
udają?

45. „Źle zaplanowany projekt będzie trwał trzy razy dłużej,
niż oczekuje tego klient.
Dobrze zaplanowany projekty – tylko dwa razy
dłużej.” ;-)
Z notatek Kierownika ProjektuZ notatek Kierownika Projektu

46. Dziękuję za uwagę!
Michał Bukowski
http://www.goldenline.pl/michal-bukowski2