Od pewnego czasu obserwuję toczącą się dyskusję – zwłaszcza w świecie szeroko rozumianego IT, choć oczywiście nie tylko - nt. projekt i zarządzanie projektem versus produkt i zarządzanie produktem. Czasem w tej dyskusji padają głosy dość ekstremalne typu: zarządzanie projektem to dawne czasy, należy zrezygnować z zarządzania projektami, itp.

Jesteście ciekawi, jakie jest moje zdanie na ten temat? Przeczytajcie poniższy tekst.

Po pierwsze – jak najczęściej bywa – zagadnienie nie jest zero-jedynkowe, gdyż pytanie: projekt czy produkt jest – moim zdaniem - niewłaściwym pytaniem. Do głębszych i w dodatku praktycznych wniosków dojdziemy zadając inne pytania: w jakiej sytuacji i dlaczego warto stosować podejście projektowe, a w jakiej sytuacji i dlaczego podejście produktowe?

A ta sytuacja opisana może być – moim zdaniem – przede wszystkim poprzez cechy charakterystyczne rezultatu pracy, który chcemy otrzymać i którego procesem wytwarzania chcemy zarządzać. W świecie biznesu powiązanego z IT mamy bowiem do czynienia z produktami cyfrowymi, takimi jak mniejsze lub większe aplikacje oraz systemy informatyczne wspomagające funkcjonowanie samego biznesu, klientów, jak i samego IT. Cechy charakterystyczne tych produktów to m.in.

• Duży stopień innowacyjności produktu, złożoność problemu adresowanego przez produkt i brak jego wcześniejszych rozwiązań
• Niemożność zdefiniowania up-front szczegółowych wymagań użytkownika
• Możliwość pojawiania się zmodyfikowanych lub wręcz nowych wymagań w trakcie tworzenia produktu, a tym samym modyfikacji kursu prac
• Konieczność całościowego patrzenia na pełen cykl życia produktu od jego idei poprzez cały jego cykl życia aż do wycofania, w dodatku: najlepiej przez ten sam stały zespół autorów produktu
• Bardzo silna koncentracja na wartości biznesowej, tworzonej przez działania całościowego strumienia wartości (ang.value stream), jaką uzyskuje klient/użytkownik aplikacji, systemu i ich poszczególnych funkcji
• Modularność umożliwiająca użytkownikowi korzystanie z poszczególnych modułów produktu
• Dopuszczalność popełniania błędów podczas inkrementalnego dostarczania produktu, gdyż stanowią one cenną naukę i – z drugiej strony – nie przynoszą katastrofalnych skutków
• Możliwość i wręcz celowość częstej informacji zwrotnej od odbiorcy (użytkownika) podczas tworzenia produktu.

Klasyczne zarządzanie projektami

To teraz porównajmy powyższe charakterystyki z definicją i charakterystykami projektu oraz praktykami klasycznego zarządzania projektami. Na początek definicja projektu wg PMBOK® Guide:

• Projekt jest ograniczonym czasowo działaniem realizowanym w celu stworzenia unikalnego produktu lub usługi lub rezultatu

podkreślająca ten ustalony i ograniczony czasowo czas trwania projektu.

I jeszcze spójrzmy na listę praktyk klasycznego zarządzania projektem:

• Tworzenie zespołu projektowego dla konkretnego projektu, na określony czas i rozwiązywanego po zakończeniu projektu
• Tworzenie budżetu dla całego projektu już na jego początku
• Dążenie do trzymania się ustalonego na początku zakresu produktów projektu i możliwie maksymalne ograniczanie wprowadzania zmian poprzez mechanizmy kontroli zmian
• Koncentracja na zarządzaniu kosztami (ang. cost management), przy jednoczesnym pomijaniu zarządzania korzyściami (ang. benefits management).

Dwa światy

Widać dwa różne światy i dwa różne podejścia. Dla mnie konkluzja jest prosta: praktyki klasycznego zarządzania projektem po prostu nie wpasowują się w cechy charakterystyczne produktów cyfrowych, opisane wcześniej. Nie będą umożliwiać realizacji celów, jak i podejścia niezbędnego przy produktach cyfrowych, bo są po prostu „z zupełnie innej bajki”.

Czy ta konkluzja oznacza, że klasyczne zarządzanie projektem powinno odejść do lamusa? Tego nie powiedziałem i … nie powiem.

Dlaczego? Proste: jeśli znajdziemy takie produkty i dotyczące ich wytworzenia podejścia, których realizację i stworzenie oraz osiągnięcie związanych z nimi celów mogą być wspierane przez praktyki klasycznego zarządzania projektami, jak na przykład te wymienione powyżej, to oczywiście stosujmy to klasyczne podejście.

A jakie mogą to być przedsięwzięcia? Takie choćby jak: różnego typu projekty usprawnieniowe, projekty dostarczające produkty o niewielkiej nieprzewidywalności, czy też produkty dla których możliwe jest zdefiniowanie na początku przedsięwzięcia niemal stałego zbioru wymagań. To też projekty mające dobrze określony moment końcowy, np. zbudowanie Empire State Building o 102 piętrach i głównym tarasie widokowym na 86-tym piętrze.

Świat innowacyjnych produktów cyfrowych to jednak zupełnie „inna bajka”.

Z pewnością podczas lektury narodziło się w Waszych głowach kilka pytań, na przykład takie oto:

• Czy rola Project Managera będzie nadal potrzebna?
• Co z wiedzą na temat klasycznych metod i technik zarządzania projektami? Czy jeszcze będzie przydatna, czy raczej nadaje się do lamusa?

Odpowiedzi na te pytania będą tematem kolejnego tekstu z cyklu „Product Management vs. Project Management”.