Założenia to przekleństwo

Czasami warto jest się przyjrzeć głębiej powodom, dla których podejmowane są działania uważane przez wszystkich za oczywiste. Dla przykładu pierwsza z brzegu rzecz czyli planowanie. Wszyscy wiemy, że to jest ważne, jest podstawą pracy itd. Projekty z definicji są działaniami, które są innowacyjne, które zawierają w sobie pewien element niepewności. Dlatego też musimy je planować a nie działać automatycznie jak to się robi w przypadku procesów. Plan jest następnie realizowany, po czym, w dużej części przypadków, następuje brutalne zderzenie z rzeczywistością, które dla planu okazuje się być nie do przeżycia. Zwykle w wyniku nieprzewidzianych zdarzeń muszą nastąpić poważne zmiany w planie jak i w samych produktach projektu.

Interesujące jest co dzieje się dalej. W większości środowisk, z którymi miałem do czynienia podejmuje się natychmiastowe działania naprawcze skupiające się wokół generalnego twierdzenia "musimy lepiej planować". Przez "lepiej" w tym wypadku określa się zwykle dogłębniej, dokładniej i bardziej szczegółowo. Generalnie bardziej kosztownie. I tu pojawia się pytanie następujące. Jakie założenie stoi za twierdzeniem, że więcej zasobów poświęconych na planowanie automatycznie przekłada się na lepszą realizacje tychże planów w przyszłości?

Jak dla mnie założenia za tym twierdzeniem są następujące "planując dłużej uzyskujemy większą kontrolę nad przyszłością" oraz "dłuższe planowanie powoduje zmniejszenie liczby zmian w przyszłości". Czy te założenia są prawdziwe? Wątpię. Czy to oznacza, że planowanie jest zbędne. Oczywiście nie. Oznacza tylko, że nigdy nie możemy oczekiwać, że maksymalne wydłużenie analizy i planowania spowoduje automatyczny sukces naszego projektu. Tak się nie dzieje. Od pewnego momentu mimo przeznaczania coraz większych nakładów na planowanie "uzysk" dokładności jest minimalny. A im działanie jest bardziej innowacyjne tym to "wypłaszczenie" następuje szybciej.

Co z tym zrobić? Może zamiast brnąć w taki system oparty na błędnym założeniu skonstruować system, który dostosowuje się do rzeczywistości. Czyli zadać sobie pytanie "jak powinien wyglądać mój system realizacji projektów jeżeli założę, że zmiany na pewno nastąpią". Jeżeli uda się taki system zbudować i wprowadzić w życie to zamiast walczyć z rzeczywistością otrzymamy organizację potrafiącą w danej rzeczywistości idealnie zarządzać.

P.S. Oczywiście powyższe wywody nie dotyczą pewnej klasy systemów, np. takich gdzie gra idzie o życie ludzkie (projektowania samolotów).

Zarządzanie innowacjami jest łatwe!!!

A konkretnie: zarządzanie projektami innowacyjnymi nie jest trudniejsze od projektów nie-innowacyjnych. Taki długi tytuł nie zmieściłby się na stronie. Przechodząc do konkretów:
Zupełnie nie rozumiem, dlaczego przyjęło się, że zarządzanie projektem wysoce innowacyjnym jest dużo trudniejsze niż zarządzanie projektem „standardowym”. Fakty przeczą takiemu twierdzeniu i jedyne, co można powiedzieć to, że zarządzanie jest „inne”, ale na pewno nie „trudniejsze”.

W zarządzaniu projektami innowacyjnymi główną „innością” jest występująca duża niepewność, co do podejmowanych działań. Z jednej strony tradycyjna metodyka zarządzania projektem zwykle wymaga, żebyśmy już na początku wiedzieli, co dokładnie mamy zrobić, w jakiej kolejności i ile to potrwa. Z drugiej strony samo pojęcie innowacyjności sugeruje coś dokładnie odwrotnego: nie wiemy co dokładnie mamy zrobić, nie wiemy dokładnie jaki będzie rezultat, ani tym bardziej nie wiemy ile dokładnie przeznaczymy na to czasu. Z takich dwóch stanowisk rodzi się konflikt, którego rozwiązanie nie wydaje się być proste. Wtłoczeni w ten konflikt kierownicy projektów rozrywani między dwie strony twierdzą później, że zarządzanie projektami innowacyjnymi to koszmar.

Tymczasem ten konflikt można rozwiązać w dość prosty sposób: zmieniając założenia dotyczące zarządzania projektami. Metody tradycyjne, wymagające bardzo dokładnego planowania po prostu są tutaj złym narzędziem. To tak, jakby ktoś próbował użyć siekiery do obierania ziemniaków i narzekał, że to frustrujące. Wystarczy natomiast zmienić narzędzie (na nóż) i natychmiast przestaniemy się frustrować.

Ogólnie można wyróżnić dwa „trudne” przypadki w zarządzaniu projektami innowacyjnymi: albo wiemy co mamy zrobić (poszczególne zadania) ale nie wiemy ile będą trwały, bo są one innowacyjne, albo wiemy tylko co chcemy osiągnąć, ale nie mamy sprecyzowanej drogi dojścia do celu.

W drugim wypadku, gdy znamy tylko cel a nie znamy metody dojścia do celu ani nie możemy jej zaplanować w ekonomicznie uzasadnionym czasie pozostaje użycie narzędzia stworzonego do takich przypadków: zwinnego zarządzania projektami. Jak już wielokrotnie tu było pisane metody zwinne pozwalają na dokładne planowanie tylko krótkich iteracji zbliżających cały projekt do wcześniej określonego celu (wizji). Jednocześnie częste interakcje z klientem pozwalają na weryfikację czy nasza innowacja stanowi wartość dodaną dla klienta. W ten sposób możemy bardzo szybko wycofać się z chybionych inwestycji. Czy zarządzanie projektem innowacyjnym w oparciu o takie procesy to koszmar? Nie, to czysta przyjemność. Pod warunkiem oczywiście, że procesy będą wspierane przez wszystkich w organizacji a nie tylko przez kierownika projektów.

Innym przypadkiem jest pierwszy z przypadków opisanych wcześniej. Czyli sytuacja, kiedy wiemy, jakie zadania należy wykonać w projekcie, ale innowacyjność przedsięwzięcia uniemożliwia stworzenie poprawnych oszacowań czasu trwania poszczególnych zadań. Jest to interesujące, bo problem ten dotyczy także innych projektów, niekoniecznie innowacyjnych – często z wielu przyczyn nie możemy określić dokładnie czasu trwania poszczególnych zadań lub ten czas trwania z założenia jest określony z dość małym stopniem prawdopodobieństwa. Znów użycie tradycyjnych metod zarządzania projektami w takim przypadku bardzo szybko prowadzi do frustracji kierownika projektu i całego zespołu. Należy bowiem zdać sobie sprawę, że np. szeroko stosowana metoda ścieżki krytycznej zakłada, że czasy trwania poszczególnych zadań są oszacowany poprawnie. Jeżeli pojawią się różnice w realnym czasie wykonania zadań w stosunku do planu wówczas ścieżka krytyczna może się zmieniać praktycznie codziennie doprowadzając osobę próbującą nią zarządzać na stan załamania nerwowego. Czy tak musi być? Nie. Istnieją odpowiednie metody zarządzania projektami, które skonstruowane zostały właśnie po to, aby radzić sobie z niedokładnością oszacowań. Taką metodą jest metoda łańcucha krytycznego (łańcuch a ścieżka to dwa różne pojęcia). W metodzie łańcucha krytycznego zakłada się skonstruowanie modelu projektu w taki sposób, aby ochronić datę zakończenia projektu przed zmianami. Jednocześnie jednym z założeń tej metody jest niedokładność oszacowań czasu trwania poszczególnych zadań. Niemożliwe? A jednak. Możliwe i wykorzystywane.

Znów dochodzimy do tego, od czego ten post się zaczął. Zarządzanie projektami innowacyjnymi jest łatwe. Pod warunkiem, że użyje się odpowiedniego narzędzia. Niestety część osób próbuje używać tego samego zestawu narzędzi do zarządzania stabilnym projektem budowy domku jednorodzinnego jak i do zarządzania wysoce innowacyjnym projektem z dziedziny IT. Oczywiście można próbować, tylko jaki będzie efekt? Etyka zawodowa kierownika projektów powinna nakazywać poznanie więcej niż jednej metody zarządzania projektami. Każdy kierownik powinien posiadać wiedzę o wielu narzędziach i wykorzystywać je w zależności od potrzeb. Jeżeli będzie próbował zawsze i wszędzie stosować jedno i to samo narzędzie to niestety skutki będą znane: frustracje, porażki i tłumaczenia, że to jest „trudne i skomplikowane”. Fakt, obieranie ziemniaka przy użyciu siekiery jest trudne i skomplikowane.

Niepewność wymagań

Niepewność wymagań została wywołana dwukrotnie w ciągu ostatnich dwóch tygodni, w tym raz publicznie w komentarzach na blogu Alexa. Dlatego dzisiaj o niepewności wymagań.

W świecie IT (choć nie tylko) bardzo często dochodzi do sytuacji, kiedy w momencie w którym projekt powinien się rozpocząć zespół wykonawczy nie jest w stanie spisać wszystkich wymagań klienta. Według standardowych metod w takim wypadku należy powołać zespół analityków i być może projektantów, którzy siądą z użytkownikami końcowymi (lub klientem, choć to bardziej ryzykowne) i spiszą wymagania. Brzmi bardzo rozsądnie. Problem pojawia się w momencie kiedy klient nie wie czego by chciał. To wbrew pozorom zdarza się dosyć często. Tzn. klient wie do czego ma służyć system, wie jakie mają być główne jego funkcje, ale na przykład wymyślenie szczegółowych raportów, które powinien generować system jest poza możliwościami klienta. Głównie dlatego, że system nie istnieje jeszcze w rzeczywistości a człowiek często ma trudności w operowaniu bytami wirtualnymi. Co więcej jest pewna gama projektów, w których nie ma możliwości określić wszystkich wymagań na początku trwania projektu. Przykładami jest większość projektów internetowych. Na przykład www.flickr.com powstał jako narzędzie do dzielenia się zdjęciami. Kto w momencie powstawania tego serwisu zdefiniowałby takie funkcjonalności jak geotagging czy tworzenie fizycznych gadżetów ze zdjęciami?

Wracając jednak do niepewności wymagań: należy założyć, że istnieją projekty w których ta niepewność po prostu jest. Są też projekty, w których tej niepewności być nie powinno. Na przykład projekty realizowane w ramach zamówień publicznych - tam wszystkie wymagania powinny być określone w SIWZ. Błędem często popełnianym przez kierowników projektów jest próba użycia metodyk doskonale sprawdzających się w projektach ze stałymi wymaganiami do projektów w których występuje duża niepewność wymagań. Oczywiście gwoździe można wbijać trzonkiem noża zamiast młotkiem ale skutki mogą być opłakane.

Narzędziem do radzenia sobie z projektami o dużej niepewności wymagań są właśnie metody zwinne zarządzania projektami. Metody zwinne oferują kilka narzędzi/technik, które pomagają radzić sobie z takimi problemami. Najważniejsze:

• Klient szybko dostaje wartość dodaną - krótkie powodują, że klient dostaje regularnie system wzbogacony o nowe funkcjonalności do testowania, co powoduje że jest w stanie na żywo sprawdzić czy jego wymagania zostały spełnione i wygenerować/uszczegółowić nowe
• Planuje i rozlicza sie funkcjonalności - całe planowanie oparte jest o kolejne funkcjonalności a nie o zadania do wykonania. Z tego względu klient i zarząd dokładnie wie co (jaką wartość) otrzyma po każdej iteracji. Konieczność zdefiniowania tego powoduje, że musi doprecyzowywać wymagania na bieżąco - do realizacji nie wchodzą wymagania "niepewne".
  
• Można planować na różnych poziomach - Ze względu na poziomy planowania tylko najbliższa iteracja lub iteracje muszą być zaplanowane dokładnie. Kolejne wersje mogą być zaplanowane mniej dokładnie, co wprost implementuje naturalną dla człowieka zdolność do dokładniejszego planowania tego co jest bliżej a mniej dokładnego tego co jest dalej. Dodatkowo w sposób naturalny obejmuje to wszelkie niepewności co do wymagań odnośnie szczegółów projektu.
  
• Istnieje pewność realizacji spójnego projektu - poziom planowania produktu czy też wizji w projektach zwinnych zapewnia, że cały czas będziemy realizować jeden projekt z jedną wizją i spójnym produktem końcowym. Pozwala to błyskawicznie wykryć sytuację kiedy okaże się, że wymagania tak się zmieniły, że robimy co innego niż pierwotnie zakładane.
  
• Zespół pracuje w środowisku stabilnym - na czas iteracji. A to już spojrzenie "z drugiej strony". Programiści i inni zaangażowani w projekt realizowany metodami zwinnymi są szczęśliwi, bo mają pewność że wymagania są zamrażane na czas jednej iteracji. Mają pewność, że nikt nie przerwie im pracy i nie zmieni gwałtownie tego co robią przez całą iterację. Ta pewność w morzu niepewności jest przez członków zespołów szczególnie ceniona.
  

Oczywiście na koniec słowo o kontraktach. Kiedyś już to było poruszane na tym blogu. W skrócie jeżeli klient nie wie co chce to w jaki sposób może oczekiwać, że my wiemy jak to wycenić? W przypadku projektów o dużej niepewności wymagań podawanie stałej ceny za zrealizowanie takiego kontraktu to chodzenie po bardzo cienkiej linie.