Update 2008.02.17

1) Przy okazji przygotowywania dla Państwa prezentacji o zarządzaniu ryzykiem wg PMBOK na stronie PMI WPC zauważyłem informację o planowanej konferencji, która może Państwa zaciekawić.

23-24 kwietnia 2008 w Krakowie będzie mieć miejsce konferencja PriorITy poświęcona zarządzaniem projektami informatycznymi. Więcej informacji znajdą Państwo na stronie priority.org.pl

2) Skoro już jesteśmy przy konferencjach: we wrześniu zeszłego roku miała miejsce konferencja Software Project Management.
Na jej stronie mogą Państwo znaleźć wygłoszone prezentacje (3 poniższe linki to PDFy).

Mnie osobiście zainteresowały dwie prezentacje p. Jacka Mamota z K2 Consulting:

• Zarządzanie ryzykiem w projektach IT
• Zarządzanie ryzykiem – psychologia strachu

Godne uwagi jest w nich m.in. odniesienie się do kwestii psychologii osób realizujących projekt, o czym nie mówi się zbyt często.

Tych z Państwa, którzy prosili o więcej informacji na temat mind-mappingu może zaciekawić prezentacja [Twórcze myślenie i Mind Mapper w zarządzaniu projektami] p. Mariusza Paszko z Brand-IT, który jest od wielu lat niezmordowanym orędownikiem tej tematyki.

3) Odnośnie PMBoKa
a) można kupić przez Amazon już od 35 USD + przesyłka.
b) na stronie skutecznyprojekt.pl jest sporo artykułów poświęconych opisowi treści tej publikacji – tak na wypadek, gdyby chcieli Państwo więcej poczytać przed zakupem.
c) Prezentacja odnośnie tego jak PRINCE2 i PMBOK mogą się dopełniać (PDF)

Update 2008.02.14

Co z nowości?

1) Wrzuciłem na stronę prezentację odnośnie wpływu regulacji ładu korporacyjnego na IT ze spotkania 3. Znajdą ją Państwo we wpisie dla spotkania 3.

2) Na stronie Software Developers Journal zauważyłem dział z artykułami archiwalnymi. Dostęp wymaga podania adresu mailowego na potrzeby newslettera.
[Strona ze spisem artykułów]
Wydaje mi się, że kilka z nich może Państwa zainteresować:
a) Dziesięć największych problemów w projektach informatycznych
Dosyć techniczne i istotne raczej dla większych projektów, ale ciekawe
b) Inżynieria oprogramowania: Wstęp do Scrum
c) Antywzorce projektowe – złego dobre początki
Interesujące z punktu widzenia zarządzania ryzykiem – co może zagrozić naszym projektom
d) Baza wiedzy w zarządzaniu projektem informatycznym
Praktyczne – jak można zorganizować wymianę wiedzy w organizacji. Zarządzanie ryzykiem bez uczenia się na błędach (i sukcesach) delikatnie mówiąc mija się z celem…

Wpisy

Jako, że kilka osób nie ma jeszcze wpisu chciałbym zaproponować termin i miejsce:
poniedziałek 11 lutego o 19:00 w Traffic Clubie (pierwsze piętro przy ruchomych schodach).

Jeśli komuś z Państwa to nie pasuje prosiłbym o maila – ustalimy coś alternatywnego.

Update 2008.02.03

Dodałem do wpisu dla spotkania 4 egzamin oraz prezentację przedegzaminową. Może się Państwu przyda?
Więcej o PMBOKu dopiszę w ramach kolejnego update’u – zapewne w okolicach kolejnej niedzieli.

Osoby bez wpisów proszę o kontakt.

Poniżej kilka linków, które mogą Państwa zainteresować:

1) W Computerworldzie jest ciekawy komentarz p. Chabika na temat “kultu opadających powiek” panującego wśród informatyków. Polega on na tym, że bardziej ceni się projekty zakończone dzięki szalonym nadgodzinom niż te, które dobrze zaplanowano i w rezultacie zakończono w terminie bez szaleństw.
Autor opisuje przykładowy case 2 zespołów: jednego, który wszystko zaplanował i spokojnie skończył oraz drugiego, który podarował sobie zarządzanie projektem i kodował po kowbojsku ratując się w końcówce dzięki pracy w nadgodzinach. Nagrodzony za ciężką pracę został zespół drugi…
Pytanie do pomyślenia: co będą robić ludzie widząc, że nagradza się wysiłek, a nie rezultaty?

2) Stare, ale interesujące – w harvardzkim serwisie “Working Knowledge” mogą Państwo znaleźć artykuł “Mission to Mars: It Really Is Rocket Science” na temat programu kosmicznego NASA. Zapewne Państwa projekty będą mniejsze i nieco tańsze, ale można poczytać o wpływie cięć budżetowych, transferze wiedzy między projektami i zarządzaniu projektami w warunkach znacznej niepewności.

Spotkanie 4

Egzamin

Prezentacja z ostatniego spotkania (część o PMBOKu dodam w kolejny weekend)

Tak, jak się umawialiśmy plan na nasze ostatnie spotkanie wygląda następująco:
1) Powtórzenie (30-40 minut; omówię wszystko, co się przyda na egzaminie)
2) Egzamin (dokładniej opisany post niżej)
3) Zamówienia z ewaluacji (w pierwszej kolejności omówienie ryzyka wg PMBOK)

Pytania (i powtórzenie) będą obejmować:
a) Ryzyko a kontekst projektu (powiązanie projektu ze strategią i oczekiwaniami stron)
b) Identyfikację ryzyk
c) Ocenę ryzyk
d) Postępowanie z ryzykiem (typy)
e) Plan zarządzania ryzykiem i dalsze kroki
f) Ryzyko związane z zespołem projektowym
g) Wybór metodyki zarządzania projektami
h) Harmonogramowanie
i) Wymagania i zakres
j) i nad tym się jeszcze zastanawiam ;)

Wiem o 2 osobach, które nie mogą być na egzaminie.
Jeśli komuś jeszcze coś wypadnie proszę o kontakt mailowy (zbigniew.misiak[at]gmail.com).

Tak w odpowiedzi na pytanie jednej osoby z grupy – strona jest robiona dla Państwa, więc zostaje również po zakończeniu kursu. Jeśli trafię na coś, co uznam za potencjalnie interesujące dla Państwa, to będę dorzucał nowe treści.

Spotkanie 3

Prezentacja – spotkanie 3

Ład korporacyjny i jego wpływ na IT – Michał Kossowski

---

Co będzie na spotkaniu 3?
Plany są takie:
* ITIL, COBIT oraz jaki wpływ na IT ma wdrażanie frameworków
[o poprowadzenie tej części dla Państwa poprosiłem swojego szefa. Michał spędza sporo czasu na projektach europejskich, więc myślę, że będzie mógł Państwu opowiedzieć sporo ciekawych rzeczy]
* Omówienie tego, co będzie na egzaminie
* Jeśli zostanie nam trochę czasu, to (w odpowiedzi na zamówienia z komentarzy) chciałbym poszerzyć to jak PMBOK podchodzi do ryzyka.

Na wypadek gdyby kogoś miało nie być info o egzaminie:
Tak, jak się umawialiśmy egzamin będzie na ostatnich zajęciach i będzie to w formie testu. Planuję 10 pytań i 20 minut czasu (tak więc zostanie nam czas na omówienie zagadnienia, które Państwo zamówią).
Pytania będą w formie krótkiego case’u z odpowiedziami typu tak/nie. W ramach przygotowania można przejrzeć prezentacje i materiały, które wrzuciłem dla Państwa na stronę, ale postaram się, aby zdrowy rozsądek wystarczył.

Przykładowe zadanie:
Razem z zespołem właśnie skończyliście szacowanie pracochłonności nowego projektu. Twój projekt ma już doświadczenia z projektami programistycznymi tego typu, więc w oparciu o dane z poprzednich projektów udało się ustalić, że na 90% skończycie w 8 miesięcy, a na 100% w 9 miesięcy. Wariant najbardziej optymistyczny to 7 miesięcy. Gdy zakomunikowałeś to swojemu szefowi wyraźnie sposępniał. “Hmmmm… Nie myślałem, że to zajmie aż tak długo i obiecałem klientowi, że będzie to za 3 miesiące. Mam pomysł – mamy sporo praktykantów z nowej rekrutacji. Jeśli dostaniesz 3 razy większy zespół to dasz radę?”.
Abstrahując od kwestii politycznych – czy mówisz:
(Tak) zgodzisz się na skrócenie terminu i przyjęcie praktykantów (nie znasz tych ludzi, ale wiesz, że znajomość potrzebnej do tego projektu technologii nie jest zbyt powszechna) w nadziei, że więcej osób pozwoli szybciej zakończyć projekt
(Nie) tłumaczysz, że większy zespół nie oznacza, że szybciej skończycie i proponujesz rozwiązanie, które pozwoli dostarczyć klientowi przynajmniej część potrzebych funkcjonalności w 3 miesiące, co pozwoli szefowi zachować twarz, Twojemu zespołowi oszczędzi niepotrzebnego stresu, a firmie na dłuższą metę utraty reputacji terminowych i solidnych dostawców.

Wesołych Świąt

Z okazji Świąt Bożego Narodzenia chciałem Państwu życzyć spokojnego i radosnego czasu spędzonego w towarzystwie bliskich.
A w Nowym Roku – wielu ciekawych projektów, w których ryzyko się nie będzie materializować.

Co nowego?

1) Czekam na Państwa uwagi/zamówienia w związku z kolejnym spotkaniem. Draft jest na początku wpisu “Spotkanie 2“

2) W ramach spełniania Państwa zamówień z ewaluacji zaczynam tworzyć strony tematyczne. Na razie są to: “Biblioteczka PMa” (tam będę zamieszczał namiary na przydatne książki), “PRINCE2 a ryzyko” (zaczątek obiecanego opracowania tematu) oraz “Rachunek sumienia PMa – harmonogram“. Ostatni wpis jest eksperymentem – z założenia ma służyć Państwu jako lista kontrolna w pracy zbierająca dobre praktyki z literatury oraz może być podstawą do testu na koniec. Czy taka forma Państwu odpowiada? Jeśli tak, to dodam kolejne tematy składające się na zarządzanie projektami i powiązane z ryzykiem.

Spotkanie 2

Prezentacja ze spotkania 2:
[PDF 312KB]

Plany na spotkanie 2 (2007.12.09)

Obiecany draft – o czym będzie na spotkaniu

* Podsumowanie spotkania 1
* Jakie są najczęstsze ryzyka projektów informarycznych i w jaki sposób tradycyjnie się do nich podchodzi
* Na jakich założeniach opierają się tradycyjne podejścia do zarządzania projektami

* Agile Manifesto – nowy pomysł na podejście do projektów, czyli co robić jeśli tradycyjne podejścia nie działają. Zasady Agile.
* Jak przy podejściu Agile radzić sobie z popularnymi ryzykami
* Odrobina praktyki – opis SCRUM

* Sposoby specyfikacji systemów, czyli jak ustalać czego Klient potrzebuje

Koniec draftu

Proszę o uwagi/zamówienia w komentarzach

Do poczytania:
Agile Manifesto – zbiór zasad na których opierają się lekkie metodyki. Godna uwagi jest też lektura listy autorów – widać tam ciekawy przegląd istniejących metodyk z tego nurtu.

Na stronie warszawskiego PMI można zapoznać się z prezentacją z seminarium “Tradycyjne zarządzanie projektami a podejście adaptacyjne i metody lekkie”.

Kolejna prezentacja ze strony infoshare: Bartosz Kiepuszewski “Agile Software Development Perspektywa Członka Zespołu” [PDF 1,11MB]. Doktor Kiepuszewski należy do Cutter Consortium – amerykańskiej firmy badawczej skupiającej światowej klasy ekspertów IT, która zajmuje się m.in. zarządzaniem projektami i ryzykiem.

Dla zainteresowanych SCRUM:
Scrum in five minutes [PDF 438KB] – bardzo przystępne wprowadzenie do metody

Oprogramowanie dla zespołów stosujących metody Agile:

ScrumWorks – wersja Basic tego komercyjnego programu jest dostępna za darmo
XPlanner – (Open Source) rozwiązanie wspierające zespoły korzystające z programowania ekstremalnego. Dostępne przez przeglądarkę.

Spotkanie 1

Dodatkowe materiały do spotkania 1 (2007.11.25)

Prezentacja – spotkanie 1 [PDF 428 KB]

Prezentacja – spotkanie 1 pełna wersja [PDF 572 KB]

Strony o PM:
4PM
PMI

Warto przeczytać:
Szablon ryzyk projektu
Ryzyko w projektach informatycznych (Andrzej Kiesz, Wirtualna Polska)
Risk Management for Software Projects (Tom DeMarco) [PDF 343KB]
Management of Risk – omówienie elementów zarządzania ryzykiem w PRINCE2 [PDF 816KB]

Programy dla PMa:
Project in a box – wersja community edition programu wspierającego zarządzanie w oparciu o PRINCE2
Product Based Planner

Sugestie tematów do rozszerzenia (przez dodatkowe materiały na stronie) oraz zagadnień do omówienia na kolejnych spotkaniach mile widziane – proszę o sugestie w komentarzach.

==================
Lista zmian

2007.11.26
1) Polecony przez uczestnika link (dziękuję) do strony streszczającej zalecenia z PMBOKa – w tym również te dotyczące zarządzania ryzykiem:
Link
2) Znaleziona prezentacja ludzi z Ernst & Young na temat zarządzania projektami – w tym ryzyka
PDF ze strony MIMUW (714KB)
3) Wspominałem Państwu na zajęciach o PMI – organizacji skupiającej praktyków zarządzania projektami. Na stronie oddziału warszawskiego można znaleźć ciekawe materiały i informacje o nadchodzących spotkaniach/konferencjach z zakresu zarządzania projektami.
Strona PMI WPC
4) W odpowiedzi na zamówienie z ewaluacji na więcej informacji o testowaniu: strona testerzy.pl zawiera m.in. ciekawe artykuły na temat testowania oprogramowania. Czy o coś takiego chodziło?
5) Nawiasem mówiąc strona Wikipedii zawiera dobry opis zarządzania ryzykiem wg. PMBOK: Link

2007.11.27
6) Dla zainteresowanych PRINCE2 i PMBOK – na stronie Akademii Ekonomicznej we Wrocławiu (link) można znaleźć ciekawe prezentacje do pogłębienia wiedzy. Jest też prezentacja omawiająca klasykę z zakresu projektowania systemów IT (“Marsz ku klęsce” Edwarda Yourdona). Moim zdaniem ciekawa lista powodów dla których projekty informatyczne się nie udają…

2007.11.29
7) Dwie kolejne prezentacje ze strony infoshare:
Jak usprawnić pracę w zespole IT? Wykorzystanie narzędzi do pracy grupowej na przykładzie zespołu Polska.pl, Agnieszka Kukałowicz. Omówienie narzędzi (groupware), które mogą się przydać zespołowi projektowemu. Może któreś z nich się Państwu przyda w pracy? Do tej tematyki wrócimy jeszcze na 2 spotkaniu przy okazji omawiania specyfikacji i zarządzania wymaganiami.

“Zarządzanie zespołem projektowym IT”, Danuta Żak. Omówienie kwestii zespołu ludzkiego w zarządzaniu projektami.

8) Jako podsumowanie poprzedniego spotkania i wstęp do następnego warto przeczytać zapis dyskusji z Teleinfo “Jak okiełznać projekt IT” [PDF 272 KB]. Praktycy IT dyskutują na temat znaczenia stosowania metodyki i podają dobre praktyki z zakresu zarządzania projektami.

==================

Zamówienia z ewaluacji:
- więcej na temat ryzyka w PRINCE2 oraz PMBOK
- ryzyko, a testowanie (dodany link do strony z materiałami 2007.11.26)
- więcej na temat oprogramowania, które prezentowałem
- praktyczne przykłady zarządzania ryzykami
- najczęstsze ryzyka i sposoby postępowania z nimi
- definiowanie ryzyk
- ITIL (będzie na 3 spotkaniu)
- PRINCE2
- lekkie metodyki i narzędzia wspomagające (będzie na 2 spotkaniu)
- jaśniejsze omówienie różnic w metodykach, przykłady
- jak rozmawiać z klientem po analizie ryzyka
Dobre pytanie. Jeśli dobrze rozumiem intencję – moim zdaniem ważne jest, aby rozmawiać w sposób partnerski w oparciu o zasadę win-win. Klient powinien wiedzieć, że chodzi o jego satysfakcję, ale że są rzeczy, których nie da się zrobić (“To jeszcze dwie drobne funkcyjki”) bez podejmowania decyzji co do priorytetów. W ramach dyskusji można ustalać jak będzie przebiegał projekt, co i w jakiej kolejności będzie realizowane. Natomiast ważne jest aby Klient zdawał sobie sprawę z istniejących ograniczeń technicznych i nie oczekiwał cudów (“Dwa miesiące-czemu tak długo? Nie da się szybciej?”).
- a gdzie ludzie ( – o tym będzie w znacznej mierze 2 spotkanie)
Tak w zasadzie to najciekawsza część zarządzania projektami odnosi się do ludzi. To ludzie zapewniają innowacyjność, ale też z ludźmi wiąże się mnóstwo ryzyk. Jako, że temat ludzi jest ważnym elementem ruchu Agile chciałbym o tym więcej opowiedzieć na 2 spotkaniu.
- ryzyko a intuicja, przeczucie i nos
Gdzieś wyczytałem, że de facto intuicja to nasz osobisty system ekspercki zasilany doświadczeniami zbieranymi przez lata. Intuicja jest ważna, gdyż pozwala na wyłapanie symptomów, które mogą być niepokojące (“Coś ostatnio moi główni developerzy siedzą posępni”). Natomiast warto sobie zdawać sprawę z ograniczeń intuicji (jest to ciekawie opisane m.in. przez DeMarco w “Zdążyć przed terminem”): w oparciu o intuicję ciężko jest robić analizy różnych wariantów postępowania i nie jest łatwo ustalać wartości liczbowe. Poza tym – wiedza cicha siedząca w naszej głowie może nam świetnie służyć, ale inni nie są w stanie z niej skorzystać i trudno jest dyskutować wyłącznie w oparciu o przeczucia. Cytując Deminga “In God we trust, all others bring data”.
- pamiętnik Tompkinsa (zapytam zapytałem wydawnictwo od “Zdążyć przed terminem” czy mogę zrobić dla Państwa handouty z książki)

Wszelkie dalsze uwagi/zamówienia/pomysły mile widziane – proszę dopisywać w komentarzach.