Encyklopedia Zarządzania :: Zarz��dzanie projektami w organizacjach
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.
Wyszukiwarka pełnotekstowa (kliknij)
Cytaty i parafrazy (0 - 18 z 18)
(cytat, str. 3) "Zorientowanie projektu na cel wiąże się z niezwykle ważnymi konsekwencjami dla procesu zarządzania nim. Jak się bowiem można domyślać, z jednej strony kluczowym elementem tego procesu staje się właściwe określenie celów, począwszy od celu podstawowego, poprzez wszystkie cele pośrednie. Z drugiej zaś, realizacja projektu staje się pogonią za starannie obranymi celami, a postęp projektu sprowadza się do osiągania kolejnych, coraz ważniejszych w hierarchii celów pośrednich, czego uwieńczeniem jest dotarcie do celu podstawowego."
(cytat, str. 5) "Projekty realizuje się w ściśle określonym czasie (choć menedżerowie doświadczający opóźnień względem przyjętego harmonogramu mogą mieć niekiedy wrażenie, że realizacja projektu wydłuża się w nieskończoność). Cechą charakterystyczną projektu jest jego tymczasowość. Ma on względnie jasno zdefiniowany początek oraz koniec. Kiedy się osiąga podstawowy cel projektu, sam projekt dobiega końca. Istotna część wysiłków związanych z realizacją projektu polega na dążeniu do zakończenia go w założonym czasie. W tym celu tworzy się harmonogramy określające, kiedy powinny zacząć się i skończyć poszczególne etapy projektu."
(cytat, str. 10) "Plan jest swego rodzaju mapą pokazującą, jak przejść od jednego etapu realizacji projektu do następnego. Powinien obejmować cały czas trwania projektu. Początkowo tworzymy zwykle nieformalny plan wstępny (preplan)- ogólną koncepcję mówiącą o tym, czego będzie wymagać realizacja wybranego przez nas projektu."
(cytat, str. 11) "W czasie realizacji projektu menedżer zarządzający nim nieustannie kontroluje jego postęp. sprawdza, jakie działania zostały wykonane, i ustala, jak stan faktyczny ma się do przygotowanego wcześniej planu. W zarządzaniu projektem ewentualne rozbieżności zwane są odchyleniami (variances). Możemy być absolutnie pewni, że w każdym projekcie odchylenia takie występują. Nie udało się nam dotąd udoskonalić metod prognozowania do tego stopnia, żebyśmy mieli całkowitą pewność, co przyniesie nam przyszłość, i tak długo, jak okryta jets ona mrokiem niepewności, plany naszych projektów będą niedoskonałe."
(cytat, str. 30 - 31) "Menedżer zarządzający projektem przypomina nieco w tym względzie polityka. Najczęściej nie otrzymuje władzy w prezencie i nie ma zwykle możliwości bezpośredniego narzucania swej woli współpracownikom, podwykonawcom i dostawcom. Podobnie jak polityk, jeśli ma osiągnąć swój cel, musi znaleźć sposób efektywnego wywierania wpływu na innych. (...) jednym ze sposobów skłonienia innych do wykonywania naszych poleceń jest zbudowanie autorytetu. Ale politykom nie wystarcza tylko samo posiadanie autorytetu. Muszą również dokładnie poznać środowisko, w którym ich autorytet ma być wykorzystany. Muszą być realistami."
(cytat, str. 71 - 72) "Kiedy mamy do czynienia z konkretnym projektem, nie możemy- ani nie powinniśmy- stosować wyłącznie jednego stylu zarządzania. doświadczony menedżer uzależnia swoje podejście od okoliczności, z którymi ma do czynienia w danej chwili. Dlatego w fazie twórczego planowania projektu zastosuje wobec swych najbliższych współpracowników styl leseferyczny, a w bardziej rutynowej fazie realizacji- podejście demokratyczne. Czasem może dojść do wniosku, że jedynym sposobem przywołania do porządku kapryśnego dostawcy jest przyjęcie wobec niego postawy autokratycznej, natomiast w kontaktach z innym dostawcom, który przez wiele lat regularnie dowodził swojej solidności i wiarygodności, zastosuje styl leseferyczny."
(cytat, str. 76) "Zespół projektowy ma określoną strukturę, czyli reguły rządzące relacjami pomiędzy poszczególnymi członkami zespołu oraz między nimi a menedżerem, klientem i produktem, nad którym pracują. Od struktury zespołu w znacznym stopniu zależą perspektywy pomyślnej realizacji projektu- odpowiednia struktura zwiększa prawdopodobieństwo sukcesu, zaś słaba z pewnością jest przyczyną kłopotów. Dobra struktura zespołu jest koniecznym, choć niewystarczającym warunkiem sukcesu, słaba- gwarantuje klapę. wobec tego powinniśmy zadać sobie pytanie: jak trzeba budować strukturę zespołu projektowego, by stworzyć warunki umożliwiające efektywne zarządzanie projektem? Odpowiedź brzmi: tak, aby zwiększała wydajność zespołu."
(cytat, str. 76) "Zespoły projektowe- podobnie jak same projekty- występują w bardzo różnej postaci i wielkości. Niektóre są wielkie, inne- małe. Niektóre muszą się borykać z niezwykle złożonymi i nietypowymi problemami, inne- realizują rutynowe zadania. Niektóre są bardzo dynamiczne, a ich członkowie nieustannie się zmieniają, inne nie podlegają zmianom przez cały projekt."
(cytat, str. 82 - 83) "Ponieważ dążymy do takiej struktury zespołów projektowych, która wzmacniałaby ich wydajność, musimy się wystrzegać elementów strukturalnych sprzyjających tarciom organizacyjnym, które omówiliśmy powyżej. Zatem pożądana struktura zespołu projektowego powinna: rozwiązywać problemy rotacji pracowników i braku bezpośredniej kontroli menedżera projektu nad zasobami, zwiększać efektywność komunikacji pomiędzy członkami zespołu projektowego oraz zapewniać integrację poszczególnych elementów projektu. Nie istnieje struktura idealna, która sprawdzałaby się we wszystkich projektach. Model spełniający swą rolę w jednym projekcie może się okazać niewypałem w innych."
(cytat, str. 99 - 100) "Projekty uruchamia się w celu zaspokojenia potrzeb człowieka. Kiedy pojawia się i zostaje zidentyfikowana określona potrzeba, kierownictwo organizacji decyduje, czy jest ona warta zaspokojenia, a następnie przygotowuje się projekt, którego celem jest właśnie zaspokojenie określonej potrzeby. A zatem potrzeby są podstawową przyczyną uruchamiania projektów i dlatego mają decydujące znaczenie dla procesu zarządzania projektem. Pojawienie się potrzeby wyzwala ten proces. Jeśli od początku nie będziemy w pełni rozumieli danej potrzeby i wszystkiego co się z nią wiąże, jeśli niepoprawnie ją zdefiniujemy albo przez pomyłkę zajmiemy się niewłaściwą potrzebą, pozbawimy nasz projekt solidnego fundamentu i możemy być pewni, że będziemy mieli problemy z jego ukończeniem"
(cytat, str. 105) "Po uważnym zdefiniowaniu potrzeb otrzymujemy podstawę do stworzenia planu projektu. Dokonujemy tego, formułując potrzeby, jako wymogi funkcjonalne (functional requirements). Opisują one cechy charakterystyczne produktu- czyli tego, co otrzymujemy w chwili zakończenia projektu- za pomocą terminów zrozumiałych dla ludzi nie mających przygotowania technicznego."
(cytat, str. 105 - 106) "Wymogi techniczne powstają na podstawie wymogów funkcjonalnych. Wprawdzie wymogi funkcjonalne powinny być jasno sformułowane, ale zwykle nie stanowią wystarczająco precyzyjnych wskazówek dla pracowników realizujących projekt, aby mogli je traktować jako cel swoich działań. Wymogi funkcjonalne pozwalają nam się upewnić, że klient orientuje się, jaki jest planowany końcowy produkt projektu. Natomiast wymogi techniczne stanowią podstawę działań pracowników technicznych i dlatego często są niezrozumiałe dla klientów nie posiadających odpowiedniej wiedzy w tym zakresie."
(cytat, str. 122) "Znaczenie wymogów wynika przynajmniej z dwóch przyczyn. po pierwsze, są one ucieleśnieniem potrzeb klienta- końcowym produktem procesu ich definiowania stanowiącym podstawę planu projektu. Ostatecznym celem procesu planowania projektu jest ustalenie, w jaki sposób najprościej można spełnić wymogi klienta. Zatem niewłaściwe, czy nawet niewystarczająco precyzyjne sformułowanie wymogów, może prowadzić do stworzenia nieodpowiedniego planu. Po drugie, za pomocą wymogów definiujemy zobowiązania zespołu projektowego wobec klienta. Poprawnie zdefiniowane wymogi projektu umożliwiają podział obowiązków w ramach zespołu. W wypadku projektów realizowanych na zasadach kontraktu wymogi zapisuje się w postaci zakresu robót do wykonania (statement of work- SOW), stanowiącym podstawę do rozliczenia wykonawcy realizującego kontrakt."
(cytat, str. 141) "Poprawne formułowanie wymogów jest wielkim wyzwaniem. Czyha na nas wiele pułapek: wymogi mogą się okazać niejednoznaczne albo mało realistyczne; mogą mieć niewiele wspólnego z rzeczywistymi potrzebami klientów. Mogą być nazbyt szczegółowe albo niewystarczająco szczegółowe. Mogą być zbyt sztywne albo nadmiernie elastyczne. (...) (...) zespół projektowy może wykonać wiele działań prowadzących do dobrze zdefiniowanych wymogów. Najważniejszy krok wydaje się jednak najłatwiejszy- trzeba uświadomić sobie znaczenie wymogów dla ewolucji projektu. Musimy przyjąć do wiadomości, że wymogi stanowią podstawę planu projektu, ponieważ jego celem jest określenie najbardziej efektywnych sposobów spełnienia oczekiwań klienta. zatem jeśli wymogi są źle sformułowane, wówczas plan projektu jest również obciążony skazą, a co za tym idzie, projektowi grozi niepowodzenie. Zrozumienie zależności pomiędzy wymogami i planem projektu pozwoli nam uświadomić sobie, że zmiany wymogów prowadzą do przekroczenia budżetu i terminów, ponieważ wymagają odpowiednich zmian w planie projektu."
(cytat, str. 146) "Plan projektu jest swego rodzaju mapą mówiącą jak dostać się z A do B. Najczęściej traktuje się go jako początek całego projektu- zapowiedź przyszłych zdarzeń. ale trzeba uświadomić sobie, że plan jest efektem wielu wcześniejszych działań. (...) plan pojawia się stopniowo w miarę definiowania potrzeb, formułowania wymogów, opracowywania prognoz dotyczących przyszłości i analizowania dostępnych zasobów. Dopiero kiedy wyniki tych działań przemyślimy, powiążemy ze sobą, dopracujemy, poddamy selekcji i scalimy, otrzymamy plan, który możemy wykorzystać jako mapę naszego projektu. Plan najczęściej opisuje projekt w kontekście trzech wymiarów- czasu, pieniędzy oraz zasobów ludzkich i materialnych. Z każdym z nich wiążą się określone narzędzia i techniki planistyczne. Wymiar czasu opisywany jest za pomocą harmonogramów, które tworzymy, korzystając z szerokiej gamy narzędzi o różnym stopniu złożoności. Pozwalają nam one określić, kiedy powinny się rozpocząć poszczególne działania (...)."
(cytat, str. 150) "Kontrola projektu polega na zapoznaniu się z planem, sprawdzeniu, co aktualnie dzieje się w projekcie, a następnie porównaniu wniosków z obu obserwacji. Podobnie jak w wypadku planowania, interesują nas trzy wymiary: czas, pieniądze oraz zasoby ludzkie i materialne."
(cytat, str. 151 - 152) "Każda osoba przygotowująca plan projektu albo metody jego kontroli musi odpowiedzieć na pytanie dotyczące zakresu planowania i kontroli. trudno jednoznacznie rozwiązać ten problem. Z jednej strony wydaje się, że powinniśmy dążyć do tworzenia możliwie najbardziej szczegółowych planów i uzyskania możliwie największej kontroli, marginalizując tym samym niepewność związaną z projektem. (...) Z drugiej jednak strony planowanie i kontrola wiążą się z określonymi kosztami. Zależność pomiędzy kosztami projektu a kosztami planowania i kontroli można wyrazić następującym wzorem: Koszty projektu = koszty produkcji + koszty administracyjne Jak widać, wzrost kosztów planowania i kontroli (to znaczy kosztów administracyjnych) powoduje wzrost całkowitych kosztów projektu. Co więcej, powoduje, że coraz mniejszą część naszego budżetu przeznaczamy na bezpośrednie działania produkcyjne."
(cytat, str. 190) "Projekty często łączy się w portfele, to znaczy zestawy projektów, które muszą być zarządzane w skoordynowany sposób, niezależnie od tego, czy są ze sobą powiązane, czy też nie. Z portfelami projektów spotykamy się w różnych sytuacjach. Są one powszechne w działach przetwarzania danych, gdzie pracuje się jednocześnie nad wieloma projektami- długo- i krótkoterminowymi, małymi i dużymi. Firmy doradcze stanowią często- z funkcjonalnego punktu widzenia- konglomerat pojedynczych projektów. Równoległa realizacja wielu projektów to również codzienność działów badawczo- rozwojowych, firm audytorskich i działów rachunkowości, a także agencji reklamowych."