Strefa Wiedzy
Strategy & Business

Uzasadnienie biznesowe w projektach i programach – czy naprawdę jest potrzebne?

Fot. Fotolia.com

Temat uzasadnienia biznesowego w pro­jektach jest od dłuższego czasu modny. Firmy oczekują od kierownika projektu biznesowych efektów ze zrealizowanych produktów projektu, a według modelu kompetencji opublikowanego w zeszłym roku przez PMI®, kierownik projektu ma znać się na organizacji, uzasadnieniu biz­nesowym i rozumieć biznes firmy.


Rozbudowana została również sekcja uza­sadnienia biznesowego w PMBOK® Guide! W szóstej wersji standardu pojawiły się do­kumenty biznesowe: uzasadnienie bizne­sowe i plan realizacji korzyści, które mają stanowić podstawę pomiaru sukcesu oraz postępu przez cały cykl życia projektu. Ma być to realizowane poprzez porównanie wyników projektu z celami oraz określonymi w uzasadnieniu biznesowym kryteriami sukcesu.

Praktyka pokazuje, że kierownik projektu jest tak pochłonięty operacyjną działalno­ścią w projekcie, że „nie ma czasu” na uza­sadnienie biznesowe. Dyrektor przychodzi z konkretnym rozwiązaniem, które trzeba wdrożyć i oczekuje realizacji na jutro. Czy w megaprojektach jest lepiej? Chyba nie, bo budując blok energetyczny kierownik pro­jektu wie, jakie parametry wydajności musi spełnić „produkt projektu”, a nie dlaczego inwestor zdecydował się na taką inwesty­cję i po ilu latach ma się zwrócić. To może programy? Niestety w większości sytuacji odpowiedź jest prosta: „koordynujemy wiele projektów, które prowadzącą do tego same­go celu”. A jaki to cel? „Digitalizacja Banku”. A jakie korzyści z tego są? „Będziemy bardziej nowocześni i innowacyjni, a poza tym wszyscy to robią i nie możemy odstawać”. Takie odpowiedzi pokazują, że de facto nie znamy uzasadnienia biznesowego progra­mu. Jak do tego dodamy jeszcze aspekt po­lityczny, ukryte prawdziwe cele projektu/programu to rekomendacja wydaję się jasna: kierowniku projektu, jak najdalej od uza­sadnienia biznesowego!

Stosowania uzasadnienia biznesowego nie ułatwia również fakt, że jest to temat trudny do zmierzenia. Wiele osób uważa, że nie da się przygotować dobrego uzasadnie­nia biznesowego, bo przy tak zmieniającym się rynku, liczenie czegoś na 2-5 lat w przód nie ma sensu, a poza tym jest tyle czynni­ków wpływających na rzeczywiste efekty, że udowodnienie później, że to sam projekt przyniósł te korzyści nie będzie możliwe. Tylko jeżeli nie przyjmiemy założeń, to nigdy nie będziemy w stanie wyciągnąć wniosków. Zachęcam do przedstawienia uzasadnie­nia biznesowego w wymiarze finansowym, nieważne ile założeń musicie przyjąć po drodze.

Zobaczmy przykład sytuacji z jednej fir­my: dział HR przyszedł do Zarządu z prośbą o uruchomienie projektu poprawy satysfak­cji pracowników. Na pytanie jakie korzyści osiągnie organizacja, Zarząd usłyszał, że w badaniu satysfakcji wyjdzie lepszy wynik punktowy. Kiedy Zarząd odrzucił projekt, w końcu przeanalizowano uzasadnienie biz­nesowe i wrócono do Zarządu z informacją, że dział HR chce zmniejszyć rotację w firmie. Kiedy przedstawiono koszt 1% rotacji pra­cowników (koszty firmy rekrutacyjnej, szko­lenia, czas nauki nowej osoby, itp.), to wtedy bez problemu Zarząd uruchomił projekt, ale również bez problemu go zamknął, kiedy przy niekorzystnej sytuacji na rynku pracy, ludzie przestali zmieniać pracę i nie trzeba było walczyć już o rotację!

Uzasadnienie biznesowe ułatwia życie obu stronom, Sponsorowi – który próbu­je uzyskać zgodę na realizację projektu, ale również Zarządowi, który dzięki uza­sadnieniu jest w stanie dokładniej ocenić zgłoszony temat.

Czy przypadkiem pominąłem kierownika projektu w poprzednim akapicie? Przecież w praktyce to kierownik projektu idzie na Zarząd z wnioskiem o uruchomienie projek­tu! Postawmy się w roli Sponsora projektu i odpowiedzmy sobie na pytanie, czy chce­my, aby nasz projekt prowadził efektyw­ny organizator, który zaplanuje i dowiezie prace w projekcie, czy ekspert od rynku, branży i biznesu, który prowadzimy? Naj­lepiej oczywiście obu, ale jeżeli mielibyśmy wybrać? Wiele organizacji zwiększa swoje oczekiwania w stosunku do kierownika pro­jektu i oczekuje od niego również zajęcia się aspektami uzasadnienia biznesowego, kreując kierownika projektu na menedżera ds. rozwoju biznesu. Jest to bardzo wygodne podejście (szczególnie dla Sponsorów, Wła­ścicieli Departamentów czy Właścicieli Pro­duktów), ale czy rzeczywiście chcemy zdjąć tę odpowiedzialność z innych ról i oczeki­wać jej od kierownika projektu? Do projek­tów potrzebujemy efektywnego organiza­tora! Oczywiście takiego, który rozumie uzasadnienie biznesowe realizowanego przedsięwzięcia.

A co z poziomem programu? Przecież kie­rownik programu musi zarządzać korzyścia­mi, aby zrealizować i móc zamknąć program. Jeżeli popatrzymy na wiele przykładów, oczywiste staje się, że kierownik programu monitoruje korzyści, ale nie powinien two­rzyć i odpowiadać za uzasadnienie bizneso­we w programie. Kierownik musi oczywiście rozumieć jak uzasadnienie biznesowe prze­kłada się na cele szczegółowe dla programu, jak one wiążą się z produktami i korzyściami, które projekty w ramach programu dowiozą.

Wróćmy na chwilę do nowej wersji stan­dardu PMBOK® Guide. Tak jak napisałem na początku, dokumenty biznesowe pojawiły się w standardzie, ale… cały czas stanowią one wejście do procesu przygotowania karty projektu i nie zarządza nimi kierownik pro­jektu! I bardzo dobrze, zostawmy „sponso­rowi co sponsorskie”.

Fot. Fotolia.com

Jaka jest w takim razie rola kierownika projektu w zakresie odpowiedzialności za uzasadnienie biznesowe: „Kierownik projek­tu jest odpowiedzialny za zapewnienie reko­mendacji oraz dopilnowanie, by uzasadnienie biznesowe, plan zarządzania projektem, kar­ta projektu i metryki sukcesu zawarte w pla­nie zarządzania korzyściami projektu były w pełni zsynchronizowane ze sobą oraz z za­mierzeniami i celami organizacji.”1

Czy w takim razie kierownik projektu nie powinien się zajmować uzasadnieniem biz­nesowym? Oczywiście, że powinien. Kierownik projektu musi zrozumieć, że bez uzasad­nienia biznesowego jego projekt kompletnie traci sens i rację bytu. Oczywiście rola kie­rownika projektu nadal polega na efektyw­nym organizowaniu i prowadzeniu projektu oraz przewodzeniu ludziom, ale realizacja tej roli musi odbywać się w ramach uzasadnie­nia biznesowego. Uzasadnienie biznesowe nadaje tym działaniom kierownika projektu sens i wartość. Bez wiedzy o uzasadnie­niu biznesowym kierownik projektu nie ma żadnego wpływu na to, co najważniejsze dla organizacji, a organizacja traci bezcenne źródło rekomendacji i informacji dotyczą­cych rzeczywistości widzianej z perspekty­wy operacyjnego zarządzania projektem. Bez wiedzy o uzasadnieniu biznesowym kierow­nik projektu nie będzie miał świadomości, co jest naprawdę ważne, jakie ryzyka są najbar­dziej kluczowe z punktu widzenia sukcesu projektu, a w skrajnej sytuacji może wręcz szkodzić organizacji, bo oczywiście będzie za wszelką cenę starał się zmieścić w budżecie i harmonogramie i w tym celu może podej­mować decyzje, które z biznesowego punktu widzenia będą niszczyły wartość powstającą w projekcie. Wiedza o uzasadnieniu bizneso­wym i jego zrozumienie są tak samo ważne jak organizowanie i prowadzenie projektu, czy przywództwo.

Pamiętajmy: kierownik projektu czy kierownik programu nie są odpowiedzial­ni za uzasadnienie biznesowe, ale muszą je znać, rozumieć i traktować jako naj­wyższą wyrocznię, bo to ona definiuje na czym polega ich sukces.

Jest to tym bardziej ważne, że w praktyce i tak będą musieli je przygotować.


1 PMBOK® Guide, Sixth edition

Strefa Wiedzy
Strategy & Business

Projekt czy Produkt? Oto jest pytanie!

Fot. Costello77 - stock.adobe.com

Pracowałem przez ostatnie 11 lat z najróżniejszymi firmami, od malutkich software house’ów, poprzez korporacje, aż po ministerstwa. Niestety w większości przypadków spotykam się z charakterystycznym problemem, nazywam go syndromem myślenia projektowego. Jest to przeciwieństwo do jak najbardziej pożądanego myślenia produktowego.


Zanim wytłumaczę, na czym polegają oba podejścia oraz przedstawię kilka często spotykanych antywzorców, najpierw usystematyzuję kilka ważnych pojęć. Jak to podobno mawiał Konfucjusz: „Naprawę państwa należy zacząć od naprawy pojęć”.

Projekt to tymczasowe przedsięwzięcie. Jego rezultatem jest unikatowy produkt, usługa lub rezultat. Tymczasowość to nic innego jak początek i koniec. Sukces projektu często jest definiowany przez trzy parametry: zakres, budżet i czas. Te trzy zmienne często są nazywane żelaznym albo magicznym trójkątem projektowym. Mamy projekty technologiczne, infrastrukturalne, budowlane, finansowe, medyczne, organizacyjne, typowo biznesowe. Przykładem projektu było też napisanie artykułu, który właśnie czytasz.

Produkt natomiast to coś, co spełnia potrzeby i oczekiwania użytkowników. Coś, co dostarcza im wartość. Mamy produkty fizyczne takie jak: krzesła, samochody czy kiełbasy. Mamy też produkty cyfrowe takie jak: Youtube, Power Point czy Nasza Klasa. Usługa też może być produktem, na przykład produktami, które ja dostarczam na rynek są szkolenia ze Scruma i Kanbana, ale również usługi konsultacyjne.

Skoro już ustaliliśmy (przynajmniej w teorii), czym się różni projekt od produktu to pojawia się zasadnicze pytanie, kto to jest: Project Manager oraz Product Owner. Każda z tych ról ponosi inną odpowiedzialność i wykonuje inną pracę.

Project Manager odpowiada za sukces projektu, czyli umowne dowiezienie produktu w budżecie i na czas. Produkt Owner odpowiada za to, aby został stworzony właściwy produkt. Taki, który odniesie sukces na rynku i taki, który będzie dostarczał maksymalnie dużo wartości. Amerykanie często o Product Ownerze mówią Value Maximizer.

Kiedyś mój klient z jednego z ministerstw nie potrafił zrozumieć, jaka jest różnica pomiędzy Project Managerem a Product Ownerem. Powiedziałem mu wtedy, że Project Manager nie może spać po nocach, bo nie uda mu się zrealizować zakresu w określonym budżecie lub na czas. Natomiast Product Owner nie może spać po nocach, bo Pani Krysia z urzędu skarbowego nie będzie potrafiła za pomocą aplikacji szybko i efektywnie wykonać swojej pracy. Obie te role skupiają się na czymś bardzo różnym. Co ważne, interesy tych dwóch ról zawsze po- winny być spójne, ale niestety rzeczywistość pokazuje, że czasami są sprzeczne, a to już równia pochyła do klęski!

Samo myślenie projektowe nie jest niczym złym. Jednak, jeżeli ktoś zaczyna myśleć tylko o projekcie, a zapomina o produkcie to mamy do czynienia z czymś, co nazywam syndromem myślenia projektowego. Najprawdopodobniej nic wartościowego z takiego podejścia nie powstanie. Coś na zasadzie „operacja się udała, ale pacjent zmarł”. Dowieźliśmy co prawda na czas, w zakresie i budżecie (sukces!), tylko nikomu niepotrzebny produkt. Widziałem to dziesiątki razy, za każdym razem smuci mnie to tak samo. Syndrom myślenia projektowego przybiera różne postaci, warto je poznać, aby skutecznie im zapobiegać.

1. Prędkość ponad wartość biznesową

…szybko i dużo, ale niewłaściwych rzeczy. Ten antywzorzec najczęściej widzę w korporacyjnych implementacjach Scruma. Chodzi o mierzenie prędkości zespołu (zwanej najczęściej velocity), czyli ilości zrealizowanej pracy (np. User Story) przy jednoczesnym małym skupieniu uwagi, na tym jaka wartość biznesowa jest dostarczana. Przykładowo jeden Product Owner którego zapytałem: „Po czym poznasz sukces Waszego produktu?”, odpowiedział „Jak to po czym? Po ilości Story Pointów na Sprint”. Bez odpowiedniej wizji biznesowej i świadomości biznesowej większość tworzonych funkcjonalności równie dobrze mogłaby w ogóle nie powstać.

 „Szybkość jest najważniejsza, jeżeli poruszamy się we właściwym kierunku” 
 David J. Anderson 

2. Zakres wyryty w kamieniu

Kiedyś jednemu Project Managerowi powiedziałem, że zaproponowane zmiany w zakresie są dobre dla produktu. Odpowiedział: „Może i są dobre dla produktu, ale nie są dobre dla harmonogramu”. To sztywne trzymanie się ustalonego początkowo zakresu. Nawet, jeżeli widać, że rzeczywistość się mocno zmieniła, że potrzeby, które ma realizować produkt uległy zmianie. Pomimo tego, że widzimy, że to, co robimy jest średnio sensowne, dokończymy, bo tak jest w harmonogramie!

3. Predykcja zamiast empiryzmu

Predykcja to przewidywanie przyszłości na podstawie teraźniejszej wiedzy. Predykcyjne tworzenie produktów oznacza zebranie wszystkich wymagań na początku projektu bez ich weryfikacji w trakcie. Jednak użytkownicy produktów to ludzie. Ludzie są trudno przewidywalni, a ich potrzeby zmieniają się w czasie. Projekt oparty o predykcję, który powstaje przez 3 lata, co najwyżej zrealizuje potrzeby użytkowników sprzed 3 lat!

Aby stworzyć produkt, który podbije rynek, nie wystarczy porządna faza specyfikacji wymagań. Wszystko, co myślimy o potrzebach naszych użytkowników i sposobach na ich realizację należy traktować jako hipotezy. Bez częstych pętli zwrotnych i empirycznego potwierdzenia tych biznesowych hipotez, istnieje ogromne ryzyko, że stworzymy produkt o małej wartości rynkowej.

Przykładem „biznesowych” pętli zwrotnych mogą być, np. badania User Experience, szybkie prototypowanie oraz częste wywiady z użytkownikami. Warto też wspomnieć scrumowe Sprint Review – jest to spotkanie, na którym kolejna wersja inkrementu produktu jest poddawana inspekcji ze strony interesariuszy, po czym następuje adaptacja wymagań.

Pamiętajmy jednak, że ostateczną weryfikacją czy nasz produkt dostarcza wartość jest wydanie produktu na rynek – warto zrobić to jak najwcześniej.

4. „Klepnęli nam to niech się martwią”

Kiedyś „sprzątałem” w projekcie, którego efektem miał być produkt – aplikacja dla graczy futbolu amerykańskiego. Klient, który zamówił produkt w software house mocno się zwiódł efektem końcowym. Okazało się, że aplikacja jest niezgodna z zasadami futbolu amerykańskiego! To, co powstało miało zerową wartość biznesową. Na to Project Manager z rozbrajającą szczerością powiedział: „Przecież nie jest napisane w kontrakcie, że ta aplikacja ma być zgodna z zasadami tej gry”.

Tego typu podejście bardzo często widać w zamówieniach publicznych. To zabawne dopóki nie uświadomimy sobie, że jest to finansowane z naszych podatków!.

5. Procedury organizacyjne ponad wartość biznesową

Najgorsze, co może spotkać człowieka zmiany to procedury. Nawet największego wizjonera może sprowadzić na ziemię dowód audytowy. Oczywiście procedury mogą być bardzo pożyteczne: standaryzują procesy, pomagają podjąć następne kroki, zapewniają zgodność. Jednak, jeśli stawiamy je ponad produkt, wartość i zdrowy rozsądek, mamy problem i kolejny antywzorzec.

Warto tworzyć procedury jak „najlżejsze” i często je weryfikować. To, co 5 lat temu dostarczało wartość teraz już może być tylko „tłuszczykiem procesowym” – należy to usunąć. Często też u moich klientów zauważam, że liczne i uciążliwe procedury są wynikiem małego zaufania do pracowników. Niestety często zamiast pochylić się nad prawdziwym problemem jest tendencja do… dodawania kolejnych procedur.

Pamiętajcie, że dobrego Project Managera czy dobrego Product Ownera poznamy po owocach ich pracy. Bez wątpienia owocem ich pracy zawsze jest produkt! Taki, który spełnia lub nie spełnia potrzeb i oczekiwań użytkowników.

Apeluję do wszystkich zostańcie produktowcami! Dostarczajcie wartość! Natomiast zakres, czas i budżet traktujcie jak drogę do celu.