O narzędziach do zarzadzania projektami można mówić na wiele sposobów. Można też przewrotnie – w odniesieniu do medycyny. Ale tylko pozornie. Bo jeśli wymienić trzy osoby: historycznego doktora Schnabel von Rom, telewizyjnego House’a oraz współczesnego nam doktora Goldratta, to pytanie nasuwa się jedno – w jaki sposób, tak różne od siebie postacie, mogą pomóc nam lepiej zrozumieć zarzadzanie projektami?


Primum non nocere

Wszystko zaczęło się od medycyny, której historia sięga czasów starożytnych. Choć w tamtym okresie choroby leczono najczęściej za pomocą magicznych rytuałów, to także wtedy zrewolucjonizowano podejście do długotrwałych dolegliwości, postulując baczne obserwowanie choroby. We współczesnej medycynie w dalszym ciągu istnieją dwa różne podejścia do leczenia. Pierwsze z nich, to leczenie objawowe, doraźnie łagodzące skutki choroby. Przykładowo: jeśli mamy gorączkę, stosujemy leki na jej zbicie, jeśli mamy katar, używamy chusteczek do nosa, które chwilowo przynoszą ulgę. Niestety żaden z tych środków nie rozwiązuje problemu. Dobrym przykładem jest doktor Schnabel Von Rom_, który w XVII w. uważany był za specjalistę i praktyka w dziedzinie leczenia dżumy. Z perspektywy czasu okazał się jednak szarlatanem, w masce w kształcie ptasiego dzioba, który bezskutecznie „leczył” chorych czosnkiem, octem siedmiu złodziei, driakwią. Epidemia dżumy okazała się sprawdzianem, który był jednak bardziej wymagający niż zakładano. Drugim rodzajem podejścia, które zdałoby taki egzamin, jest leczenie przyczynowe, zmierzające do usunięcia źródła choroby. Postacią symbolizująca właśnie takie spojrzenie na sprawę, jest serialowy doktor House. Genialny diagnostyk, który swoim nieprzeciętnym intelektem, naukowym podejściem i skutecznością, nie raz rzucał na kolana medycynę wschodu. Podsumowując – leczenie objawowe nie działa, nie działa także leczenie przyczynowe, o ile jest nietrafne.

Dobre praktyki w zarzadzaniu – leczenie doraźne czy przyczynowe?

Podobnie jest w zarzadzaniu – doraźne leczenie projektów nie jest rozwiązaniem. Na naszej drodze często występują dość znane, oczywiście „z firmy innej niż nasza”, symptomy: pierwotne terminy nie są dotrzymywane, pojawiają się  przekroczenia budżetu, potrzebne zasoby nie są dostępne na czas, pracownicy są wykończeni. Brzmi znajomo? Czy w takim momencie, gdy projekt wykazuje niepokojące oznaki, staramy się dokonać diagnozy różnicowej, niczym doktor House, czy zdajemy się na sprawdzone remedia? Najczęstsze kroki jakie prewencyjnie lub doraźnie podejmujemy, gdy projekt przejawia alarmujące objawy, to m.in. szkolenia, systemy motywujące, wprowadzenie sprawdzonych standardów i procesów, certyfikacje pracowników, albo ad hoc – zmiana kierownika projektu, zmiana całego zespołu, przygotowanie planu naprawczego czy nawet zamkniecie projektu. Czy to działa? Mówimy, ze oczywiście! Przecież wszystkie opisane standardy zarzadzania maja jeden cel, którym jest zebranie najlepszych praktyk. Stosujemy dobre praktyki, bo działają, a działają, bo wszyscy je stosują. W ten sposób popadamy w błędne koło ustalonych standardów, które z pełnym  przekonaniem wykorzystujemy jako uniwersalne remedium. Czym różnią się w takim razie nasze problemy od przeszkód, którym stawiali czoła kierownicy projektów 40 lat temu? Niczym – są dokładnie takie same. W takim razie, jeśli od tylu dekad mamy sprawdzone rozwiązania, które doskonale działają na płaszczyźnie teoretycznej, to czego brakuje? Otóż podejścia naukowego.

„Największe pomysły cechuje prostota” – W. Golding

Nasz kolejny, przykładowy doktor stosował podejście naukowe. Zainspirowany cytatem Newtona: „Natura valde simplex est et sibi consona” (Natura jest niezwykle prosta i harmonijna z sama sobą) uważał, „ze każda rzeczywista sytuacja, niezależnie od tego, jak początkowo wydaje się złożona, jest w gruncie rzeczy, gdy zostanie już zrozumiana, żenująco prosta”. Tym człowiekiem był dr Eliyahu Goldratt, izraelski fizyk stosujący naukowe podejście do rozwiazywania ekonomicznych problemów przedsiębiorstw. Wejście w świat zarzadzania Goldratt zaczął z przypadku, gdy został poproszony przez swojego sąsiada o pomoc w opracowaniu programu, który zwiększy produkcje w jego fabryce kurników. Tak powstała technologia optymalizacji produkcji (OPT – Optimized Production Timetable), która dała swój początek teorii ograniczeń (TOC – Theory of Constraints). Sława Goldratta odbiła się na tyle szerokim echem, ze został poproszony o konsultacje m.in. przez firmę Statoil. W latach 80-tych koncern borykał się ze znacznymi opóźnieniami w budowie platform wiertniczych. Goldratt po rozmowach z kadrą zarządzająca, zapoznaniem się z problemem i studiowaniu wewnętrznych procesów firmy, znalazł rozwiązanie. Na tyle proste, ze zanotował je na serwetce, lecąc na spotkanie z zarządem koncernu.

Rys. 1. Ogólny schemat chmury Goldratta
Źródło: mandarine.co

Chmura Goldratta

Goldratt wierzył, ze przyczyna każdego, permanentnego problemu jest wewnętrzny, logiczny konflikt. Przekładając na fizyczne podejście – zawsze istnieje antysiła, która stoi w sprzeczności z siłą dążąca do zastosowania rozwiązania. W przeciwnym wypadku metoda naprawcza zostałaby już wdrożona.

Chmura Goldratta, będąca integralną częścią łańcucha krytycznego, jest procesem myślowym. Jego celem jest odpowiedź na pytania niezbędne do osiągniecia konkretnej poprawy. Przykładowo: w konflikcie kierownika projektu (rys. 2), opisanym na schemacie chmury, pokazany jest ważki problem – terminy nie są dotrzymywane. Opóźnianie się projektu uderza w realizacje koniecznej potrzeby, jaka jest wynik biznesowy projektu. Skoro terminowość projektu, czyli kluczowy aspekt, jest zagrożony, to na etapie planowania zakładamy bezpieczne czasy. Siłą, która blokuje wdrożenie bezpiecznego rozwiązania, czyli długich czasów, jest potrzeba realizacji projektów jak najszybciej, z zachowaniem krótkich terminów. Nie da się planować czasów zarówno bezpiecznych jak i ambitnych, wiec dwie siły w tym miejscu się wykluczają i występuje rzeczony konflikt wewnętrzny. W tym momencie nie mamy jeszcze dobrego rozwiązania danego problemu, ale dzięki diagnozie różnicowej poznaliśmy już przyczynę naszej choroby.

Rys. 2. Przykładowy konflikt
Źródło: mandarine.co

Na rys. 3 przedstawiony jest schemat procesu zarzadzania pojedynczym projektem. Na jakim wiec jego etapie technika chmury jest pomocna? Na etapie analizy przedprojektowej procedura może i powinna być wykorzystana do znalezienia rozwiązania. Skoro projekty najczęściej powoływane są w celu rozwiązania jakiegoś specyficznego problemu, mamy dwa wyjścia. Będziemy postępować niczym doktor Schnabel von Rom i dla rozwiązania pojedynczego symptomu będziemy każdorazowo powoływać osobny projekt (przez co możemy doprowadzić do złej wielozadaniowości) albo wybierzemy podejście naukowe doktora House’a, używając zmultiplikowanej techniki chmury – chmury skonsolidowanej. Inaczej mówiąc, dla każdego z symptomów stworzymy chmurę i sprawdzamy, czy należy ona do innej, większej i bardziej ogólnej. Choć znów nie jesteśmy w stanie podać jednego, sprawdzonego rozwiązania, to należy podkreślić, że w technice chmury zawsze istnieje logiczne rozwiązanie danego konfliktu. I tak, w prozaicznym przykładzie pozornie nie do przejścia, gdzie jedna osoba chce pojechać na wakacje w góry, a druga nad morze, możemy znaleźć rozwiązania, w których żadna ze stron nie będzie musiała ustępować drugiej. Logicznym wyjściem może być wyjazd na wakacje razem, do Chorwacji, gdzie są zarówno góry i morze, albo samodzielna podróż w wybrane miejsce. Zgodnie z podkreślonym wcześniej stwierdzeniem – rzeczywistość jest niezwykle prosta i wewnętrznie niesprzeczna, dlatego należy poszukiwać sposobu dostatecznie długo, by rozwiązać wewnętrzny konflikt. A ponieważ, jak mawiają, zarzadzanie projektami nie istnieje, to technikę chmury można zastosować także na płaszczyźnie międzyludzkiej.

Rys. 3. Schemat procesu zarzadzania projektem
Źródło: mandarine.co

  1. http://en.wikipedia.org/wiki/Plague_doctor
  2. Watson Kevin J., Blackstone John H., Gardiner Stanley C., “The evolution of a management philosophy: The Theory of  constraints”, Journal of Operations Management, 2007, vol. 25, issue 2, pages 387–402.