Projekty są realizowane w różnych środowiskach. Ich realizacje rozpoczęto w organizacjach operacyjnych, czyli takich, które realizują swoje cele biznesowe poprzez realizację ciągłych, standardowych procesów. Organizacjami takimi są wojsko (właściciel jednego z pierwszych bardzo znanych projektów: Manhattan – budowa bomby atomowej). Projekty przez długi czas były realizowane jako część biznesu organizacji operacyjnych. Następnie zaczęły powstawać organizacje mieszane [1] : takie, w których główna część biznesu jest realizowana poprzez działalność operacyjną, ale realizuje się także projekty. Przykładem może być wytwórnia samochodów, w których większość produktów to wytwory seryjne, ale firma na specjalne życzenia wykonuje także specjalne samochody. Najbardziej zaawansowane w zakresie zarządzania projektami są te organizacje, w których całość biznesu jest realizowana poprzez działalność projektowi. Są to organizacje nastawione na projekty (ONP) – takie, które swoje cele biznesowe realizują poprzez realizację projektów. Sektorami przemysłu, w których największy udział mają ONP są np. budownictwo oraz informatyka.

Pojęcia ONP nie należy mylić z organizacją zarządzaną projektowo, chociaż najbardziej korzystne jest zarządzanie ONP w sposób projektowy. Organizacja zarządzana projektowo (w dużym uproszczeniu) to taka, której elementarnymi jednostkami organizacyjnymi są zespoły projektów.

Rodzaje projektów

Z rodzajem organizacji powiązane jest pojęcie rodzaju projektu (Tabela 1). Kryteriami klasyfikacji projektów są:

· Wprowadzanie zmian w sposobie realizacji biznesu klienta projektu

· Relacja organizacji (firmy) klienta i organizacji wykonawcy

Tabela 1. Rodzaje projektów w zależności od rodzaju organizacji

		Zmiana sposobu realizacji biznesu klienta
		Tak	Nie
Klient = wykonawca	Tak	Wewnętrzny Inwestycyjny	Wewnętrzny Usługowy
Klient = wykonawca	Nie (zwykle ONP)	Komercyjny Inwestycyjny	Komercyjny Usługowy

Projekty wewnętrzne inwestycyjne

Przykładami projektów tego rodzaju są:

· Wdrożenie systemu FK we własnej organizacji

· Budowa fabryki we własnej organizacji

Projekty wewnętrzne usługowe

Przykładami projektów tego rodzaju są:

· Budowa następnej linii przesyłowej w zakładzie energetycznym

· Wytworzenie nowego rodzaju lekarstwa w koncernie farmaceutycznym

Projekty komercyjne inwestycyjne

Przykładami projektów tego rodzaju są:

· Wdrożenie systemu FK w innej organizacji

· Projekt doradczo-restrukturyzacyjny organizacji zewnętrznej

Projekty komercyjne usługowe

Przykładami projektów tego rodzaju są:

· Budowa domu przez developera dla zewnętrznego inwestora

· Wykonanie badań rynkowych dla producenta dóbr konsumpcyjnych

Projekt w ONP

Zgodnie z najbardziej znaną definicją, umieszczoną w PMBoK [3] :

D1.Projekt jest to ograniczone w czasie przedsięwzięcie podjęte w celu wytworzenia unikalnego produktu, usługi lub innego wyniku.

Definicja ta, z punktu widzenia ONP, ma istotne wady.

1. Unikalność produktu

Wymaganie unikalności produktu, szczególnie w ONP, jest zbyt mocne. Kilkakrotne stawianie domu według tego samego projektu (a także takiego wg. samego procesu) za każdym razem jest w ONP uważane za projekt.

2. Definiowanie poprzez cechę produktów

Zgodnie z podstawowymi standardami (PMBoK, Prince 2 [2] ) najpierw określa się potrzeby biznesowe, a później, po podjęciu decyzji o uruchomieniu projektu, dokładnie definiuje się produkt i sposób jego wytworzenia.

Tak zbudowany proces uruchamiania projektu jest niezgodny z definicją projektu opartą na cechach produktu (także procesu wytwórczego). Zgodnie z tą definicją, o tym czy prace mogą być uznane za projekt, można się wypowiadać wtedy, kiedy jego produkt jest dobrze określony, czyli po jego uruchomieniu. A zarówno PMBoK, jak i Prince 2 nakazują wypowiedzenie się o tym, czy coś jest projektem, i to w sposób najbardziej istotny, poprzez jego uruchomienie, wtedy kiedy produkt nie jest jeszcze zbyt precyzyjnie zdefiniowany.

Definicja projektu powinna się więc odwoływać wyłącznie do obszaru biznesowego, ponieważ w tej sferze podejmowana jest decyzja o uruchomieniu projektu.

D2.Projekt jest to realizacja elementarnego celu biznesowego, którego nie można osiągnąć poprzez działania operacyjne.

Prace (procesy) realizowane aby biznes zrealizować, oraz produkty tych procesów to czynniki wtórne względem biznesu podmiotu zaangażowanego w projekt.

Rysunek 1. Projekt klienta a projekt wykonawcy

Kolejną konsekwencją przyjęcia takiej definicji jest stwierdzenie, że:

Projekt klienta i projekt wykonawcy, w ramach którego wykonywane są te same, określone prace, są różnymi projektami.

Dlatego też konieczne jest istnienie modeli projektów zarówno klientów jak i wykonawców, którymi bardzo często są ONP.

Spojrzenie na projekty w głównych standardach

Po stwierdzeniu, że perspektywa biznesowa znacząco wpływa na samą definicję projektu, należy przyjrzeć się, jak to rozróżnienie spojrzenia jest uwzględniane w podstawowych standardach zarządzania projektami. Krótkiej analizie poddano dwa najbardziej znane w Polsce standardy: amerykański (a raczej globalny) PMBoK i brytyjski, popularny także w Europie, Prince 2.

PMBoK

Przyjrzyjmy się opisowi celu realizacji projektów w PMBoK. Zgodnie z tym standardem Celem projektu jest osiągnięcie zamierzonego rezultatu i zakończenie projektu, podczas gdy działalność operacyjna ma zapewnić ciągłe funkcjonowanie przedsiębiorstwa. [p. 1.2.2]

Dla ONP jest to fałszywe przeciwstawienie. W ONP właśnie realizacja projektów jest ciągłym funkcjonowaniem przedsiębiorstwa.

Przedsięwzięcia są sposobem na zrealizowanie takich zamierzeń, których nie da się osiągnąć w trakcie normalnej działalności operacyjnej organizacji. [p. 1.2.3]

Dla ONP stwierdzenie to także nie jest prawdziwe.

Przedsięwzięcia zatwierdza się na ogół w rezultacie wystąpienia przynajmniej jednego z poniższych czynników strategicznych:

Popyt rynkowy (np. .... budowa nowej rafinerii benzyny w odpowiedzi na stały niedobór benzyny)
Potrzeba związana z działalnością organizacji (np. opracowanie nowego kursu szkoleniowego)
Zlecenie klienta (np. firma zajmująca się dystrybucją energii elektrycznej zatwierdza projekt budowy nowej podstacji, która ma obsługiwać nową strefę przemysłową)
Postęp technologiczny (np. firma produkująca oprogramowanie zatwierdza projekt opracowania nowej generacji gier wideo, w odpowiedzi na wprowadzenie na rynek przez firmę elektroniczną nowej konsoli do gier)
Wymagania prawne (np. producent farb zatwierdza projekt określenia zasad obchodzenia się z nowymi materiałami toksycznymi). [p. 1.2.2]

Dla ONP nie są to powody uruchomienia projektów komercyjnych. W ONP powodem realizacji projektu jest przede wszystkim uzyskanie marży (lub bezpośrednia realizacja celów statutowych, jeśli ONP nie jest przedsiębiorstwem komercyjnym).

PMBoK opisuje projekt z punktu widzenia jego klienta.

Prince 2

Podejście do realizacji projektów reprezentowane w Prince 2 jest najlepiej opisane w następujących stwierdzeniach:

Zasadniczą filozofią Prince 2 jest kierowanie projektem zgodnie z uzasadnieniem biznesowym [rozdz. 13].
W środowisku klient / wykonawca zawsze są dwa uzasadnienia biznesowe: klienta i wykonawcy. Jeśli nie jest to powiedziane inaczej, w tym podręczniku, „uzasadnienie biznesowe” oznacza uzasadnienie biznesowe klienta. [p. 14.1.4]

Prince 2 ani razu, poza tym zapisem, nie odnosi się do uzasadnienia biznesowego wykonawcy projektu. Czyli jest to standard przeznaczony wyłącznie dla klienta projektu.

Rada Projektu nie jest demokracją rządzoną większością głosów. Sponsor [reprezentujący klienta] jest głównym decydentem, wykorzystującym rady i zaangażowanie pozostałych członków [Rady Projektu]. [p. 14.2.1]

W Radzie Projektu są przedstawiciele wykonawcy, ale jak widać nie mają oni możliwości uczestniczenia w podejmowaniu decyzji.

A więc Prince 2 reprezentuje wyłącznie punkt widzenia klienta projektu. Nie jest to standard przeznaczony dla ich wykonawców, którymi zwykle są ONP.

Żaden z podstawowych standardów zarządzania projektami nie opisuje projektów komercyjnych realizowanych w ONP. Jest to istotny brak, ponieważ na świecie obserwujemy coraz większą tendencję do realizacji prac w postaci projektów. Coraz większa liczba przedsiębiorstw to organizacje nastawione na projekty.

Różnice w sposobach realizacji projektów pomiędzy organizacjami operacyjnymi i ONP

Realizacja projektów przez klienta różni się od realizacji projektów przez Organizacje Nastawione na Projekty nie tylko ogólnym podejściem, opisanym w poprzednich rozdziałach. Także w poszczególnych obszarach te dwa rodzaje organizacji kładą nacisk na różne aspekty zarządzania.

Cykl życia projektu

Klient – wiele faz

Klient zwykle może zaplanować projekt tak, żeby kolejne jego fragmenty przynosiły konkretne korzyści. Fazy planuje się tak, żeby po każdej z nich można było ocenić możliwości realizacji faz następnych i ryzyko związane z przyszłymi fazami. Jeżeli perspektywy dalszej realizacji nie są dostatecznie dobre, projekt można przerwać.

Na przykład realizacja projektu pokrycia terenu siecią telefonów komórkowych ma fazy zawierające poszczególne fragmenty tego terenu. Gdy inwestor (klient projektu) dojdzie do wniosku, że wyniki realizacji projektu nie są dostatecznie pozytywne, może na podstawie własnej decyzji zrezygnować z faz, w których przewidywano wykonanie pokrycia dla dalszych rejonów.

Wykonawca – nie więcej niż dwie fazy

Kontrakty są podpisywane z klientem zwykle na ściśle określony zestaw prac. Zapisy mówiące o możliwości odstąpienia od realizacji prac mają przeważnie charakter zapobiegania sytuacjom awaryjnym. Projekt wykonawcy często jest fragmentem projektu klienta. Projekt wykonawcy składa się przeważnie z nie więcej niż dwóch faz: analiza wykonalności i realizacja prac.

Zarządzanie biznesem

Klient – pośrednie efekty biznesowe

Cele realizacji projektu przez klienta najlepiej opisane są w PMBoK (patrz podrozdz. 0). Są to różne przesłanki, związane z sytuacją biznesową: np. spełnienie wymagań prawnych, inwestycja nastawiona na przyszłe funkcjonowanie organizacji. Jest to pośrednie nastawienie na uzyskanie efektów biznesowych. U klienta projekty są bezpośrednio przede wszystkim źródłem kosztów. Zyski z projektów są uzyskiwane z wykorzystania efektów projektów.

Wykonawca – bezpośrednie efekty biznesowe

W ONP podstawowym celem biznesowym realizacji projektu jest osiągnięcie bezpośredniej korzyści biznesowej. Firmy komercyjne uzyskują przychody z realizacji projektów w trakcie lub bezpośrednio po zakończeniu projektu.

Zarządzanie zakresem

Klient – nastawienie na zakres produktu

Klient jest skoncentrowany, jak napisano wyżej, na pośrednich efektach biznesowych projektu. Efekty te są uzyskiwane dzięki wytworzonym i używanym produktom projektu. Z punktu widzenia klienta projekt jest zestawem uzyskanych w jego wyniku produktów. Zestaw produktów projektu, zgodnie z definicją PMBoK, to zakres produktu – nim właśnie przede wszystkim zainteresowany jest klient projektu.

Wykonawca – nastawienie na zakres projektu

Wykonawca dostarcza zasoby do realizacji prac projektu. Zadaniem kierownika projektu jest sprawne wykonanie wszystkich zaplanowanych prac (w wyniku których powstają produkty) w przewidziany sposób. Zestaw wykonywanych prac jest nazywany zakresem projektu – to jest główny punkt zainteresowania wykonawcy projektu.

Zarządzanie harmonogramem

Klient – kamienie milowe

Dla klienta przede wszystkim ważne są terminy dostarczania produktów projektu. Terminy takie są określone w umowie. Terminy realizacji elementarnych czynności nie mają szczególnego znaczenia dla klienta, o ile czynności te nie są realizowane z zaangażowaniem jego pracowników.

Wykonawca – szczegółowy harmonogram

Wykonawca musi opracować i realizować zgodnie z planem szczegółowy harmonogram projektu. Harmonogram wykonawcy musi być opracowany dla wszystkich prac, na ostatecznym, maksymalnym poziomie szczegółowości.

Zarządzanie kosztem

Klient – minimalizacja planu kosztów

W zakresie zarządzania kosztem występuje jeden z bardziej oczywistych konfliktów biznesowych. Klient oczekuje jak najtańszego wykonania produktu, czyli minimalizacji kosztu zatwierdzonego (a potem realizacji tych ustaleń, ale pozostawia je stronie wykonawczej). Szacowanie kosztu odbywa się przy ustalonym zakresie prac projektu. Oznacza to, że klient oczekuje minimalizacji kosztu poprzez zmniejszenie kontraktowej ceny jednostki pracy oraz zmniejszenie liczby tych jednostek.

Wytwórca – maksymalizacja planu, minimalizacja zrealizowanych kosztów

W trakcie ustalania warunków realizacji projektu wykonawca jest zainteresowany ustaleniem jak największych kosztów, aby uzyskać jak najwyższą wypłatę. Natomiast w trakcie realizacji projektu, aby osiągnąć jak najwyższą marżę, stara się je zminimalizować – na tyle, żeby móc się wywiązać z umowy.

Zarządzanie jakością

Klient – jakość maksymalna

Naturalnym dążeniem klienta jest uzyskanie produktu doskonałego, takiego który w jak najlepszy sposób spełni jak najwięcej jego wymagań. Dążenie do uzyskania takiego produktu objawia się zarówno w trakcie przygotowywania umowy z wykonawcą, jak i w trakcie jej realizacji. Często spotykanym problemem jest formułowanie wymagań dotyczących produktu w trakcie jego realizacji przez osoby ze strony klienta, nie będące świadomymi, jak została podpisana umowa. Jakość wymagana przez klienta odnosi się bezpośrednio do jego potrzeb.

Wykonawca – jakość wymagana

Celem wykonawcy jest dostarczenie produktu mającego jakość odpowiadającą wymaganiom ustalonym z klientem. Jakość jest określana w trakcie opracowywania umowy. Po podpisaniu umowy celem wykonawcy jest dostarczenie produktu spełniającego wymagania.

W perspektywie biznesowej podejście klienta i wykonawcy nie muszą być sprzeczne. Wynagrodzeniem za jakość wyższą niż wymagana może być korzyść biznesowa w postaci następnej umowy podpisanej z zadowolonym klientem.

Zarządzanie ryzykiem

Klient – ryzyka efektów biznesowych

Podejście do ryzyka i zarządzania nim w projekcie jest pochodną podejścia do zarządzania jakością. Głównym ryzykiem z punktu widzenia klienta jest nieuzyskanie spodziewanych efektów mimo zainwestowania środków. Klient obawia się przede wszystkim, że otrzymany produkt nie będzie spełniał jego wymagań. Na bardziej szczegółowym poziomie ryzykiem po stronie niewłaściwe określenie efektów biznesowych; za małe wsparcie wyższych przełożonych we wdrożeniu produktów projektu.

Ryzykiem klienta jest odebranie produktu nie spełniającego oczekiwań.

Wykonawca – ryzyka techniczne

Odpowiednikiem ryzyka klienta, polegającego na niespełnieniu oczekiwań biznesowych przez produkty projektu, jest analogiczne ryzyko niewłaściwego oszacowania kosztów realizacji projektu, a więc nieuzyskania właściwej marży po stronie wykonawcy. Z ryzykiem tym związane są ryzyka techniczne, bezpośrednio wpływające na prace projektowe, na przykład wybór nieodpowiednich narzędzi produkcyjnych czy personelu.

Ryzykiem wytwórcy jest nieodebranie wytworzonego produktu.

Zarządzanie poddostawcami

W relacji klient – wykonawca, kontakty z wykonawcą projektu są relacjami z poddostawcą. Za relacje głównego wykonawcy z jego poddostawcami odpowiada główny wykonawca projektu, a nie jego zleceniodawca (klient). Dla każdego podwykonawcy, z jego punktu widzenia, jego prace są projektem, podczas gdy dla zleceniodawcy prace te mają charakter właśnie prac podwykonawczych.

Rysunek 2. Względność relacji bycia poddostawcą

W zaprezentowanym przykładzie projekt P1.1 jest w projekcie P1 projektem podwykonawczym. Natomiast projekt ten dla jego wykonawcy jest po prostu projektem; jego podwykonawcami są projekty P1.1.1 i P1.1.2, zapewne mało widoczne dla projektu P1.

Zarządzanie personelem

Klient – personel nadzorujący, konsultacyjny i odbierający

Klient musi sobie zagwarantować właściwą realizację projektu. Chociaż realizacja prac leży po stronie wykonawcy, to nadzór, którego zakres jest określany w umowie, leży po stronie klienta. Klient musi więc zagwarantować osoby realizujące ten nadzór. Drugą powinnością klienta jest dostarczenie specjalistów, znających środowisko, w którym efekty projektu będą wdrażane – personel konsultacyjny. Prace, które muszą być wykonane przez klienta, to odbiór produktów projektu: osoby odbierające produkty są dostarczane z jego strony.

Wykonawca – personel wykonawczy

Główną cechą wykonawcy jest wykonywanie większości prac w projekcie. Po stronie wykonawcy leży skompletowanie zespołu realizującego prace oraz osób kierujących wykonaniem prac oraz wspomagających je (np. administracja projektu).

Zarządzanie komunikacją

Klient – komunikacja nadzorcza

Sposób i zakres zarządzania komunikacją zależy od udziałowców zaangażowanych po obydwu stronach oraz ich potrzeb informacyjnych. Ponieważ klient jest zainteresowany nadzorowaniem projektu, po jego stronie realizowany jest głównie przepływ informacji zarządczych: postęp prac, uzyskane wyniki.

Wykonawca – komunikacja techniczna i zarządcza

Główny strumień informacji przepływających po stronie wykonawcy to informacje techniczne, konieczne do zrealizowania cyklu wytwórczego produktu. Konieczny jest także przepływ wszelakich informacji pozwalających sprawnie realizować prace: dotyczących zakresu, kosztu, harmonogramu i wszystkich innych obszarów zarządzania projektem.

Zarządzanie integralnością

Zarządzanie integralnością jest wspólne dla obydwu stron. Jednym z podstawowych celów tego obszaru jest właśnie zagwarantowanie, żeby projekt klienta i projekt wykonawcy były tym samym, sprawnie realizowanym w trybie win-win, projektem.

Różnice w tym obszarze dotyczą większego zainteresowania wykonawcy zarządzaniem konfiguracją oraz zarządzaniem zmianami. Wykonawca musi stosować techniki zarządzania konfiguracją do wszystkich obiektów projektu, nie tylko produktów przekazywanych klientowi. W zakresie zintegrowanego zarządzania zmianą klient jest zainteresowany przede wszystkim (ale nie tylko) zmianami zakresu, natomiast wykonawca – zmianami we wszystkich obszarach zarządzania.

Podsumowanie

Istniejące główne metodyki zarządzania projektami najwięcej uwagi poświęcają projektom inwestycyjnym (spojrzenie klienta). Sytuacja ta przestaje odpowiadać zmieniającej się rzeczywistości, w której coraz większa część biznesu jest realizowana w ramach paradygmatu projektowego, a nie operacyjnego. Pojawiła się więc potrzeba nowego, szerszego spojrzenia na zarządzanie projektami, uwzględniającego także perspektywę wykonawcy. Potrzeba ta może być zaspokojona na dwa sposoby:

Opracowanie dwóch bardziej wyspecjalizowanych modeli, uwzględniających osobno spojrzenie każdej ze stron zaangażowanych w realizację projektu.
Opracowanie jednego modelu uwzględniającego jednocześnie spojrzenie wykonawcy i klienta projektów.

Docelowo powinien istnieć jeden wspólny model, oparty na podejściu win-win. Opracowanie dwóch osobnych modeli należy uważać za etap przejściowy w opracowaniu docelowego, wspólnego modelu. Konieczność wystąpienia pierwszej z tych faz jest także uzasadniana przez aktualny brak równowagi w reprezentowaniu interesów obydwu głównych podmiotów zarządzania projektami: zdecydowana większość publikacji opisuje projekty z punktu widzenia ich klientów. Opracowanie drugiej części pierwszego modelu – opisujących projekty z punktu widzenia ich zewnętrznych wykonawców – jest koniecznym elementem realizacji pierwszej z powyżej opisanych faz.