Encyklopedia Zarządzania :: Zarz��dzanie projektami informatycznymi dla praktyk��w
Przeglądanie katalogu (kliknij)
Przeglądaj katalog alfabetyczny według autorów, tytułów lub słów kluczowych. Kliknij odpowiedni przycisk poniżej, a następnie wybierz pierwszą literę nazwiska, tytułu czy słowa kluczowego.
(cytat, str. 19) W ramach zasobów własnych lub zewnętrznych (doradcy) wdraża się plan dostosowania organizacji do wymogów rzeczywistości projektowej: jawność kompetencji, giętkie zarządzanie zasobami osobowymi, budowanie systemów zarządzania organizacją projektową. Wdrożenie organizacji zorientowanej projektowo może trwać nawet kilka lat, jednak jest ot nieunikniony etap rozwoju firm w obecnej rzeczywistości ekonomicznej i silnej presji otoczenia konkurencyjnego.
(cytat, str. 20) Spoglądając na działania w projektach od strony procesowej, łatwo zauważymy, że schemat działań w typowych projektach jest zazwyczaj dość podobny i łatwo jest w nich wyróżnić zbliżone koncepcyjce fazy: - faza inicjacji (wybór koncepcji realizacji, określenie celu zakresu projektu itd.), - planowanie (tutaj już pojawiają się konkrety: zadania, ludzie sprzęt itp.), - wytwarzanie (trwa intensywna praca i następuje największa konsumpcja zasobów i generowanie kosztów), - zakończenie (zdajemy produkty projektowe, dopinamy zadania mniej ważne).
(cytat, str. 21) Firmy prowadzące projekty, okazjonalnie lub w ramach swojej głównej działalności w celu zwiększania bezpieczeństwa procesu i uczynienia go powtarzalnym stosują lub z czasem dopracowują się własnych metodologii projektowych. Pod tym pojęciem kryją się: - procedury postępowania, - standardy pracy, - formularze, - techniki używane w projektach.
(cytat, str. 23) Realizacja projektu zakończy się niepowodzeniem, gdy nie uda się w nim osiągnąć spodziewanych wartości w kluczowych czynnikach krytycznych, np.: - nie dotrzymamy terminu realizacji (ang. deadline), - projekt przekroczy planowany budżet, - jakość produktu będzie niska (dużo błędów lub niespełnienie oczekiwań użytkowników).
(cytat, str. 24) Project Management, według pierwotniej definicji Project Management Institute, jest to zastosowanie wiedzy, umiejętności, narzędzi i technik do aktywności projektowych, w celu zaspokojenia potrzeb tzw. udziałowców projektu. Udziałowcem w projekcie jest każdy, kto w nim uczestniczy lub ma z nim faktyczny kontakt - np. sponsor, zespół projektowy, klienci, użytkownicy, dostawcy oraz oponenci.
Słowa kluczowe:zarządzanie projektami Komentarze i źródła pierwotne: Źródło pierwotne: Project Management - Body of Knowladge, Project Management Institute
(cytat, str. 30) Karta projektu jest niejako dowodem osobistym projektu (lub nawet raczej: jego metryką urodzenia), opisuje jego kluczowe charakterystyki. Wieńczy ona mniej lub bardziej formalne działania mające na celu ustanowienie projektu w danej organizacji (firmie) i ma na celu ukonstytuowanie jego bytu.
(cytat, str. 34 - 35) Kierownik projektu powinien doprowadzić do oddzielenie warstwy zarządzania projektem (to jego domena) od bezpośrednie niego podejmowania strategicznych dla projektu decyzji. Tą sferą niech lepiej zarządza demokratycznie skonstruowanie ciało zwane komitetem sterującym.
Komitet sterujący jest złożony z reprezentantów kluczowych udziałowców projektu, np. dostawców, inwestorów podwykonawców, nie można także zapomnieć o użytkownikach końcowych produktu projektu. Zadaniem komitetu sterującego jest zatwierdzenie decyzji natury strategicznej: - zakres projektu, - startu projektu, - zmiany budżetu (np. udostępniania nowych zasobów), - modyfikacji lub zaprzestania realizacji projektu.
(cytat, str. 36) Zawartość planu projektu zależy od samego projektu, gdyż tak jak unikalny jest projekt, tak unikalny powinien być jego plan. Tym niemniej struktura planu projektu jest zazwyczaj dość podobna do siebie w wielu przypadkach i obejmuje takie informacje jak: - zakres prac - obejmujący to, co chcemy osiągnąć, - organizacja prac - role, podległości służbowe, procedury itd., - procedury (np. dotyczące współpracy z klientem, zarządzania zmianami), - szkolenia (wymagane do wykonania projektu), - harmonogram prac, - budżet - wynikający z użycia zasobów projektowych w czasie.
Jest zalecane, aby dokument planu projektu miał w miarę standardową strukturę (szablon) i był stale uaktualniany w trakcie życia projektu.
(cytat, str. 41) Celem procedur powinno być zapewnienie realizacji projektu w momencie, gdy nie steruje nim kierownik. Powinny one stanowić oparcie dla członków zespołu projektowego, a nie utrudnienie w ich pracy!
(cytat, str. 43) Harmonogram prac projektowych umieszczany w planie projektu nie powinien mieć charakteru szczegółowego (tj. nie powinien obejmować zadań). Jego celem jest pokazanie: - ram czasowych projektu, - kluczowych faz, - najważniejszych terminów projektowych, tzw. Kamieni milowych, - kluczowych zależności wewnętrznych (np. synchronizacji prac nad modułami systemu) i zewnętrznych (np. dat dostarczenia niezbędnych serwerów).
(cytat, str. 43) Jedną z przyczyn klęski może być niedopatrzenie kluczowego elementu infrastruktury projektowej. Przez ten termin rozumiemy zazwyczaj: - niezbędne środowiska sprzętowe do budowy produktów, - środowiska pomocnicze (testowe, integracyjne), - narzędzia programistyczne (np. kompilatory, biblioteki, CASE) i pomocnicze (np. do wersjonowania kodu źródłowego i dokumentów), - foldery współdzielone, - listy adresowe i(lub) telefoniczne numery kontaktowe, - przestrzeń projektową w firmowym Intranecie.
(cytat, str. 44) Pamiętajmy, ze plan projektu jest dokumentem roboczym i powinien stanowić podstawę pracy zespołu: - na spotkaniu inicjującym projektu omawiamy zawartość planu projektu, - w momencie, gdy w projekcie zachodzą zmiany dezaktualizujące zawartość planu projektu, aktualizujemy go, - zmieniony plan projektu publikujemy w dostępnym dla wszystkich zainteresowanych stron repozytorium dokumentów projektowych.
(cytat, str. 47) Budowa zgranego zespołu wymaga szeregu czynników, które powinny z mniejszą lub większą intensywnością stale występować: - należy ludziom stale tłumaczyć sens ich pracy i wzbudzać poczucie współuczestnictwa, - za sukcesy trzeba nagradzać, - za porażki ganić (ale raczej nie publicznie), - trzeba bronić swoich ludzi na zewnątrz przed wpływem polityki i zdarzeń rozpraszających, - należy stale badać, co motywuje członków zespołu i czy ich aktualne zadania pokrywają się z ich ambicjami zawodowymi, - wszelkimi dostępnymi metodami warto budzić poczucie identyfikacji z grupą, zaznaczać istnienie zespołu (projektu) jako struktury socjalnej, - w razie wystąpienia konfliktów należy starać się wypracować rozwiązania satysfakcjonujące dla obu stron (ang. win-win).
(parafraza, str. 50 - 51) Role (wzorce zachowań), które pełnią członkowie zespołów projektowych wg klasyfikacji dr. Belbina: myśliciel, koordynator, krytyk wartościujący, realizator, skrupulatny wykonawca, poszukiwacz źródeł, lokomotywa, dusza zespołu, specjalista.
Słowa kluczowe:wzorce, wzorce zachowań Komentarze i źródła pierwotne: Źródło pierwotne: Team roles at work, Meredith Belbin
(parafraza, str. 51 - 52) Klasyfikacja wzorców zachowań wg typologii MTR-iâ„¢: rzeźbiarz, trener, naukowiec, wynalazca, przewodnik, krzyżowiec, badacz, kustosz.
Słowa kluczowe:wzorce zachowań Komentarze i źródła pierwotne: Źródło pierwotne: www.mtr-i.com
(cytat, str. 57) Każdy człowiek, niezależnie od swojego typu osobowości, może odgrywać różne role zespołowe. Jest to spowodowane okolicznościami, zapotrzebowaniem pracodawcy, wymogami kulturowymi.
Do pewnych ról jesteśmy predysponowani i w nich odnajdziemy się idealnie, bez dyskomfortu psychicznego i poczucia niedopasowania, wpływającego na efektywność pracy.
(cytat, str. 63) W praktyce zasadniczym celem struktury WBS jest: - logiczne podzielenie skomplikowanej pracy na mniejsze prace łatwiejsze do zarządzania (kontrola wykonania), - podzielenie zadań na grupy ułatwiające zrozumienie celu projektu (komunikowanie zawartości projektu jego uczestnikom i udziałowcom), - kontrola kosztów.
(parafraza, str. 64 - 65) Przy tworzeniu WBS warto przyjąć zasady: - szczegółowe rozpisywanie zadań cząstkowych ma jedynie sens przypadku konieczności kontrolowania tych zadań, - delegujemy realizację skomplikowanych zadań na doświadczonych członków zespołu na zasadzie kontraktu, - w dużych projektach unikamy zbyt szczegółowego definiowania struktury podziału prac, - członkowie merytoryczni projektu powinni być zaangażowani w tworzenie WBS.
(cytat, str. 64) Prawidłowe podejście przy tworzeniu WBS polega na próbie zorganizowania prac projektowych według obszarów, które jesteśmy w stanie kontrolować i na których kontrolowaniu tak naprawdę nam zależy.