Project management system powinien przede wszystkim pokazywać, co jest do zrobienia, kto za to odpowiada i co blokuje kolejne zadanie. Łatwo natomiast kupić narzędzie, które świetnie wygląda na prezentacji, ale po miesiącu staje się dodatkowym miejscem do ręcznego przepisywania informacji z maila i komunikatora.
Zacznij od jednego prawdziwego projektu
Przed wyborem warto wziąć trwający projekt i przenieść go do wersji próbnej. Trzeba utworzyć zadania, terminy, osoby, zależności i kilka zmian zakresu. Wtedy szybko wychodzi, czy system pomaga, czy wymaga ciągłego klikania tylko po to, by utrzymać aktualny obraz.
Warto oddzielić termin zobowiązania wobec klienta od wewnętrznej daty planowanej. Zespół potrzebuje bufora, ale raport powinien jasno pokazywać oba poziomy.
Eksport danych i historia zmian są ważne przy długich projektach oraz wtedy, gdy firma może w przyszłości zmienić narzędzie.
Lista zadań to nie zawsze zarządzanie projektem
W prostym zespole tablica z kolumnami może wystarczyć. Przy większych przedsięwzięciach zaczynają mieć znaczenie zależności, kamienie milowe, obciążenie ludzi, budżet i historia decyzji. Nie warto płacić za te funkcje, jeśli projekt ich nie potrzebuje, ale też nie warto udawać, że sam status „w toku” rozwiązuje problem wielu powiązanych prac.
System projektowy powinien pokazywać odpowiedzialność, termin i zależności, a nie tylko przechowywać długą listę zadań.
System powinien ograniczać spotkania statusowe
Jeżeli przed każdym zebraniem wszyscy muszą aktualizować osobny arkusz, dane w narzędziu nie są używane na bieżąco. Dobrze skonfigurowany projekt pozwala wejść na spotkanie z aktualnym obrazem i rozmawiać o problemach, a nie przepisywać statusy.
Po zakończeniu projektu archiwum decyzji, zakresu i problemów może być materiałem do następnego planu. System ma wartość również po zamknięciu ostatniego zadania.
Najlepszym testem jest przeniesienie jednego realnego projektu do wersji próbnej, zamiast oceniania przykładowej tablicy przygotowanej przez producenta.
Uprawnienia i historia zmian rosną razem z zespołem
Przy kilku osobach każdy może widzieć wszystko. W projektach z klientami i podwykonawcami potrzebne są bardziej precyzyjne role. Historia pomaga później ustalić, kiedy zmienił się termin albo zakres i kto zatwierdził decyzję.
Mały zespół zwykle korzysta na prostszym procesie. Jeżeli aktualizacja zadania trwa dłużej niż wykonanie drobnej pracy, system jest zbyt ciężki.
Zależność między zadaniami powinna być używana tam, gdzie rzeczywiście blokuje termin. Łączenie wszystkiego ze wszystkim tworzy skomplikowany wykres, który trudno utrzymać.
Integracje powinny usuwać pracę, nie tylko istnieć
Połączenie z kalendarzem, komunikatorem czy repozytorium kodu ma wartość wtedy, gdy konkretna informacja pojawia się automatycznie we właściwym miejscu. Samo logo integracji na stronie producenta nie mówi, czy będzie użyteczna.
Dobry system do zarządzania projektami jest na tyle prosty, by zespół naprawdę go aktualizował, a jednocześnie przechowuje wystarczająco dużo kontekstu, żeby kierownik nie musiał odtwarzać sytuacji z dziesięciu rozmów. To lepsze kryterium niż liczba modułów.
Task management nie powinien zastępować rozmowy tam, gdzie potrzebna jest szybka decyzja. Narzędzie ma przechowywać ustalenia i pilnować odpowiedzialności.
System projektowy powinien pokazywać odpowiedzialność
System projektowy powinien pokazywać odpowiedzialność, termin i zależności, a nie tylko przechowywać długą listę zadań.
Zbyt wiele statusów zwiększa koszt aktualizowania systemu i skłania użytkowników do obchodzenia procesu zamias
Zbyt wiele statusów zwiększa koszt aktualizowania systemu i skłania użytkowników do obchodzenia procesu zamiast korzystania z niego.
Z tym tematem bezpośrednio łączy się Business Intelligence a zwykły raport.
Zbyt wiele statusów zwiększa koszt aktualizowania systemu i skłania użytkowników do obchodzenia procesu zamiast korzystania z niego.