Controlling projektów w organizacji klienta cz II

Z niedoskonałym pianem w ręku nadal można panować nad projektami i procesami jednocześnie. Tak można zdefiniować cel istnienia controllingu projektów w organizacji klienta. Niniejsze opracowanie stanowi próbę odpowiedzi na pytania postawione w części pierwszej cyklu

W literaturze poruszane są zagadnienia procesu zarządzania projektami rozumianego jako zestaw działań sterujących powoływaniem, realizacją, zamykaniem projektów. Działania te muszą zawierać w sobie wbudowany proces budżetowania. Dla przykładu, Bogusław Niedbała w książce „Controlling funkcyjny w przedsiębiorstwie" (red. M. Sierpińska) wyróżnił stadia kalkulacji wstępnej i kalkulacji ofertowej zmierzające finalnie do opracowania budżetu projektu. Stadia te są typowe w organizacji projektowej wykonawcy. W organizacji klienta stadia te odpowiadają tworzeniu preliminarzy budżetowych dla projektów wewnętrznych. Jest to najważniejsza część wspólna w controllingu projektów w organizacjach projektowych wykonawców i organizacjach ich klientów.
Istotna różnica pomiędzy organizacją wykonawcy i klienta zasadza się w wycenie korzyści (metodycznie: wycenie wartości projektu). W organizacji klienta konieczne jest stworzenie wieloletniej prognozy porównującej stan „bez projektu" ze stanem „z projektem". W praktyce wycena taka jest trudna. Rzetelne jej wykonanie wymaga przeanalizowania (czy wręcz zamodelo-wania) zmian w procesach przedsiębiorstwa oraz zmian w otoczeniu, a dodatkową komplikację stanowi horyzont czasu.
Błąd w prognozie wzrasta tym bardziej, im odleglejszy okres prognozujemy. Dla projektów, z definicji niejako obarczonych dużą niepewnością i ryzykiem, prognoza drugiego roku po oddaniu produktów projektu do użytkowania często przypomina porównanie wielkiej niewiadomej (tzw. scenariusz „do nothing" lub „bez projektu") z inną wielką niewiadomą (tzw. scenariusz „project" lub „z projektem").

Perspektywy zarządzania

W controllingu projektów oddziela się obszar utrzymania wartości projektów od kosztów i nakładów związanych z produkcją produktów projektu. Oba obszary są spinane przez decydentów pełniących role członków komitetów sterujących (według PRINCE2™) albo sponsora (według PMBOK®). Decydenci ci przyjmują postawę inwestorską lub konsumencką i stosują instrumenty wyceny wartości projektu według własnego uznania.
Z ogółu powyższych działań wynikają następujące ogólne konsekwencje dla controllingowe-go rachunku wyników:

• tzw. budżet kosztowy projektów wpłynie na krótko- i długookresowy wynik przedsiębiorstwa,
• zmiany wywołane projektem mogą wpłynąć na przychody i koszty w krótkim i długim okresie,
• cele stawiane wobec zarządzania płynnością finansową organizacji mogą istotnie wpłynąć na wartość projektu.

Powyższe stwierdzenie może wydać się banalne. Doświadczenie pokazuje, jak niewiele organizacji jest w stanie panować nad realizacją wszystkich tych trzech celów łącznie. System controllingu musi spełniać swoją rolę jako po-nadfunkcyjny instrument zarządzania. W organizacji klienta system ten musi dodatkowo współgrać z controllingiem procesów.

Perspektywa produkcji produktów

Obszar ten jest domeną controllera oraz kierowników projektów. W mysi zaleceń metodycznych, każda praca w projekcie powinna zakończyć się odbiorem produktu pracy. Produktem jest więc w zasadzie wszystko: dokument, dostawa, test, prezentacja itp. Fazy posiadają zwykle predefiniowany zestaw produktów zarządczych, stąd ich produkcja poddaje się standaryzacji. Niektóre produkty merytoryczne również (np. tzw. mały rozwój w IT) składają się ze standardowych komponentów analitycznych, konfiguracyjnych, programistycznych i testowych. Na tej podstawie można opracować system controllingu produkcji produktów.
Co ciekawe, controlling produkcji produktów projektów jest ponadprojektowy, ponieważ bazuje na obiektach mniejszych niż projekt. Jest to konieczne do standaryzacji zarządzania wieloma projektami, wykrywania związków pomiędzy projektami oraz przekrojowych analiz. 

UWAGA:Produkty projektu są podstawowym obiektem zarządzania - służą do alokowania zasobów, czasu i pieniędzy. Niezależnie od stopnia skomplikowania projektu, portfela projektów lub programu projektów nigdy nie wolno od tej zasady odejść. Można nie znać szczegółów produktów planowanych w odległym czasie, ale obowiązkowe jest utrzymanie spójnego planu (w tym budżetu) obejmującego cały projekt.

W controllingu produkcji produktów projektów rolą controllera jest utrzymanie wielu projektów w stanie przewidywalnym. Controlling pojedynczego projektu jest domeną kierownika projektu. Controłler powinien pomóc kierownikom identyfikować związek pomiędzy produktami różnych projektów. Służą temu metody port-felowego zarządzania projektami.

Tabela 1:

Programy projektów w myśl definicji według metodyki Managing Successful Programmes (utrzymywanej przez OGC) są złożeniem wielu projektów wraz z elementami procesowymi. W praktyce oznacza to utworzenie dedykowanej infrastruktury zarządzania na potrzeby realizacji wybranej strategii, zazwyczaj wieloletniej. Powołanie programu jest decyzją analogiczną, jak przy „zwykłym" projekcie - wybór takiej formy następuje wtedy, kiedy decydent uzna ją za najlepszą formułę zarządzania. 

Schemat 1:

Controlling produkcji w programie wymaga istnienia dedykowanego controllera. Zwykle rolę tę pełni biuro programu albo inne podobne ciało administracyjne. W myśl cytowanej niżej metodyki, rola taka określana jest jako dyrektor programu.
Co zatem powinien robić controłler zajmujący się w organizacji controllingiem produkcji produktów projektów? Przede wszystkim czynić wszystko, aby projekty i procesy koegzystowaiy w zgodzie ze sobą i były zoptymalizowane pod względem kosztów i nakładów.
W rękach controllera powinny być z jednej strony standardy planowania i raportowania, z drugiej strony - controłler powinien być dysponentem zasobów niezbędnych do produkcji wspólnych produktów dla wiełu projektów (decydent) oraz koordynować wykorzystanie wspólnych zasobów (doradca). W praktyce oznacza to, że controłler podejmuje decyzje o produkcji produktów infrastrukturalnych oraz wpływa jako doradca na decyzje o wykorzystaniu zasobów wspólnych (wpływa, więc nie decyduje samodzielnie). Umożliwia kierownikom projektu zawarcie kompromisu w zakresie takich zasobów albo przygotowuje swoją rekomendację dla decydentów wyższego szczebla.
Bardzo ważnym instrumentem controllera produkcji produktów projektu jest zarządzanie centralną rezerwą portfela projektów oraz podejmowanie decyzji o produkcji produktów wspólnych dla wielu projektów. Działania te są niezależne od polityk rezerw projektowych stosowanych przez komitety sterujące i kierowników projektów, jakkolwiek controller powinien otrzymywać informacje o stosowaniu takich polityk w projektach.
Polityka rezerw w produkcji produktów projektów jest jedną z istotnych różnic pomiędzy projektami i procesami. Uwzględnia zmienność i niepewność typową dla projektów. Bez aktywnego zarządzania rezerwami controlling projektów sprowadza się do administracyjnej kontroli, w praktyce silnie zwalczanej przez kierowników projektów.
Stąd w obszarze produkcji bardzo istotnym czynnikiem przesądzającym o jakości controllin-gu są interpersonalne, komunikacyjne umiejętności kierowników projektów i controllera. Same procedury nie wystarczają.

Perspekywa utrzymania wartości

Obszar ten jest domeną controllera oraz komitetów sterujących (albo sponsorów). W myśl zaleceń metodycznych, za sukces projektu odpowiada komitet sterujący. Skierowanie takich, a nie innych, produktów projektu do realizacji jest skutkiem wyboru, co jest najlepsze z punktu widzenia celów projektu. Kierownik projektu pełni w tym zakresie rolę doradcy; nigdy nie powinien pełnić roli decydenta.
Na wartość projektu składają się w uproszczeniu: koszty i nakłady produkcji produktów, korzyści wynikające ze stosowania produktów projektów po projekcie (okres eksploatacji), koszty utrzymania produktów w okresie eksploatacji, koszty rozwoju/zmian w procesach zmienionych poprzez projekt. Powyższe jest częścią tzw. business case i nie zawsze musi być wycenione finansowo.
Od controllera należy oczekiwać przede wszystkim umiejętności oszacowania budżetu projektu. Przy zastosowaniu finansowej wyceny projektu budżet ten należałoby określić mianem budżetu kapitałowego dokładnie tak, jak postępuje się przy analizie inwestycji. Controller sam z siebie nie będzie w stanie opracować takiego budżetu, bo nie jest członkiem zespołu projektowego i może nie rozumieć specyfiki projektu. Musi jednak być w stanie pokierować opracowaniem budżetu lub co najmniej doradzić wskazanej osobie z zespołu projektu, jak powinna taki budżet opracować.

Schemat 2:

Przy konsumenckiej postawie komitetu sterującego, budżet projektu zawiera tylko część kosztową/nakładową. W odróżnieniu od budżetów produkcji produktów, obowiązkowy jest preliminarz budżetowy dla utrzymania i rozwoju produktów. Bez takiej kalkulacji nie będzie możliwe rzetelne rozstrzyganie o oczekiwanej jakości produktów oraz świadomy wybór właściwej grupy produktów do realizacji.
Z wartością projektu wiążą się różnorodne standardy zatwierdzania projektów do realizacji. Dla przykładu, stosowanie kart projektów pozwala eliminować propozycje projektów źle przygotowanych, o ryzyku nieakceptowalnym przez organizację. Controller nie może jednak zastąpić decydentów, jest w stanie jedynie wspomóc proces podejmowania decyzji.

UWAGA: Typowe rezultaty pracy controllera w stadium kwalifikacji projektów to:

• wykrycie synergii pomiędzy proponowanymi projektami, co skutkuje połączeniem wielu projektów w jeden lub powołaniem programu projektów,
  
• wykrycie kanibalizmów korzyści, co skutkuje wstrzymaniem projektu „kanibala" albo rekonstrukcją istniejących portfela projektów,
  
• wykrycie innych związków pozwalających na zoptymalizowanie portfela.

Tak naprawdę nie istnieje jeden moment w czasie, kiedy projekty są zatwierdzane. Proces powoływania, realizacji i zamykania projektów jest ciągły dla wielu projektów równocześnie, jedynie z perspektywy pojedynczego projektu można mówić o tego rodzaju zamkniętych w czasie fazach (etapach). Tworzy to naturalny konflikt z typowym dla wielu organizacji budżetowaniem rocznym. Zbyt często i niepotrzebnie doprowadza to do konfliktu pomiędzy controllerem a komitetami sterującymi i kierownikami projektów.
W budżetowaniu rocznym biorą udział ci sa mi decydenci, którzy zasiadają w komitetach ste rujących. W związku z tym decydenci ci zawsze mają prawo do powołania projektu i stosują je w praktyce. Skutkiem tego są projekty powoły wane w trakcie roku poza oficjalnie istniejącym controłlingiem projektów, co długoterminowo może sprowadzić controlling do biurokratycznej instytucji kontroli wewnętrznej niedającej za uważalnych korzyści ani kierownikom projek tów, ani decydentom.
Rozwiązanie tego problemu jest proste: rocz ny preliminarz dla projektów oczekujących na zatwierdzenie (w tym takich, o których nikt jesz cze nie myślał, tworząc budżet roczny) i aktyw na rola controllera jako doradcy w procesie za twierdzania projektów. W tym miejscu znowu można powtórzyć: bardzo istotnym czynni kiem przesądzającym o jakości controllingu są interpersonalne, komunikacyjne umiejętności kierowników projektów i controllera. Same pro cedury nie wystarczają.

Zarządzanie wartością projektów w organizacji klienta odbywa się w 3 obszarach:

1. pojedynczych projektów, dla których warto stosować zaawansowane .narzędzia oceny projektu przed jego zatwierdzeniem - projekty takie tworzą łącznie podstawowy portfel projektów i są oceniane pojedynczo oraz w relacji z innymi projektami,
2. programy projektów, w ramach których projekty mogą podlegać odrębnym procedurom - zazwyczaj bardzo podobnie jak projekty poza programem, ale przede wszystkim z uwzględnieniem związku z celem programu,
3. mikroprojekty, dla których zarządzanie wartością odbywa się łącznie i dla których łączny budżet stanowi w praktyce część budżetu procesów modyfikowanych w trakcie roku obrotowego poprzezwspomniane mikroprojekty (tzw. mały rozwój).

Dodatkowo, zależnie od specyfiki organizacji, wymienione wyżej obszary mogą istnieć odrębnie w strukturze funkcjonalnej. Powszechnie spotykane są dedykowane obszary dla IT oraz badań i rozwoju. Centralny controlling projektów spinający całość warto stosować wtedy, kiedy większość pojedynczych projektów przekracza swoim zasięgiem jeden pion/dywizję.

Długoterminowe zarządzanie wynikiem

Abstrahując od użycia projektów jako instrumentu do zarządzania-finansami, budżet (kapitałowy) projektów w długim okresie znajdzie się w całości w rachunku wyników każdej organizacji. Budżety produkcji produktów projektu trafią tam wcześniej, jeśli będą opeksowe, albo później, jeśli będą capeksowe. Budżety kosztowe utrzymania i rozwoju znajdą się w rachunku wyników po projekcie i ważne jest, aby były co najmniej zgrubnie zaplanowane podczas kwalifikacji projektu do realizacji. Analogicznie ze zmianami przychodów.

Schemat 4:

Rezerwy controllingowe projektowe po pierwsze trzeba stosować. Po drugie, trzeba pamiętać, że przed ich rozwiązaniem do rachunku wyników powinna trafić wartość mniejsza niż suma wszystkich rezerw związanych z projektami. Ogólny schemat postępowania dla zestawu obiektów projektowych jest następujący:

• centralna rezerwa portfelowa powinna być traktowana jak oczekiwany koszt/nakład, dlatego opeksowa rezerwa znajdzie się w rachunku wyników w bieżącym roku, a capeksowa powinna być ujęta w planowanej amortyzacji produktów projektu w przyszłych okresach,
• centralna rezerwa programu projektów - j,w.,
• rezerwa portfela mikroprojektów - j.w.,
• rezerwy pojedynczych projektów - w wariancie opeksowym należy uwzględnić wartość oczekiwaną konsumpcji rezerw w bieżącym roku, w wariancie capeksowym wartość oczekiwana powinna być częścią planowanej amortyzacji w przyszłych okresach,
• rezerwy na zakup/wytorzenie produktów infrastrukturalnych wspólnych dla projektów i procesów, skutkujące skokowym wzrostem kosztów lub wydatków, należy uwzględnić w całości, tak jak centralną rezerwę portfelowa.

Z powyższego wynika, że controller powinien mieć metodę wyznaczenia wartości oczekiwanej konsumpcji rezerw przez pojedyncze projekty. Zwłaszcza, że wśród ogółu pozycji rezerwowych te właśnie mają największą łączną wartość. Konstrukcja odpowiedniego modelu ekonometrycz-nego to temat na osobne opracowanie.
Na koniec warto podkreślić, iż nie ma gotowych zaleceń w sprawie utrzymywania odrębnej części rachunku wyników dla projektów. Jedno jest jednak pewne: w organizacji posiadającej projekty koniecznie trzeba stosować projektowe obiekty controllingowe i używać ich w controllin-gu operacyjnym do podobnych celów jak inne obiekty, takie jak centra zysków, MPK itp.

Źródło:gamma-consulting.pl