Dlaczego zarządzanie zadaniami projektowymi jest niewystarczające?

Myśląc o realizacji projektu często koncentrujemy się na zarządzaniu zespołem, a zwłaszcza na komunikacji w zespole, dzieleniu się pracą i monitorowaniu postępów realizacji zadań. Jeśli realizujemy projekty samodzielnie to faktycznie aspekt zarządzania zespołem jest wiodący, ale zdecydowanie niewystarczający, aby efektywnie i skutecznie zarządzać całym projektem. W przypadku projektów realizowanych z podwykonawcami jest to jeszcze bardziej istotne.

---

Widać to szczególnie jaskrawo w przypadku oprogramowania służącego do zarządzania zadaniami (tj. JIRA, monday.com, Trello), którego producenci reklamują je jako narzędzia do zarządzania projektami. Jest to, mówiąc wprost, nadużycie, bo w praktyce są to narzędzia wspierające „jedynie” zarządzanie zadaniami w projekcie i, co warto przyznać, robiące to często bardzo dobrze. Jednak zarządzanie projektem to dużo więcej!

W niniejszym artykule postaram się krótko omówić kluczowe różnice między zarządzaniem samymi zadaniami i zarządzaniem całym projektem, starając się pomóc w szczególności w bardziej świadomym doborze narzędzi, które mogą wesprzeć organizację nie tylko w zakresie pracy zespołowej, ale także w zakresie zarządzania projektami.

Zadania i harmonogram projektu

Zadania to nie harmonogram projektu. Często zadania są utożsamiane z pakietami prac/działaniami, a są to zupełnie inne pojęcia. Harmonogram projektu składa się z pakietów prac/działań, ich grup oraz kamieni milowych, pozwalając zrozumieć logikę realizacji prac w projekcie (zależności, ograniczenia etc.) i w konsekwencji określić terminy cząstkowe i finalny termin zakończenia projektu.

Zadania co do zasady powinny być uszczegółowieniem harmonogramu, a konkretnie uszczegółowieniem określonych pakietów prac/działań. Zadania często są tworzone później niż harmonogram, kiedy już wiadomo kto i co konkretnie będzie robił w projekcie. Jeśli będziemy konstruować harmonogram projektu od razu na poziomie zadań (co jest np. domyślnym sposobem pracy w MS Project), to powstanie nam często bardzo złożony harmonogram, który będzie się zmieniał codziennie, a tego nikt nie oczekuje. Takie harmonogramy są bardzo pracochłonne w aktualizacji i utrudniają zrozumienie logiki realizacji prac w projekcie.

Bazując na samych zadaniach jesteśmy „skazani” na niepoprawną metodycznie i praktycznie postać harmonogramu, który w efekcie jest zbyt szczegółowy i często nieaktualny. Obecna w oprogramowaniu do zarządzania zadaniami wizualizacja zadań w formie wykresu Gantta może być kojarzona z harmonogramem projektu, którym w praktyce nie jest – to tylko postać graficzna rozłożenia zadań w czasie wraz z ich zależnościami.

Produkty

Każdy projekt powinien dostarczyć określony produkt lub wiele produktów. W końcu chodzi o to, żeby „zrobić”, a nie tylko „robić”… Produkty są wynikiem zrealizowanych prac, czasami w różnych wątkach i toczących się równolegle. W harmonogramie mogą być utożsamiane z kamieniami milowymi. Często cały projekt zaczynamy planować opisując w pierwszej kolejności produkt końcowy i opcjonalnie także produkty cząstkowe. Dzięki temu jesteśmy wstanie lepiej doprecyzować zakres prac wymaganych do dostarczenia produktu(ów) projektu.

W przypadku bazowania jedynie na zadaniach narażamy się na ryzyko, iż zaplanujemy wiele różnych czynności, ale niekoniecznie wszystkie z nich będą wymagane i jednocześnie wystarczające do dostarczenia oczekiwanych wyników, czyli produktów projektu. Trudniejsze będzie też ułożenie zadań w odpowiedniej kolejności, bez świadomości zależności między wynikami (produktami) prac.

Wydatki

Jeśli projekt wiąże się z wydatkowaniem środków (np. na zakup usług, infrastruktury, licencji etc.) to zarządzanie projektem obejmuje także planowanie i prognozowanie budżetu projektu, oraz śledzenie jego wykonania i analizę odchyleń wydatków prognozowanych i rzeczywistych od tych zaplanowanych.

Skupiając się jedynie na zadaniach w oczywisty sposób pomijamy aspekt finansowy projektu. Co więcej, często wystąpienie wydatków w czasie jest związane z elementami harmonogramu projektu (np. rozpoczęcie/zakończenie realizacji określonego pakietu prac/działania czy też osiągnięcie kamienia milowego).

Oczekiwane jest zatem prognozowanie zmian w rozłożeniu wydatków w czasie w ślad za powiązanymi przesunięciami w harmonogramie projektu. W oprogramowaniu Hadrone PPM takie przesunięcia prognoz wydatków mogą odbywać się automatycznie, redukując pracochłonność dla kierownika projektu i zapewniając aktualność danych po każdej aktualizacji harmonogramu.

Zasoby

Zasoby, które najwygodniej planować na poziomie kompetencji, a nie konkretnych osób, stanowią drugi „budżet” projektu, pozwalający zapanować nad planowaną, prognozowaną i rzeczywistą pracochłonnością projektu.

Pracując tylko na zadaniach dowiemy się po fakcie, ile faktycznie poświęciliśmy czasu na realizację zadań, ale nie będziemy w stanie zapanować nad wykorzystaniem pracochłonności w skali całego projektu. Narażamy się więc na ryzyko, że projekty będą zbyt pracochłonne, a tym samym, zbyt kosztowne.

Czasami uwzględniamy też koszty pracy w budżecie projektu, bazując na określonych stawkach kosztowych dla poszczególnych kompetencji i łączymy wykorzystanie kompetencji z harmonogramem projektu, żeby zrozumieć jak pracochłonna jest realizacja poszczególnych działań, etapów, faz etc.
Do tego również same zadania nie będą wystarczające.

Efekty projektowe

Projekty służą wprowadzaniu zmian w organizacji. Zmiana zawsze wiąże się z dążeniem do osiągnięcia określonych efektów, które z kolei są fundamentem uzasadnienia biznesowego projektu. Zarządzanie efektami i wydatkami pozwala również na śledzenie trwałości uzasadnienia biznesowego projektu podczas jego realizacji.

Skupiając się jedynie na zadaniach nie będziemy mieli pewności, czy realizacja tych zadań jest celowa, czyli czy przyniesie określone efekty po projekcie. Dobre zaplanowanie efektów pozwala skonkretyzować uzasadnienie biznesowe projektu i dookreślić zakres prac projektowych.

Ryzyka

Zarządzanie ryzykiem w projekcie pozwala na identyfikację zagrożeń dla realizacji projektu (w odniesieniu do harmonogramu, budżetu czy też wykorzystania zasobów) a także szans oraz podejmowanie działań mających na celu zapobieganie wystąpieniu zagrożeń i maksymalizacji szans.

Obserwując postępy prac w harmonogramie, wydatkowanie środków i wykorzystanie pracochłonności kierownik projektu może identyfikować ryzyka z wyprzedzeniem, dostarczając podstaw do podejmowania decyzji przez osoby nadzorujące projekt.

Skupiając się tylko na zadaniach dowiemy się o opóźnieniach oraz przekroczeniach budżetów i zasobów już po fakcie, więc nie będziemy mogli nic z tym zrobić.

Plan bazowy

Plan bazowy projektu jest swego rodzaju kontraktem zawieranym (najczęściej nieformalnie) między kierownikiem projektu i organizacją. W planie bazowym umawiamy się na to co ma być zrobione, w jakich terminach i przy wykorzystaniu jakich środków (pieniądze, czas pracy zespołu) oraz jakie efekty spodziewamy się osiągnąć w wyniku realizacji projektu. Plan bazowy nie jest wyryty w kamieniu – może się zmieniać, ale takie zmiany muszą być wykonywane pod kontrolą, przez odpowiednie osoby i ze świadomością wpływu zmian w planie na różne aspekty projektu, a w szczególności na jego uzasadnienie biznesowe.

Skupiając się tylko na zadaniach tracimy kontrolę nad harmonogramem, budżetem, zasobami i efektami. Wystawiamy się na ryzyko niezrealizowania kluczowych etapów i całego projektu w oczekiwanych terminach i przy oczekiwanym zaangażowaniu zasobów (finansowych i ludzkich). Nie mamy również kontroli nad zmianami w spodziewanych efektach projektu, co może wpłynąć na utratę uzasadnienia biznesowego projektu, o czym jednak nie będziemy wiedzieć.

W dynamicznie zmieniającym się świecie planowanie wcale nie przestało być istotne – wręcz odwrotnie, nabiera na znaczeniu, abyśmy mogli zapanować nad tą zmiennością i podejmować świadome decyzje na bieżąco. Zgodnie z maksymą, że „plan jest niczym, ale planowanie jest wszystkim”…

Zintegrowane zarządzanie zadaniami i projektem

Zarządzanie zadaniami jest więc jednym z wymiarów zarządzania projektem. Bardzo ważnym, ale z pewnością nie jedynym. Same zadania też mają różny charakter, od lekkich i zwinnych, często wizualizowanych na tablicach Kanbana, do bardziej formalnych, z zaplanowanymi terminami realizacji i pracochłonnością, przepływami prac do zlecania i odbierania zadań, służące do rozliczeń między zleceniodawcą i zleceniobiorcą. Warto o tym pamiętać, dobierając odpowiednie narzędzie IT, które będzie wspierać realizację zadań projektowych.

Czasami wykorzystujemy równolegle dwa typy narzędzi, do zarządzania zadaniami i do zarządzania projektem, które mogą być integrowane. W ten sposób funkcjonuje oprogramowanie Hadrone PPM, które oprócz zarządzania całym portfelem projektów, poszczególnymi projektami i zadaniami, zapewnia także integrację z JIRA. Dzięki temu zespoły wytwórcze nadal pracują w wygodnym dla siebie środowisku, a kierownik projektu łatwo monitoruje postępy realizacji zadań i wpływ ewentualnych opóźnień w zadaniach na harmonogram projektu.

Podsumowanie

Celem tego artykułu było wskazanie różnic między samym zarządzaniem zadaniami projektowymi, a zarządzaniem całym projektem. W szczególności przed wyborem odpowiedniego narzędzia informatycznego wspierającego organizację projektową warto przeanalizować, jakie faktyczne potrzeby ma nasza organizacja (tylko zadania, czy całe projekty), nie poprzestając tylko na komunikatach marketingowych dostawców oprogramowania, którzy często nadużywają terminu „zarządzanie projektem”.

W tym artykule opowiedziałem o tym, dlaczego zarządzanie zadaniami jest niewystarczające do efektywnej i skutecznej realizacji projektów. W kolejnym numerze Strefy PMI podpowiem z kolei, dlaczego zarządzanie projektem nie jest wystarczające do tego, aby organizacja realizowała najlepsze możliwe projekty, mieszczące się w ograniczeniach finansowych i zasobowych, osiągając zakładane efekty, zgodnie ze strategią organizacji.