Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00530 008204 10498266 na godz. na dobę w sumie
Podstawy zarządzania projektami. Zdobywanie kwalifikacji pozwalających wyprzedzić konkurencję - książka
Podstawy zarządzania projektami. Zdobywanie kwalifikacji pozwalających wyprzedzić konkurencję - książka
Autor: Liczba stron: 200
Wydawca: Onepress Język publikacji: polski
ISBN: 83-7361-943-7 Data wydania:
Lektor:
Kategoria: ebooki >> poradniki >> zarządzanie projektami
Porównaj ceny (książka, ebook, audiobook).

Tak będą działać organizacje w następnych latach. A gdzie Ty wtedy będziesz: razem z nimi czy za nimi? Jeśli chcesz być z nimi, to przeczytaj tę książkę i opanuj podstawy zarządzania projektami -- dyscypliny o sprawnym prowadzeniu działań o kluczowym znaczeniu dla rozwoju organizacji. Jeśli chcesz przetrwać, naucz się pracować mądrzej i niekoniecznie ciężej -- naucz się dobrze zarządzać projektami.

Opanuj wszystkie najważniejsze czynności potrzebne w zarządzaniu projektem: od określania celów projektu do zarządzania zespołem projektowym, monitorowania prac projektowych i mierzenia rezultatów tych działań. Skorzystaj z wiedzy i doświadczenia autora -- uznanego eksperta w dziedzinie zarządzania projektami. Poznaj podstawowe narzędzia, które pomogą Ci zarządzać projektami: od oprogramowania do tworzenia harmonogramu projektu do narzędzi monitorowania i mierzenia odchyleń od przyjętego planu.

W tej książce znajdziesz praktyczną wiedzę podaną w przystępny i przejrzysty sposób, a także wiele ćwiczeń, które pomogą Ci tę wiedzę utrwalić i zastosować w Twojej organizacji. Dowiesz się:

Podstawy zarządzania projektami to niezastąpione, łatwe w wykorzystaniu źródło informacji o zarządzaniu projektami w każdej organizacji. Pomoże Ci podnieść efektywność i obniżyć koszty na każdym etapie prac.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Podstawy zarz¹dzania projektami. Zdobywanie kwalifikacji pozwalaj¹cych wyprzedziæ konkurencjê Autor: James P. Lewis T³umaczenie: Pawe³ D¹browski ISBN: 83-7361-943-7 Tytu³ orygina³u: Fundamentals of Project Management: Developing Core Competencies to Help Outperform the Competition Format: A5, stron: 200 Tak bêd¹ dzia³aæ organizacje w nastêpnych latach. A gdzie Ty wtedy bêdziesz: razem z nimi czy za nimi? Jeœli chcesz byæ z nimi, to przeczytaj tê ksi¹¿kê i opanuj podstawy zarz¹dzania projektami — dyscypliny o sprawnym prowadzeniu dzia³añ o kluczowym znaczeniu dla rozwoju organizacji. Jeœli chcesz przetrwaæ, naucz siê pracowaæ m¹drzej i niekoniecznie ciê¿ej — naucz siê dobrze zarz¹dzaæ projektami. Opanuj wszystkie najwa¿niejsze czynnoœci potrzebne w zarz¹dzaniu projektem: od okreœlania celów projektu do zarz¹dzania zespo³em projektowym, monitorowania prac projektowych i mierzenia rezultatów tych dzia³añ. Skorzystaj z wiedzy i doœwiadczenia autora — uznanego eksperta w dziedzinie zarz¹dzania projektami. Poznaj podstawowe narzêdzia, które pomog¹ Ci zarz¹dzaæ projektami: od oprogramowania do tworzenia harmonogramu projektu do narzêdzi monitorowania i mierzenia odchyleñ od przyjêtego planu. W tej ksi¹¿ce znajdziesz praktyczn¹ wiedzê podan¹ w przystêpny i przejrzysty sposób, a tak¿e wiele æwiczeñ, które pomog¹ Ci tê wiedzê utrwaliæ i zastosowaæ w Twojej organizacji. Dowiesz siê: (cid:129) jak unikaæ pu³apek czyhaj¹cych na niedoœwiadczonych kierowników projektów; (cid:129) co zrobiæ przed rozpoczêciem projektu: w³aœciwe okreœlenie problemu, przygotowanie u¿ytecznego planu i harmonogramu; (cid:129) jak wprowadzaæ do projektu zmiany w trakcie jego realizacji; (cid:129) jak zarz¹dzaæ zespo³em projektowym: od rekrutacji i przydzielania zadañ do kontrolowania prac zespo³u; (cid:129) jak korzystaæ z narzêdzi informatycznych: co robiæ i czego nie robiæ z oprogramowaniem do zarz¹dzania projektami; (cid:129) jak mierzyæ i oceniaæ efektywnoœæ i wydajnoœæ realizacji projektu; (cid:129) jak uzyskaæ certyfikat Project Management Professional (PMP®) oferowany przez Project Management Institute. Podstawy zarz¹dzania projektami to niezast¹pione, ³atwe w wykorzystaniu Ÿród³o informacji o zarz¹dzaniu projektami w ka¿dej organizacji. Pomo¿e Ci podnieœæ efektywnoœæ i obni¿yæ koszty na ka¿dym etapie prac. SPIS TREŚCI Informacja o autorze ......................................7 Przedmowa ....................................................9 Rozdział 1. Ogólnie o zarządzaniu projektami ..............13 Rozdział 2. Planowanie projektu ....................................37 Rozdział 3. Określanie misji, wizji i celów projektu .....53 Rozdział 4. Wykorzystanie struktury podziału pracy do planowania projektu .................................67 Rozdział 5. Harmonogramowanie prac w projekcie ......83 Rozdział 6. Tworzenie użytecznego harmonogramu ....99 Rozdział 7. Kontrola i ocena projektu ..........................123 Rozdział 8. Wykorzystanie analizy wartości wypracowanej w kontroli projektu ...........141 Rozdział 9. Kierowanie zespołem projektu ..................161 Rozdział 10. Sprawne zarządzanie projektami w naszej firmie ...........................................177 Dodatek A Odpowiedzi do ćwiczeń ............................185 Dodatek B Źródła i literatura uzupełniająca ..............189 Skorowidz ..................................................191 ROZDZIAŁ 1. Ogólnie o zarządzaniu projektami O czym właściwie będziemy tu mówić? Od czasu pierwszego wydania tej książki w 1995 roku, Project Management Institute (PMI®), organizacja zawodowa skupiająca osoby zajmujące się zarzą- dzaniem projektami, rozrosła się z kilku tysięcy do ponad 75 tysięcy członków. Tylko w roku 2000 jej „stan posiada- nia” zwiększył się o około 30 procent1. Organizacja zawodowa? Zajmująca się wyłącznie zarzą- dzaniem projektami? Czyż zarządzanie projektami nie jest po prostu jedną z odmian zarzą- dzania? I tak, i nie. Jest wprawdzie wiele podobieństw, ale też i wystarcza- jąco wiele różnic uzasadniających potraktowanie zarządzania projek- tami jako dziedzinę odrębną od ogólnie pojętego zarządzania. Po 1 Według najbardziej aktualnych danych (czerwiec 2005) PMI skupia ponad 170 tysięcy członków w ponad 150 krajach — przyp. tłum. Projekt to wielozadaniowe zlecenie, dla którego określa się wymagania dotyczące wydajności, kosztów, czasu i zakresu oraz które wykonuje się tylko jednorazowo. 14 Podstawy zarządzania projektami pierwsze, projekty podlegają w znacznie większym stopniu ograniczeniom czasowym aniżeli większość innych działań podejmowanych w ramach zarządzania. Po drugie, pracow- nicy przydzielani do projektów często nie są bezpośrednimi podwładnymi kierownika projektu, ale rozmaitych innych osób zajmujących stanowiska kierownicze. Na czym zatem polega zarządzanie projektami i — jeśli już o tym mowa — czym jest projekt? Zacznijmy od tego, że projekt to wielozadaniowe zlecenie, dla którego określa się wymagania dotyczące wydajności, kosztów, czasu i za- kresu oraz które wykonuje się tylko jednorazowo. Jeśli ma- my do czynienia z czymś powtarzalnym, nie jest to już projekt. Projekt powinien mieć sprecyzowany termin rozpo- częcia i zakończenia (czas), budżet (koszt), jasno określony zakres — czy też rozmiar — wykonywanych w nim prac oraz konkretne wymagania dotyczące wydajności. Napisałem „powinien”, ponieważ niewiele projektów spełnia tę pożąda- ną definicję. Przy okazji — wspo- mniane ograniczenia dotyczące projektu określać będziemy w tej książce mianem celów wydajno- ściowych2. Projekt to problem przeznaczony do rozwiązania. — J.M. Juran Dr J.M. Juran, autorytet w dziedzinie jakości, zdefiniował projekt jako problem przeznaczony do rozwiązania. Podo- ba mi się ta definicja, ponieważ przypomina mi, że każdy projekt podejmuje się po to, by rozwiązać jakiś problem, przed którym stanęła firma. Muszę jednak przestrzec, że pojęcie problemu wywołuje na ogół negatywne skojarzenia, 2 W oryginale autor określił je mianem PCTS targets (PCTS to skrót od Performance (wydajność), Cost (koszt), Time (czas) i Scope (zakres)). Odpowiada to stosowanemu w kontekście zarządzania projektami po- jęciu celów wydajnościowych — jednej z dwóch, obok celów ekono- miczno-finansowych, kategorii celów formułowanych dla projektów — przyp. tłum. Ogólnie o zarządzaniu projektami 15 podczas gdy projekty zajmują się zarówno problemami po- zytywnymi, jak i negatywnymi. Na przykład stworzenie no- wego wyrobu jest problemem o charakterze pozytywnym, a projekt rekultywacji ekosystemu ma rozwiązać problem negatywny. Niepowodzenia projektów Standish Group (www.standishgroup.com) stwierdziła, że za- ledwie 17 procent wszystkich projektów dotyczących opro- gramowania podejmowanych w Stanach Zjednoczonych osiąga założone cele wydajnościowe. Połowa projektów wy- magała zmiany celów wydajnościowych — co oznaczało, że zwykle opóźniała się ich realizacja, wydatki przerastały oczekiwania, a wymagania dotyczące wydajności trzeba było ograniczać. Pozostałe 33 procent projektów po prostu prze- rywano. W jednym z ostatnich lat w Stanach Zjednoczo- nych wydano łącznie na rozwój oprogramowania ponad 250 miliardów dolarów, co oznacza, że 80 miliardów uto- piono bezpowrotnie w projektach, które trzeba było prze- rwać. Największe zdumienie budzi jednak fakt, że 83 procent wszystkich projektów dotyczących oprogramowania boryka się z rozmaitymi kłopotami. Wspomniane badania Standish Group przeprowadzono w 1994 roku. Natomiast zamieszczona w magazynie Software Development z lutego 2001 reklama konferencji poświęconej rozwojowi oprogramowania informuje, że firmy amerykań- skie wydają rocznie około 140 miliardów dolarów na projek- ty, które się przerywa lub w których dochodzi do przekro- czenia budżetu. Jeśli ktoś pomyślał, że uwziąłem się na firmy tworzące oprogramowanie, spieszę poinformować, że podobne staty- styki dotyczą wielu różnych rodzajów projektów. Równie 16 Podstawy zarządzania projektami przygnębiające dane dotyczące niepowodzeń, marnotra- wienia środków i przerywania projektów odnoszą się na przykład do tworzenia nowych wyrobów. Specjaliści w tej dziedzinie szacują, że około 30 procent kosztów stworzenia nowego wyrobu stanowią przeróbki i poprawki. Oznacza to, że na każdych trzech inżynierów zaangażowanych w projek- cie jeden przeznacza cały swój czas pracy wyłącznie na po- prawianie tego, co pozostałych dwóch wcześniej popsuło. Jako przyczynę tych niepowodzeń konsekwentnie podaje się niedostateczne planowanie projektu. Starając się jak naj- szybciej wykonać wszystkie prace, ludzie zaczynają strze- lać na oślep i w rezultacie ponoszą znacznie wyższe koszty, niż trzeba, poprawiając błędy, wycofując się ze ślepych uliczek itd. Często zadaje mi się pytanie, jak uzasadnić wyższemu kierownictwu korzyści wynikające z formalnych metod za- rządzania projektami i zawsze wówczas podaję te statysty- ki. Osoby zarządzające firmami chciałyby jednak wiedzieć, czy porządne zarządzanie projektami faktycznie zmniejsza liczbę niepowodzeń i poprawek. Można wówczas tylko od- powiedzieć, że każdy musi to sprawdzić i przekonać się na własnej skórze. Wszak jeśli udaje się ograniczyć liczbę po- prawek do poziomu ledwie kilku procent prowadząc pro- jekty metodami intuicyjnymi, to pozostaje tylko pogratulo- wać! Tyle, że nie bardzo wierzę, żeby było to możliwe. Warto by zastanowić się, do jakiego stopnia przydatne są tradycyjnie pojmowane metody kierowania. Czy gdyby wy- słać wszystkich kierowników w firmie na kilka miesięcy urlopu, jej wyniki pozostałyby na niezmienionym poziomie, czy też pogorszyłyby się? Spadek wydajności mógłby istot- nie potwierdzać, że kierownictwo spełnia jakąś pozytywną rolę, jednak gdyby wyniki się poprawiły, to należałoby są- dzić, że raczej przeszkadza, niż pomaga. Nie sądzę, by więk- szość zarządzających była skłonna przyznać, że ich działania Ogólnie o zarządzaniu projektami 17 nie mają większego znaczenia. Jednakże wszyscy wiemy, że są wśród nich zarówno osoby skuteczne, jak i nieskutecz- ne, i że dotyczy to również kierowników projektu. Zarządzanie projektami ułatwia planowanie, harmonogramowanie i kontrolę wszystkich działań, które trzeba wykonać, aby osiągnąć cele projektu. Na czym polega zarządzanie projektami? Zarządzanie projektami ułatwia planowanie, harmonogramowanie i kontrolę wszystkich działań, które trzeba wykonać, aby osiągnąć cele projektu. Są wśród nich również wspomniane wcześniej cele wy- dajnościowe. Warto zauważyć, że mówimy o ułatwianiu planowania. Jednym z błędów popełnianych często przez niedoświad- czonych kierowników projektu jest samodzielne wykony- wanie wszystkich działań związanych z planowaniem pro- jektu. Jednakże powstający w ten sposób plan nie tylko nie zyskuje wsparcia zespołu, ale pełen jest rozmaitych niedo- statków. Kierownik projektu nie jest w stanie uwzględnić wszystkich okoliczności, co sprawia, że szacunki czasu trwa- nia zadań są niepoprawne i cały plan zaczyna się rozcho- dzić w szwach, gdy tylko zacznie się jego realizację. Dlatego pierwsza zasada zarządzania projektami nakazuje zaangażo- wanie do planowania ludzi, którzy muszą później wykonywać daną pracę. Pierwsza zasada zarządzania projektami nakazuje, by ludzie, którzy muszą wykonywać daną pracę, pomagali w jej planowaniu. Kierownik projektu ma umoż- liwiać działanie innym. Jego praca polega na pomaganiu członkom zespołu w skutecznym wykony- waniu zadań, przejmowaniu na siebie niekorzystnego wpły- wu czynników zewnętrznych, zdobywaniu deficytowych 18 Podstawy zarządzania projektami zasobów potrzebnych im do pracy i oddzieleniu ich od ze- wnętrznych sił, które mogą zaburzyć ich pracę. Kierownik projektu nie jest władcą projektu. Powinien być — nade wszystko — liderem, w pełnym tego słowa znaczeniu. Najlepszą definicję przywództwa, jaką znam, sformuło- wał w 1962 roku Vance Packard. Stwierdził on, że „przy- wództwo jest sztuką sprawiania, by inni chcieli zrobić coś, co w naszym przekonaniu trzeba zrobić”. Kluczowym ele- mentem tej definicji jest chęć. Dyktatorzy zmuszają innych do robienia rzeczy, które to oni chcą robić. Podobnie po- stępują strażnicy pilnujący pracujących grup więźniów. Na- tomiast lider sprawia, że ludzie sami chcą wykonać jakąś pracę, a to jest zasadnicza różnica. Planowanie, harmonogramowanie i kontrola działań skła- dają się na kierowniczy czy też administracyjny aspekt pra- cy. Jeśli jednak brakuje przywództwa, projekty zazwyczaj spełniają zaledwie minimalne wymagania. Dopiero przy- wództwo pozwala wznieść się ponad te minimalne poziomy. Nie tylko harmonogramowanie Panuje dość powszechne — i błęd- ne zarazem — przekonanie, że zarządzanie projektami ogranicza się wyłącznie do harmonogramo- wania. Według ostatnich danych Microsoft sprzedał łącznie po- nad milion egzemplarzy programu Microsoft Project, a mimo to wskaźnik nieudanych projek- tów pozostaje wysoki. Harmonogram to z pewnością jedno z podstawowych narzędzi zarządzania projektami, ale nie jest ono bynajmniej ważniejsze aniżeli konieczność wypra- cowania wspólnego rozumienia tego, co chcemy osiągnąć w projekcie, czy też skonstruowania dobrej struktury po- działu pracy określającej wszystkie prace, które trzeba wy- konać (strukturę podziału pracy omówimy później). W istocie Przywództwo jest sztuką sprawiania, by inni chcieli zrobić coś, co w naszym przekonaniu trzeba zrobić. — Vance Packard. Ogólnie o zarządzaniu projektami 19 bez dobrego zarządzania projektami, szczegółowy harmono- gram pomoże nam chyba tylko w dokładnym udokumento- waniu naszych niepowodzeń. Pozwolę sobie tu na małą dygresję dotyczącą oprogra- mowania wspomagającego harmonogramowanie. Nie ma większego znaczenia, jaki pakiet wybierzemy, ponieważ każdy ma swoje mocne i słabe strony. Można jednak zaob- serwować skłonność do tego, by zapewniać ludziom opro- gramowanie i oczekiwać od nich, że nauczą się z niego ko- rzystać bez żadnego formalnego przeszkolenia. Tyle, że takie podejście po prostu nie jest skuteczne. Programy te mają bowiem tak rozmaite możliwości, że większość ludzi nie jest w stanie samodzielnie zgłębić ich tajników. Brakuje im cza- su, bo starają się wypełniać swoje regularne obowiązki, a nie każdy potrafi narzucić sobie odpowiedni rytm uczenia się. Nie zatrudnilibyśmy niedoświadczonego pracownika do ob- sługi skomplikowanego urządzenia w fabryce, nie zapew- niając mu uprzednio odpowiedniego przeszkolenia, ponie- waż obawialibyśmy się, że mógłby coś zniszczyć albo zrobić sobie krzywdę. Dlaczego nie zachować podobnej ostrożno- ści, jeśli chodzi o oprogramowanie? Projekty jednoosobowe Kiedy z prowadzeniem projektu nie jest związane zarządza- nie projektami? Jeśli w projekt zaangażowana jest tylko jed- na osoba. Wiele ludzi przysyła się na moje seminaria, aby nauczyli się, jak zarządzać projektami, pomimo że są jedynymi oso- bami pracującymi w swych projektach. To prawda, że pracę jednej osoby można nazwać projektem, jeśli ma ona spre- cyzowany termin rozpoczęcia, docelową datę zakończenia, konkretne wymagania dotyczące wydajności, określony za- kres prac i budżet. Jeżeli jednak w projekcie nie pracuje nikt inny (w tym również zewnętrzni dostawcy), konstruowanie 20 Podstawy zarządzania projektami harmonogramu ścieżki krytycznej mija się z celem. Jest to bowiem taki harmonogram, w którym występuje kilka rów- noległych ścieżek, a jedna z nich jest dłuższa niż pozostałe i w związku z tym wyznacza czas trwania całego zlecenia i pozwala — koniec końców — stwierdzić, czy można za- kończyć projekt przed ustalonym terminem. W sytuacji, gdy zleceniem zajmuje się jedna osoba, nie możemy planować kilku równoległych ścieżek — nie można się przecież rozdwoić. Projekty jednoosobowe wymagają dobrej samokontroli lub dobrej organizacji czasu, ale do tego wystarczy nam upo- rządkowanie zadań w postaci listy kolejnych czynności. Do- póki jednak nie koordynuje się działań innych osób, dopó- ty nie praktykuje się prawdziwego zarządzania projektami. Wielka pułapka — pracujący kierownicy projektu Często się zdarza, że od osób mających pełnić funkcję kie- rownika projektu wymaga się, aby wykonywali część fak- tycznych prac w projekcie. To pewna recepta na problemy. Jeśli mamy do czynienia z prawdziwym zespołem składa- jącym się z kilku osób, kierownik projektu nieuchronnie stanie przed dylematem, czy kierować tym zespołem, czy też zająć się swoją częścią prac. Naturalnie bardziej priory- tetowe okazują się prace, w przeciwnym razie można nie dotrzymać terminów, i to na nie decyduje się kierownik pro- jektu. Siłą rzeczy jednak zaniedbuje kierowanie zespołem, mając nadzieję, że zespół da sobie jakoś radę sam, ale nie- stety to tylko złudzenia. W końcu gdyby zespół mógł sobie radzić sam, od początku zrezygnowanoby z kierownika pro- jektu (pamiętamy nasze rozważania o znaczeniu zarządza- nia projektami). Niestety, kiedy przychodzi do oceny wyników kierow- nika projektu, słyszy on, że powinien poprawić swoje umie- jętności kierownicze. A najczęściej wystarczy po prostu nie Ogólnie o zarządzaniu projektami 21 przeszkadzać mu w zajęciu się przede wszystkim kiero- waniem. Kierownik projektu może wykonywać pewne prace, jeśli ma do czynienia z bardzo małym zespołem — takim, który składa się z nie więcej niż trzech, czterech osób. Ale jeśli zespół jest większy, zajmowanie się pracą i kierowaniem jednocześnie staje się niemożliwe, ponieważ rozmaite po- trzeby naszych członków zespołu będą nas stale od tej pracy odrywać. Jedną z przyczyn takiej sytuacji jest to, że zarządzający organizacjami nie zdają sobie w pełni sprawy z tego, na czym polega zarządzanie projektami — wydaje im się, że można pogodzić prowadzenie projektu z innymi pracami. W rezul- tacie prawie każdy w firmie stara się zarządzać projektami. I jak to w każdej dziedzinie bywa, okazuje się, że niektó- rym się to udaje, a inni nie mają do tego żadnych predys- pozycji. Przekonałem się, że znacznie skuteczniejszym po- dejściem jest wybór kilku osób, którym nie brakuje ani predyspozycji, ani chęci do tego, by zostać kierownikami projektu, i powierzenie im kilku niedużych projektów. W ten sposób umożliwia się ludziom zajmującym się pracami tech- nicznymi (w szerokim rozumienia tego słowa) skupienie się tylko na tych pracach i niezaprzątanie sobie głowy kwe- stiami administracyjnymi. Z drugiej strony zaś kierownicy projektu mają więcej okazji do doskonalenia swoich umie- jętności zawodowych. Sposoby wyboru odpowiednich ludzi na stanowiska kie- rowników projektu wykraczają poza zakres tej książki, ale zachęcam do lektury książki The World-Class Project Mana- ger (Wysocki i Lewis, 2001), gdzie zajmujemy się tymi za- gadnieniami. 22 Podstawy zarządzania projektami Nie można mieć wszystkiego naraz Jedną z najczęstszych przyczyn niepowodzeń w projektach jest to, że sponsorzy projektu wymagają od kierownika pro- jektu zrealizowania danego zakresu (czyli rozmiaru prac) w wyznaczonym terminie, w ramach konkretnego budżetu i przy zachowaniu określonego poziomu wydajności. Inny- mi słowy, sponsor narzuca wszystkie cztery ograniczenia projektu, co w praktyce się nigdy nie sprawdza. Relację pomiędzy poszczególnymi celami wydajnościo- wymi można zapisać w następujący sposób: K= f(W, C, Z) Słownie można by tę zależność wyrazić tak: „koszt jest uzależniony od wydajności, czasu i zakresu”, a graficznie przedstawia ją trójkąt, którego bokami są W, K i C, zaś pole wewnątrz trójkąta to Z. Przedstawia to rysunek 1.1. Rysunek 1.1. Trójkąty przedstawiające relację między wydajnością (W), kosztem (K), czasem (C) oraz zakresem (Z) Z reguł geometrii wiemy, że jeśli mamy dane długości boków trójkąta, to możemy obliczyć jego pole, zaś znajo- mość pola i dwóch z jego boków pozwala nam obliczyć długość trzeciego boku. Pozwala to sformułować bardzo praktyczną zasadę zarządzania projektami — sponsor może narzucać wartości dowolnych trzech zmiennych, ale musi pozostawić kierownikowi projektu możliwość samodzielne- go określenia czwartej z nich. Ogólnie o zarządzaniu projektami 23 Jeśli zatem sponsor określi nam oczekiwaną wydajność, terminy i zakres projektu, wówczas kierownik projektu musi określić, jaki będzie koszt związany z osiągnięciem tych rezultatów. Zawsze tylko przestrzegam kierowników pro- jektu, żeby zadbali o obecność kogoś, kto potrafi udzielać pierwszej pomocy, w chwili, gdy będą informowali spon- sora o tych kosztach. Ten bowiem, kiedy dowie się o pozio- mie szacowanych przez nas kosztów, dostanie prawdopo- dobnie zawału i ktoś będzie go musiał reanimować. Nie ma najmniejszych wątpliwości, że pierwszą reakcją sponsora będzie zdumienie. Ma on określone oczekiwania dotyczące poziomu kosztów i nasze szacunki zawsze ten poziom przekraczają. Czasem wyrwie mu się: „przy takich kosztach, nie da się uzasadnić podjęcia tych prac”. W rzeczy samej! Właśnie taką decyzję powinien podjąć, ale będzie się raczej starał przekonać potencjalnego kierownika projektu do próby realizacji projektu przy niższym budżecie. A ten, zgadzając się na takie rozwiązanie, naraża tylko siebie — i sponsora —na wielką klapę. Kierownik projektu ma obowiązek podania sponsorowi racjonalnego szacunku kosztów pozwalającego mu podjąć słuszną decyzję o tym, czy projekt powinno się realizować. Jeśli kierownik projektu ulegnie presji sponsora i zgodzi się na zaniżenie budżetu, nieszczęście jest pewne, więc — do- prawdy — lepiej dostać cięgi teraz, niż stracić życie później. Naturalnie istnieje pewna alternatywa. Jeśli sponsor stwierdzi, że stać go na ponie- sienie tylko części oszacowanych przez nas kosztów, możemy za- sugerować zmniejszenie zakresu projektu, co jest jak najbardziej dopuszczalne, pod warunkiem, że nadal otrzymamy funkcjonalny produkt. W przeciwnym razie roz- tropność nakazywałaby rezygnację Istnieje większe prawdopodobieństwo, że zupełnie przypadkowo sprawy potoczą się nie po naszej myśli, niż że równie przypadkowo stanie się coś dla nas korzystnego. 24 Podstawy zarządzania projektami z projektu i zajęcie się czymś innym, co może przynieść firmie zysk. Jak mówią — istnieje większe prawdopodo- bieństwo, że zupełnie przypadkowo sprawy potoczą się nie po naszej myśli, niż że równie przypadkowo stanie się coś dla nas korzystnego. W wypadku kosztów oznacza to, że prawdopodobieństwo przekroczenia budżetu jest więk- sze niż szans, że uda się zakończyć projekt poniżej budże- tu. To zresztą nic innego, jak tylko kolejna postać prawa Murphy’ego, według którego to, co może się nie udać, na pewno się nie uda. Etapy projektu Istnieją najrozmaitsze modele określające układ etapów pro- jektu w ramach jego cyklu życia. Jeden z nich oddaje spe- cyfikę źle zarządzanych projektów — jakże często występu- jących wokół nas (rysunek 1.2). Rysunek 1.2. Cykl życia źle zarządzanego projektu Ogólnie o zarządzaniu projektami 25 Pokazywałem ten diagram ludziom na całym świecie. Z rozbawieniem przyznawali, że właśnie tak to wygląda na- prawdę. Jak sądzę, mogę więc pocieszać się, że my, Ame- rykanie, nie jesteśmy jedynymi, którzy muszą zmagać się z tym problemem. Smutne tylko, że skoro wszyscy rozpo- znają ten model, to musi być bardzo wiele takich źle za- rządzanych projektów. Model cyklu życia prawidłowo realizowanego projektu pokazuje rysunek 1.3. Warto zauważyć, że każdy projekt roz- poczyna się od etapu koncepcyjnego i że przed rozpoczę- ciem realizacji zespół projektu musi formalnie doprecyzować zlecenie. Niestety, skłonność do podejmowania nieprzemy- ślanych działań jest silniejsza i często zaczynamy pracę w danym zleceniu, nie zadbawszy uprzednio o prawidłowe jej doprecyzowanie ani nie upewniwszy się, że wszystkich łączy wspólna misja i wizja sformułowana dla tego zlecenia. Rysunek 1.3. Cykl życia prawidłowo realizowanego projektu Etap doprecyzowania Kilka lat temu zadzwonił do mnie pewien kierownik pro- jektu z firmy należącej do grona moich klientów i stwier- dził, że właśnie zakończył telekonferencję z najważniejszymi 26 Podstawy zarządzania projektami członkami swojego zespołu, w czasie której zdał sobie spra- wę, że jego ludzie mają odmienne spojrzenie na to, co ma być osiągnięte w projekcie. Zapewniłem go, że to powszechne zjawisko, a kiedy spy- tał, co powinien zrobić, odparłem, że jedynym rozwiąza- niem tego problemu jest nastawienie wszystkich członków zespołu na realizację tego samego celu przez wyjaśnienie im misji projektu. Wówczas poprosił mnie o poprowadzenie spotkania, które miało temu służyć. Na spotkaniu stanąłem obok tablicy i zaproponowałem wspólne sformułowanie i za- pisanie deklaracji problemu. Ktoś natychmiast zaoponował stwierdzając, że to niepotrzebne, bo i tak wszyscy wiedzą, na czym polega problem. Niezrażony stwierdziłem, że jeśli to prawda, to zapisanie deklaracji problemu będzie zwykłą formalnością, która za- bierze ledwie kilka minut, a mnie bardzo pomoże w dalszym prowadzeniu spotkania. I nie czekając na odzew poprosiłem, by ktoś pomógł mi zacząć. To, co się wydarzyło później, może zabrzmieć jak żart — ktoś powiedział „to…”, ale nim zdążyłem zapisać to sło- wo na tablicy, ktoś inny zawołał „Nie zgadzam się z tym!”. Formułowanie deklaracji problemu zabrało nam trzy godziny. Kierownik projektu miał rację. Jego ludzi znacznie bar- dziej dzieliły różnice w rozumieniu samego problemu niż sposobu jego rozwiązania. Rozbieżność jakże zasadnicza i tak często występująca, że zaczynam wierzyć, iż wszyscy je- steśmy wyposażeni w jakiś wadliwy gen, który nie pozwala nam skupić się na porządnym doprecyzowaniu problemu, zanim zaczniemy szukać sposobu jego rozwiązania. Pamię- tajmy, że zarządzanie projektami to rozwiązywanie proble- mów o wielkiej skali, a postać, do jakiej doprecyzujemy pro- blem, wyznaczy metody, za pomocą których będziemy go Ogólnie o zarządzaniu projektami 27 rozwiązywać. Jeśli ta postać będzie nieprawdziwa, może- my — owszem — znaleźć prawidłowe rozwiązanie, ale dla niewłaściwego problemu. Przekonałem się, że niepowodzenia projektów rzadko wiążą się z ich zakończeniem, a częściej z etapem doprecy- zowania. Nazywam takie projekty bezgłowymi kurczakami, ponieważ przypominają kurczaka, któremu obcięto głowę, a który biega wokół brocząc krwią, zanim w końcu padnie i „oficjalnie” zakończy swój żywot. To samo dzieje się w projektach, które krwawią na lewo i prawo, zanim ktoś w końcu stwierdzi formalnie, że projekt jest martwy. I rze- czywiście — jest martwy, tyle że był taki już na początku, kiedy obcięto mu głowę — trochę tylko trwało, zanim wszy- scy to zauważyli. Kiedy projekt jest już doprecyzowany, można zaplanować, jak wykonamy prace. Planowanie składa się z trzech elemen- tów: strategii, taktyk i logistyki. Strategia to ogólne podejście, czyli „plan gry”, który będzie przestrzegany, aby wykonać pracę. Przykład strategii podał mi mój przyjaciel, który jest historykiem wojskowym. Strategia W czasie drugiej wojny światowej podwykonawców w bran- ży obronnej poddawano silnej presji, oczekując od nich możliwie najszybszej i najbardziej intensywnej produkcji uzbrojenia. Szczególnie wytwórcy okrętów i samolotów pró- bowali stosować rozmaite nowe metody montażu mające przyspieszyć proces produkcji. Stocznie Avondale na przy- kład dążyły do usprawnienia technik budowy okrętów wo- jennych. Do tej pory okręty budowano zawsze ustawiając je w normalnej pozycji — stępka na dole, pokład na górze. W okrętach konstruowanych z elementów stalowych trze- ba było jednak zespawać ze sobą poszczególne części stęp- ki, co było dość utrudnione przy takim ustawieniu okrętu. 28 Podstawy zarządzania projektami Chcą ułatwić proces spawania, stocznie Avondale postano- wiły budować okręty „do góry nogami” i odwracać je do wła- ściwej pozycji dopiero kiedy trzeba było wykonać elementy konstrukcyjne znajdujące się ponad górnym pokładem. Stra- tegia ta okazała się na tyle skuteczna, że pozwoliła kon- struować okręty szybciej, taniej i w lepszej jakości niż kon- kurenci. Stosuje się ją zresztą do dziś, mimo że minęło już ponad sześćdziesiąt lat. Planowanie realizacji Ten etap obejmuje taktykę i logistykę. Jeśli zamierzamy bu- dować okręty do góry nogami, musimy to szczegółowo za- planować. Trzeba zaprojektować i skonstruować instalację pozwalającą utrzymać i obrócić okręt, nie uszkadzając go przy tym. Etap ten nazywa się wypracowaniem taktyk i obejmuje również określenie kolejności, w jakiej będzie się wykonywać prace, kto je będzie wykonywać i jak długo potrwa każdy krok. Logistyka dotyczy upewnienia się, że zespół ma materiały i inne artykuły potrzebne do danego zlecenia. Zazwyczaj pamiętamy o zapewnieniu zespołowi potrzebnych surow- ców, ale na przykład, jeśli projekt prowadzi się w miejscu, w którym nie można zdobyć żywności, prace szybko utkną w martwym punkcie. Trzeba zatem zapewnić zespołowi wy- żywienie, a być może również zakwaterowanie. Realizacja i kontrola Po opracowaniu i zatwierdzeniu planu zespół może rozpo- cząć pracę, czyli etap realizacji. Etap ten obejmuje również kontrolę — kiedy realizuje się jakiś plan, ktoś musi pilno- wać, żeby od tego planu nie odejść. Jeśli występują odchy- lenia od planu, trzeba podjąć działania korygujące, które przywrócą projekt na właściwe tory. Jeśli nie jest to możliwe, Ogólnie o zarządzaniu projektami 29 plan trzeba zmienić i w nowej postaci zatwierdzić. Skory- gowany plan staje się wówczas nowym planem bazowym, względem którego monitoruje się wykonanie projektu. Zakończenie Jednym z elementów zamknięcia projektu, przeprowadza- nego po zakończeniu wszystkich prac, jest przegląd projek- tu. Ma on na celu zestawienie zgromadzonego w projekcie doświadczenia, które będzie można później wykorzystać w przyszłych projektach. Zadaje się w tym kontekście dwa pytania — co zrobiliśmy dobrze i co chcielibyśmy poprawić następnym razem. Warto zauważyć, że nie pytamy o to, co poszło źle. Tak postawione pytanie mogłoby bowiem zniechęcić ludzi do ujawniania faktów, które mogłyby doprowadzić do tego, że zostaną ukarani. W istocie, przeglądu zgromadzonego do- świadczenia nigdy nie powinno się prowadzić w trybie prze- słuchania śledczego. Co innego, gdy chcemy zorganizować dochodzenie, w ramach którego chodzi zwykle o ustalenie, kto odpowiada za poważną katastrofę, i ukaranie go. Przegląd zgromadzonego doświadczenia ma przede wszystkim uczyć. W ostatnich kilku latach przekonałem się, że bardzo nie- wiele organizacji przeprowadza regularny przegląd zgroma- dzonego doświadczenia w swoich projektach. Panuje nie- chęć do otwierania tej „puszki Pandory” oraz dążenie do jak najszybszego zajęcia się następnym zadaniem. Kłopot w tym, że w ten sposób możemy być niemal pewni powtórzenia błędów popełnionych w poprzednich projektach, bowiem albo sobie ich nie uświadamiamy, albo nie rozumiemy, jak je popełniliśmy, co być może pomogłoby nam uniknąć ich w przyszłości. Co gorsza, nie jesteśmy również w stanie po- wtórzyć wszystkich korzystnych działań, jeśli sobie ich nie uświadomimy. 30 Podstawy zarządzania projektami Kolejne działania w kierowaniu projektem Wprawdzie określenie kolejnych działań składających się na prowadzenie projektu jest łatwe, ale realizacja tych działań wcale nie musi być taka prosta. Działania te przedstawia mo- del pokazany na rysunku 1.4. Rysunek 1.4. Kolejne działania w kierowaniu projektem Ogólnie o zarządzaniu projektami 31 Kolejne rozdziały tej książki bardziej szczegółowo oma- wiają realizację każdego z tych działań. Póki co, ograniczy- my się tylko do zwięzłej ich charakterystyki. OKREŚLENIE PROBLEMU Jak wspominaliśmy wcześniej, trzeba określić problem, któ- ry chcemy rozwiązać realizując projekt. Przydatne okazuje się tu wyobrażenie sobie końcowego rezultatu. Na czym bę- dzie polegać jego niepowtarzalność? Co zobaczymy, usły- szymy, posmakujemy, dotkniemy i powąchamy? (Jeśli mamy do czynienia z czymś niewymiernym, wykorzystajmy zmy- sły). Jaką potrzebę klienta zaspokajamy za pomocą projektu? WYPRACOWANIE OPCJI ROZWIĄZANIA Jak wiele jest różnych sposobów rozwiązania danego pro- blemu? Spróbujmy określić (samodzielnie lub wspólnie z ze- społem) rozmaite możliwości rozwiązania. Która z tych al- ternatyw naszym zdaniem najlepiej rozwiąże problem? Czy jest ona bardziej, czy mniej kosztowna niż inne możliwe do zrealizowania opcje? Czy doprowadzi ona do całkowitego, czy tylko częściowego rozwiązania? ZAPLANOWANIE PROJEKTU Planowanie to odpowiadanie na pytania — co trzeba zrobić, kto ma to zrobić, za ile, jak, kiedy itd. Naturalnie odpowia- danie na te pytania często wymaga daru przewidywania przyszłości. Bardziej szczegółowo omówimy te kroki w roz- działach od drugiego do czwartego. REALIZACJA PLANU To oczywiste. Kiedy naszkicujemy plan, trzeba go zrealizo- wać. Co ciekawe, czasem okazuje się, że ludzie wkładają mnóstwo pracy w opracowanie planu, a później go nie prze- strzegają. Jeśli nie przestrzega się planu, to czy jest w ogóle sens planować? 32 Podstawy zarządzania projektami MONITOROWANIE I KONTROLA WYKONANIA Plany opracowuje się po to, by skutecznie osiągać końcowy rezultat. Jeśli nie monitoruje się wykonania planu, nie moż- na być pewnym, czy nam się uda. To tak, jakby mieć mapę drogową dojazdu do miejsca przeznaczenia i nie uważać w czasie jazdy na znaki drogowe. Naturalnie, jeśli odkryje się odchylenia od planu, trzeba zadać sobie pytanie, co trzeba zrobić, żeby przywrócić pro- jekt na właściwe tory, albo — jeśli wydaje się to niemożliwe — jak zmodyfikować plan, żeby odzwierciedlał nowe oko- liczności. ZAKOŃCZENIE PROJEKTU Kiedy dotrzemy do celu, projekt jest zakończony, ale pozo- staje nam jeszcze jedno, ostatnie działanie. Niektórzy nazy- wają je audytem, inni przeglądem powykonawczym. Jak zwał, tak zwał, chodzi o to, by wyciągnąć pewne nauki z tego, co właśnie zrobiliśmy. Warto zwrócić uwagę na spo- sób formułowania pytań. Co zrobiliśmy dobrze? Co powin- no się poprawić? Czego jeszcze się nauczyliśmy? Zawsze można poprawić to, co zrobiliśmy. Jednakże pytanie o to, co zrobiliśmy źle, może sprawić, że ludzie zamkną się w sobie i mniej chętnie podzielą się swoimi spostrzeżeniami. Dla- tego powinniśmy skupiać się raczej na ulepszeniach niż na szukaniu winnych. Wrócimy jeszcze do tej kwestii. The Project Management Body of Knowlegde (PMBOK®) Project Management Institute stara się określić minimalny zakres wiedzy potrzebnej do skutecznego działania kierow- nika projektu. Obecnie PMI wskazuje dziewięć obszarów Ogólnie o zarządzaniu projektami 33 wiedzy, które krótko podsumowuję poniżej. Pełną wersję publikacji PMI można nabyć na stronie internetowej www. pmi.org3. A oto dziewięć obszarów wiedzy: 1. Zarządzanie integracją projektu. Ten obszar wiedzy pozwala zadbać o prawidłowe zaplanowanie, realizację i kon- trolę projektu. Jego częścią jest również zastosowanie formal- nej kontroli zmian projektu. 2. Zarządzanie zakresem projektu. Zmiany zakresu pro- jektu są często czynnikami, które mogą spowodować prze- rwanie projektu. Zarządzanie zakresem obejmuje autoryzację prac4, opracowywanie deklaracji zakresu, która wyznacza granice projektu, podział prac na łatwiejsze w zarządzaniu elementy, do których przypisane są produkty cząstkowe, we- ryfikację, czy zaplanowany zakres został zrealizowany, oraz wdrażanie procedur kontroli zmian zakresu. 3. Zarządzanie czasem w projekcie. Moim zdaniem ta na- zwa jest odrobinę niefortunna, ponieważ może sugerować, że chodzi o wysiłki poszczególnych osób dotyczące zarzą- dzania własnym czasem. W projektach dotyczy to opraco- wywania harmonogramu, który można zrealizować, a na- stępnie kontrolowania prac, by zapewnić, że tak faktycznie jest. Tak po prostu! 4. Zarządzanie kosztami projektu. Tu z kolei chodzi do- kładnie o to, czego można by się spodziewać. Obszar wiedzy obejmuje szacowanie kosztu zasobów, w tym zasobów ludz- kich, sprzętu, materiałów oraz takich pozycji jak delegacje 3 Wersję polską PMBOK® Guide — Kompendium wiedzy o zarządzaniu projektami — można nabyć na stronie internetowej wydawcy www. mtdc.pl — przyp. tłum. 4 Mowa tu o systemie zatwierdzania rozpoczęcia poszczególnych prac — przyp. tłum. 34 Podstawy zarządzania projektami i inne czynniki wspomagające. Po zakończeniu procesu szacowania koszty są budżetowane i monitorowane tak, by utrzymywać projekt w ramach budżetu. 5. Zarządzanie jakością w projekcie. Jak wspominaliśmy wcześniej, jedną z przyczyn niepowodzeń w projektach jest tendencja do zaniedbywania lub rezygnowania z jakości w celu dotrzymania napiętych terminów realizacji. Nie na wiele się zda, jeśli zakończymy projekt na czas tylko po to, by odkryć, że gotowy produkt nie działa prawidłowo. Za- rządzanie jakością w projekcie obejmuje zarówno zapewnia- nie jakości (planowanie pod kątem spełnienia wymagań), jak i kontrolę jakości (działania podejmowane w celu monitoro- wania wyników, by upewnić się, czy spełniają wymagania). 6. Zarządzanie zasobami ludzkimi w projekcie. Bardzo często zaniedbuje się zarządzanie zasobami ludzkimi w projektach. Ten obszar wiedzy obejmuje ustalenie osób potrzebnych do wykonania zlecenia, określenie ich ról i obowiązków oraz struktury hierarchicznej, w jakiej będą funkcjonowali, pozyskanie tych ludzi, a następnie kiero- wanie nimi w trakcie realizacji projektu. 7. Zarządzanie komunikacją w projekcie. Jak sugeruje nazwa tego obszaru wiedzy, zarządzanie komunikacją obej- muje planowanie, realizację i kontrolę pozyskiwania i roz- prowadzania wszystkich informacji odpowiadających na po- trzeby wszystkich interesariuszy projektu. Informacje te obej- mują stan wykonania projektu, osiągnięcia, zdarzenia, które mogą wpłynąć na innych interesariuszy lub projekty, itd. 8. Zarządzanie ryzykiem w projekcie. Zarządzanie ryzy- kiem to systematyczny proces identyfikacji, analizy i reago- wania na ryzyka w projekcie. Proces obejmuje zwiększanie prawdopodobieństwa i skutków zdarzeń korzystnych oraz zmniejszanie prawdopodobieństwa i skutków zdarzeń nie- korzystnych dla celów projektu. Ogólnie o zarządzaniu projektami 35 9. Zarządzanie zamówieniami w projekcie. Zamawianie potrzebnych w projekcie wyrobów i usług to logistyczny aspekt kierowania zleceniem. Obejmuje podejmowanie de- cyzji o tym, co trzeba zamówić, przygotowywanie zapytań ofertowych lub cenowych, wybór dostawców, administro- wanie kontraktami i zamknięcie ich, kiedy prace zostaną zakończone. Co trzeba zapamiętać (cid:23) Projekt to jednorazowe, wielozadaniowe zlecenie o określo- nych terminach rozpoczęcia i zakończenia, dobrze sprecyzo- wanym zakresie prac, budżecie oraz tymczasowym zespole, który rozwiązuje się po zakończeniu zlecenia. (cid:23) Projekt to również problem przeznaczony do rozwiązania. (cid:23) Zarządzanie projektami ułatwia planowanie, harmonogramo- wanie i kontrolę wszystkich działań, które trzeba wykonać, aby osiągnąć cele projektu. (cid:23) Wszystkie projekty są ograniczone przez wymagania dotyczące wydajności, czasu, kosztów i zakresu. Tylko trzy z tych warto- ści mogą być narzucone — zespół projektu musi mieć możli- wość określenia czwartej z nich. (cid:23) Projekty kończą się niepowodzeniem, ponieważ zespoły zanie- dbują prawidłowe określenie rozwiązywanego problemu. (cid:23) Najważniejsze etapy projektu to: koncepcja, doprecyzowanie, planowanie, realizacja i kontrola oraz zakończenie. 36 Podstawy zarządzania projektami Pytania sprawdzające............................................ 1. Zarządzanie projektami to nie tylko: a. Planowanie. b. Poprawki. c. Harmonogramowanie. d. Kontrola. 2. Problem związany z pracującym kierownikiem projektu polega na tym, że konflikt między koniecznością wykonywania prac a kierowaniem zespołem: a. Utrudnia wyznaczanie priorytetów. b. Sprawia, że przełożony kierownika projektu może uznać, iż celowo spowalnia on tempo pracy. c. Powoduje, że nigdy nie będzie wystarczająco dużo czasu, by porządnie wykonać oba działania. d. Zmusza do postawienia pracy na pierwszym miejscu, przez co może ucierpieć kierowanie zespołem. 3. PMBOK to: a. Określony przez PMI kanon wiedzy, którą powinni skutecznie stosować kierownicy projektu. b. Test administrowany przez PMI w ramach procesu certyfikacji kierowników projektu. c. Skrót szczególnego typu analizy ryzyka, podobnej do FMEA. d. Żadne z powyższych. 4. Zakres projektu określa: a. Pogląd kierownika projektu na datę zakończenia projektu. b. Skalę lub wielkość zlecenia. c. Jak często zmieniał się projekt. d. Ograniczenia uprawnień kierownika projektu.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Podstawy zarządzania projektami. Zdobywanie kwalifikacji pozwalających wyprzedzić konkurencję
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: