Cel i wartość projektu

Marek Rafałowicz · 24/01/2007 · Link

Czyli o tym, dlaczego czasem nie wiadomo czemu ma projekt służyć, jakie będą z niego korzyści i po co w ogóle go realizujemy.

To fajny projekt jest!

Jeden z moich znajomych opowiedział mi historię o pewnej firmie. Otóż była ona od strony IT jedną z najlepiej zorganizowanych w swojej branży, uruchomiono w niej bowiem - za gigantyczną sumę pieniędzy - wszelkie systemy informatyczne, jakie tego rodzaju firma mogłaby potrzebować. W opinii pracujących tam osób decyzje o uruchamianiu tych projektów nie zawsze były w pełni uzasadnione. Często podejmowano je pod hasłem - to będzie fajny projekt, inni to mają, ruszajmy!

Taka strategia oczywiście była nieracjonalna z biznesowego punktu widzenia (choć może optymalna dla części pracowników, którzy mieli szansę nauczyć się fajnych rzeczy!). Mimo tego, że zasadniczo projekty kończyły się sukcesem, to koszty ponoszone na rozwój nie równoważyły się z korzyściami aż w końcu firma ta otarła się o bankructwo. Udało jej się przetrwać ciężki okres, ale straciła bezpowrotnie pewną szansę i cofnęła się w wyścigu z konkurentami o kilka długości.

Jeśli pracujecie w małych, dobrze zarządzanych firmach, to takie sytuacje mogą Wam się wydawać nieprawdopodobne (chyba, że duże firmy są Waszymi klientami), ale niestety w większych organizacjach zdarzają się dość często.

Warto przy tym zauważyć, że we wspomnianej firmie poświęcano sporo uwagi "optymalizacji" działania. Polegało to na tworzeniu "ambitnych" harmonogramów, "motywowaniu" pracowników, "wyciskaniu" dostawców, by było taniej, by wcześniej uwolnić ludzi do innych prac, by szybciej zamknąć projekt. Nie przyjmowano do wiadomości, że największe oszczędności kryją się w szybkim anulowaniu kiepskich projektów a nie w optymalizowaniu ich realizacji . Nie istnieje żaden sposób istotnego przyśpieszenia prac intelektualnych i twórczych - a takimi są analiza, projektowanie i programowanie systemów - poza jednym: unikaniem bezsensownego marnowania pracy i czasu.

Jak to się stało?

Gdzie dokładnie popełniono błąd? Jak to się stało, że w organizacji, w której pracowali mądrzy, wykształceni ludzie, pozwolono na realizację tych nietrafionych projektów?

Spójrzmy, jak scenariusz inicjacji "projektu" wygląda w mniejszej skali. Załóżmy, że jesteś osobiście skonfrontowanym z jakimś problemem i próbujesz go rozwiązać. Najpierw zapewne jasno definiujesz problem (np. "wyjeżdżam do kraju, którego języka nie znam, nie będę się mógł porozumiewać"). Następnie wyszukujesz przeróżnych, potencjalnych rozwiązań problemu (szybki kurs, tłumacz elektroniczny, słownik i kartka papieru, zabranie ze sobą kogoś znającego język etc.).

Następnie rozważasz różne opcje oglądając je zapewne z dwóch stron:

• czy dana metoda rozwiąże problem i jak skutecznie (np. szybciej i wygodniej mieć do pomocy kogoś kto szybko przetłumaczy niż korzystać z kartki i słownika)?
• czy metoda jest w ogóle realna i jaki jest jej koszt (czas i wysiłek - koszt zabrania drugiej osoby, czas potrzebny na kurs etc.)

Tak czy owak cały czas masz przed oczami cel i każdy rozważany "projekt" jest ściśle ewaluowany zarówno pod kątem kosztów jak i skuteczności osiągnięcia celu. Nie pchasz się w takie rozwiązania, w których spodziewane korzyści nie przeważają nad przewidywanymi kosztami.

To brzmi naturalnie, dlaczego nie działa więc w większej skali? W wielu przypadkach przy podejmowaniu decyzji o starcie projektu brane są pod uwagę nie tylko korzyści dla biznesu firmy i koszty realizacji. Ludzie kierują się wszak różnymi przesłankami przy podejmowaniu decyzji:

• mogą być przekonani, że projekt należy zrealizować, bo widzieli, że sprawdziło się to gdzie indziej (choć mogło to być w całkiem innej sytuacji biznesowej),
• mają swój interes w jego realizacji (liczą na kierownicze stanowisko, prestiż, ciekawe doświadczenie),
• podejmują decyzję na wyczucie, kierując się intuicją,
• kierują się wcześniej ustalonymi planami firmy, które już się zdążyły zdezaktualizować,
• projekt zarekomendował ktoś ważny i nikt nie ma odwagi go zakwestionować

W prostszych sytuacjach, w mniejszych grupach ludzi i przy bardziej namacalnych problemach, sytuacja w której dochodzi do realizacji nieopłacalnego projektu zdarza się rzadziej, bo:

• proces decyzyjny jest bardziej czytelny,
• jawniej przypisana jest odpowiedzialność,
• problem do rozwiązania jest bardziej oczywisty (spróbuj szybko podać precyzyjną odpowiedź jaki problem był rozwiązywany gdy wdrażano "Błękitną Linię"? System informatyczny w ZUS? ...)

Cel uświęca środki

Co można jednak zrobić w dużej organizacji i przy większych projektach, by zwiększyć szanse na to, by o realizacji projektu (lub dowolnego jego fragmentu) decydowały racjonalne przesłanki?

Po pierwsze każdy projekt powinien mieć jasno określony cel. Dobry cel powinien być:

• biznesowy (a więc nie jest dobrym celem "wdrożenie systemu SAP", bo to samo w sobie żaden biznes),
• konkretny (a więc nie "usprawnienie działalności firmy" tylko "skrócenie czasu poświęcanego na inwentaryzację sklepu"),
• mierzalny ("z dwóch dni do jednego"),
• dający się przełożyć na finansowe korzyści w określonym okresie ("co da około 400.000 zł dodatkowego przychodu w najbliższych trzech latach)
• jasny, zrozumiały, uzgodniony i zaakceptowany przez wszystkich uczestników projektu,
• zapisany jako założenie do projektu (zwykle jest podstawą dokumentu określającego wizję projektu)

Większe projekty mają zwykle wiele celów biznesowych - na wstępnym etapie warto od razu uzgodnić z udziałowcami projektu jakie są ich względne priorytety. Bardzo ułatwi to dalsze działanie w projekcie.

Jasny cel jest nie tylko wkładem do podjęcia decyzji o starcie projektu. Stanowi też jasne kryterium dla podejmowania wszystkich bardziej szczegółowych decyzji w jego trakcie (np. "czy ten dodatkowy moduł jest nam niezbędny by skrócić czas potrzebny na inwentaryzację do jednego dnia?").

Powiedz mi o co ci w ogóle chodzi

W tym miejscu warto wspomnieć o tym, że wyartykułowanie celu wcale nie jest takie proste. Klient - zewnętrzny lub wewnętrzny - zamawiający projekt często popełnia skrót myślowy i prezentuje od razu propozycję rozwiązania ("potrzebujemy możliwości generowania raportu z następującymi kolumnami..."). Podejrzewam, że dla wielu ludzi przedstawienie konkretnej propozycji rozwiązania jest prostsze od sformułowania problemu, a może wynika to z tego, że większość ludzi odruchowo szuka rozwiązania i przywiązuje się do niego, bo to ich jedyny słuszny pomysł?

Niezależnie od przyczyny nie zwalnia to wykonawcy od obowiązku dotarcia do sedna problemu. To jego obowiązek wypytać i upewnić się, że dobrze go rozumie a następnie zaproponować możliwe rozwiązania. Wymaga to pewnej dyscypliny i asertywności, czasem też pewnych zdolności politycznych, ale warto. Wykonawca zwykle dysponuje znacznie większą wiedzą o różnych aspektach technicznych od zamawiającego i często ma doświadczenie w podobnych projektach wykonywanych np. dla innych klientów, stąd ma zwykle większe szanse na zaproponowanie optymalnego rozwiązania.

Plusy i minusy

Drugą sprawą jest wymuszenie, by spodziewane korzyści z wdrożenia systemu były porównywane z kosztami przed podjęciem kluczowych decyzji o projekcie, a w szczególności by stanowiły podstawę decyzji czy w ogóle warto dany projekt realizować.

Doprowadza nas to do ciekawej skądinąd refleksji, że od kierowników projektów często wymaga się dokładnego oszacowania kosztów projektu i rozlicza się ich z realizacji projektu w budżecie, natomiast strona korzyści, nawet jeśli nie jest w ogóle pomijana, to traktowana jest bardzo oględnie. Prowadzi to do absurdalnej sytuacji: przykładowy bilans projektu prezentowany jest następująco:

- 255.585 EUR

+ wielu nowych klientów

---------------------

?

By rzetelnie ocenić "wartość netto", korzyści powinny być oszacowane z podobną dokładnością jak koszty projektu. Skądinąd warto zauważyć, że podawanie dokładnych kwot czy dat niekoniecznie ma sens, bo zwykle niedokładność oszacowania jest i tak spora (chyba, że posługujemy się górną granicą z założonym sporym buforem).

Zarówno strona kosztów jak i zysków jest obarczona ryzykami, które warto na tym etapie uwzględnić - co wymaga oszacowania ich prawdopodobieństwa i oczekiwanej wartości (np. jeśli mamy ok. 50% szans na dodatkowe 50.000 zysku -> doliczamy 25.000 do oczekiwanych korzyści).

Jeżeli firma zarządza portfelem projektów, to oczekiwana wartość projektu jest dobrą, zobiektywizowaną podstawą do określania względnych priorytetów tych przedsięwzięć. Najpierw warto wysiłek i fundusze kierować tam, gdzie mamy szanse na największe korzyści.

Should I stay or should I go now?

Po trzecie kultura organizacji musi pozwalać na wycofanie się z projektu już po zainwestowaniu w niego pewnego wysiłku. Wspomnianej analizy nie da się wykonać od ręki. Konieczne jest uzgodnienie wspólnego celu (to jedno może w organizacji być nie lada wyzwaniem), oszacowanie zysków, wytypowanie możliwych rozwiązań i oszacowanie ich kosztów, uwzględnienie ryzyk. Często oznacza to pracę z podwykonawcami, oferentami, stworzenie sterty dokumentów, odbycie wielu spotkań. Osoby zaangażowane w taki proces mogą w naturalny sposób bronić się przed utratą ich wysiłku.

Porzucenie projektu może wymagać odwagi, bo decyzja taka, może stać w sprzeczności z interesami wielu osób. Decyzja taka jest mocno "eksponowana" a przez to narażona na publiczną krytykę, zwłaszcza jeśli organizacja nie jest przyzwyczajona do takich sytuacji. Osoby będące najbliżej projektu - analitycy, wykonawcy, kierownicy mogą obawiać się bycia posądzonym o nieskuteczność, nie wspominając o tym, że mogą utracić ciekawe zajęcie.

Powszechna w dużych firmach procedura konstruowania i realizacji budżetów może utrudniać podjęcie wspomnianej decyzji. W dużych firmach budżety planowane są najczęściej na cały rok. Wdrożenie dużego projektu, jako spora inwestycja, musi być w takim budżecie ujęta. Zwykle jest wpisywana do niego w okolicach grudnia poprzedzającego roku i na tym etapie wysiłek idzie najczęściej na przygotowanie marketingowych prezentacji dla zarządu a nie na rzetelną ewaluację korzyści.

Po zaakceptowaniu budżetu nikt już nie ma żadnej motywacji, by wyrzec się ciężko wywalczonych pieniędzy. Zwłaszcza, że niewykorzystane pieniądze trzeba będzie zwrócić a kolejny budżet zostanie odpowiednio pomniejszany.

Dlatego właśnie w wielu metodykach ocena korzyści jest formalnym obowiązkiem. Dla przykładu sercem metodyki Price II jest "business case" - uzasadnienie zasadności projektu, zawierające korzyści, koszta i ryzyka. To uzasadnienie jest reewaluowane przez cały czas trwania projektu, by wymuszać podejmowanie decyzji - niezależnie od tego ile sił już na projekt poświęcono, czy warto go dalej kontynuować.

Trafiliśmy?

Cel powinien być przed oczami uczestników przez cały czas trwania projektu, jak kompas pokazujący drogę. Cel może się w trakcie zmieniać, bo mogą się pojawiać nowe szanse lub nowe uwarunkowania; może też przestać być zasadny. Im wcześniej będziemy o tym wiedzieć, tym lepiej, bo pozwoli to podjąć działania korekcyjne.

Koniec projektu to moment, w którym warto poświęcić wysiłek na przyjrzenie się inicjalnym założeniom, planom, spodziewanym rezultatom i porównać je z rzeczywistymi wynikami. Samo zakończenie "w czasie i przy założonym budżecie" nie jest jednoznacznym wskaźnikiem sukcesu, a tylko jednej jego strony. Jeśli projekt przyniósł mniej niż zakładaliśmy, to warto przeanalizować dlaczego, będzie to niebagatelna lekcja na przyszłość. Jeśli więcej niż się spodziewaliśmy - to powód do celebrowania zwycięstwa.

Więcej na ten temat

• Business case - Wikipedia - uzasadnienie istnienia projektu
• Improving the Prioritization Process, Project Evaluation Metrics - o priorytetach i wartości projektu w kontekście zarządzania portfelem projektów

---