Jak wybrać program do zarządzania projektami dla swojej firmy

Program do zarządzania projektami wybieraj na podstawie jednego prawdziwego procesu, a nie liczby funkcji. Dobry kandydat pokaże, co ma się wydarzyć dalej, kto za to odpowiada, od czego zależy termin i jaki jest status kilku projektów naraz. Jeśli tego nie potrafi bez dokładania zespołowi drugiego raportowania, kolorowy pulpit niczego nie naprawi.

Siedem kryteriów, które warto sprawdzić przed zakupem, to: powtarzalność pracy, odpowiedzialność, zależności, widok wielu projektów, liczba osób dotykających procesu, granice z innymi systemami oraz opiekun zasad po wdrożeniu.

Program do zarządzania projektami czy program do zadań?

Program do zadań pilnuje pojedynczych rzeczy do wykonania. Program do zarządzania projektami łączy zadania w przedsięwzięcie z etapami, zależnościami, właścicielami i wynikiem. Różnica wychodzi wtedy, gdy praca przechodzi między osobami albo kilka projektów konkuruje o tych samych ludzi.

Nie każda firma potrzebuje ostatnich trzech wierszy. Jeżeli trzy osoby prowadzą jedną prostą tablicę, Trello albo Planner mogą być lepszym zakupem niż większy system. Mniej konfiguracji oznacza też mniej zasad, których ktoś musi później pilnować.

Siedem kryteriów wyboru programu do zarządzania projektami

Siedem kryteriów wystarcza, żeby skrócić listę kilkunastu aplikacji do dwóch kandydatów. Każde dotyczy sposobu pracy, który możesz pokazać na realnym projekcie.

1. Powtarzalność projektów

System projektowy zarabia na siebie wtedy, gdy zespół może użyć raz ustalonego przebiegu kolejny raz. Projekt klienta, kampania, wdrożenie produktu albo edycja programu zwykle mają wspólny szkielet, nawet jeśli szczegóły się różnią.

Jeżeli każde przedsięwzięcie jest naprawdę jednorazowe, rozbudowany szablon będzie kosztował więcej pracy, niż oszczędzi. Wtedy wystarczy lista zadań, terminów i właścicieli. Funkcje do automatyzacji powtarzalnego procesu zostaną niewykorzystane.

2. Odpowiedzialność i przekazania pracy

Dobry system pokazuje jednego właściciela następnego kroku. Gdy zadanie wymaga decyzji prawnika, materiału od marketingu i akceptacji dyrektora, każda z tych osób powinna widzieć swój moment wejścia bez czytania całej historii projektu.

Sprawdź to na jednym przekazaniu. Zamknij zadanie w dziale A i zobacz, czy osoba z działu B od razu wie, że ma przejąć pracę, z jakimi danymi i na kiedy. Jeśli trzeba jej to wyjaśnić na czacie, system odtworzył tablicę, ale nie odtworzył procesu.

3. Zależności i terminy

Zależność ma znaczenie wtedy, gdy opóźnienie jednej pracy zmienia datę następnej. Sama możliwość narysowania wykresu Gantta niczego nie daje. Narzędzie musi pokazać, kto jest zablokowany, jaki termin się przesunął i kto ma podjąć decyzję.

W prostym procesie wystarczą daty na kartach. Przy kilku etapach sprawdź zależności, kamienie milowe i sposób aktualizacji harmonogramu. Nie wpisuj dwudziestu dat tylko po to, żeby system wyglądał na kompletny. Wpisuj te, od których ktoś naprawdę planuje swoją pracę.

4. Widok wielu projektów

Widok wielu projektów jest potrzebny, kiedy manager nie może ustalić statusu bez wchodzenia do każdego projektu albo pytania prowadzących. Powinien pokazać przynajmniej właściciela, termin, status i blokadę. Reszta danych ma sens dopiero wtedy, gdy ktoś na ich podstawie podejmuje decyzję.

To miejsce, w którym prosta tablica najczęściej przestaje wystarczać. W Asanie taki widok może opierać się na portfolio i raportach, ale ich dostępność zależy od planu. Najpierw sprawdź więc, jakiego widoku potrzebujesz, a później cennik.

5. Liczba osób, które dotykają procesu

Nie licz całej firmy. Policz osoby, które tworzą zadania, przejmują pracę, zatwierdzają wynik albo muszą widzieć status. To od tej grupy zależą licencje, uprawnienia, szkolenie i liczba wyjątków w procesie.

W dużej firmie jeden dział może potrzebować kilkunastu kont, a reszta organizacji tylko raportu. W małej firmie pięć osób może pracować w pięciu różnych rolach i wymagać dokładniejszego podziału dostępu. Wielkość firmy sama w sobie niczego nie rozstrzyga.

Na tej podstawie policz koszt pierwszego roku, nie samą cenę jednego konta. Rachunek powinien zawierać:

• licencje osób, które naprawdę edytują pracę;
• konfigurację, migrację i szkolenie na początku;
• czas opiekuna potrzebny co miesiąc na szablony, uprawnienia i poprawki;
• integracje oraz dodatki, bez których proces wraca do ręcznego przepisywania.

Dwa programy z podobną stawką miesięczną mogą mieć zupełnie inny koszt utrzymania. Jeden wymaga dopracowania kilku wspólnych szablonów, drugi pozwala każdemu działowi zbudować własny wariant i później potrzebuje więcej administracji. Nie ma sensu porównywać cenników, dopóki nie wiesz, ilu użytkowników edytuje dane, który plan zawiera potrzebne widoki i kto będzie pilnował konfiguracji.

6. Granice z CRM-em i Microsoft 365

Program do projektów nie powinien przejmować każdej informacji w firmie. Zadanie, właściciel, termin i blokada mogą być w systemie projektowym. Plik zostaje w OneDrive lub SharePoint, rozmowa bieżąca w Teams, a historia klienta i sprzedaży w CRM-ie.

Granice sprawdź przed migracją. Jeśli zespół ma kopiować załączniki, komentarze i dane klienta do drugiego miejsca, stworzyłeś dodatkową administrację. Asana może łączyć odpowiedzialność nad pracą, ale nie musi zastępować Microsoft 365 ani Pipedrive.

7. Opiekun zasad po wdrożeniu

Ktoś musi zdecydować, kiedy dodać pole, zmienić szablon i odrzucić wyjątek, który przyda się jednej osobie raz w roku. Bez opiekuna każdy dział ustawi własny wariant, a po kilku miesiącach firma znowu zacznie ustalać status na spotkaniu.

To kryterium często rozstrzyga wybór między prostotą a elastycznością. Im więcej narzędzie pozwala skonfigurować, tym więcej decyzji zostawia administratorowi. Jeżeli nikt nie ma czasu pełnić tej roli, wybierz mniej opcji i krótszą listę zasad.

Które narzędzie pasuje do jakiej pracy?

Narzędzie wybierasz po rodzaju pracy, który dominuje w zespole. Tabela nie jest rankingiem. Pokazuje, od którego kandydata zacząć test i czego pilnować.

Jeżeli Asana jest jednym z dwóch kandydatów, zacznij od przewodnika po tym, jak działa w pracy zespołu. Nie kupuj wyższego planu tylko dlatego, że ma dłuższą listę funkcji. Najpierw sprawdź, czy potrzebujesz portfolio, raportów, zależności i reguł w swoim procesie.

Co firmy próbują zastąpić programem do projektów?

Najczęściej nie jest to inne narzędzie projektowe. W analizie 90 zakodowanych opisów obecnego sposobu pracy z rozmów o wdrożeniach Asany częściej wracały arkusze, poczta i Microsoft 365. Jeden opis mógł zawierać kilka rozwiązań, więc poniższe liczby są liczbą wzmianek, a nie liczbą firm.

Liczba wzmianek, nie liczba firm — jeden opis mógł wymienić kilka rozwiązań naraz. Trzy najczęstsze odpowiedzi to narzędzia, których nikt nie kupił do prowadzenia projektów.

To zmienia kolejność wyboru. Najpierw nazwij, czego nie da się już ustalić w obecnym układzie. Dopiero później porównuj aplikacje. Jeżeli problemem jest brak właściciela albo różne rozumienie statusu, migracja do nowego systemu tylko przeniesie ten sam spór do nowych kolumn.

Jak przetestować program przed zakupem?

Przetestuj jeden powtarzalny projekt od początku do końca. Wybierz taki, który ma wyraźny start, kilka przekazań między osobami i wynik możliwy do odebrania. Nie zaczynaj od projektu wyjątkowego, bo zbudujesz system pod przypadek, który nie wróci.

Jeżeli na krótkiej liście zostały dwa programy, przeprowadź w obu ten sam scenariusz. Użyj tych samych etapów, ról i danych wejściowych. Inaczej porównasz dwa różne pomysły na proces, a wynik przypiszesz aplikacji. Nie testuj też samych widoków na pustym koncie. Narzędzie zaczyna pokazywać swoje ograniczenia dopiero wtedy, gdy jedna osoba czeka na drugą, termin się przesuwa i manager chce odczytać status bez pytania prowadzącego.

1. Spisz etapy i warunek zakończenia każdego z nich.
2. Ustal jednego właściciela każdego następnego kroku.
3. Wpisz tylko terminy i pola, z których ktoś korzysta przy decyzji.
4. Przeprowadź przez szablon jeden realny projekt.
5. Zapisz każde miejsce, w którym zespół wrócił do maila, arkusza albo rozmowy.
6. Po zakończeniu usuń elementy, których nikt nie użył, i dopiero wtedy testuj drugi projekt.

Na jednym z wdrożeń każdy członek zespołu uruchomił nowy szablon na jednym kliencie. Po tygodniu lub dwóch zespół wiedział, czego brakuje i co trzeba uprościć przed kopiowaniem wzorca dalej. Taki test mówi więcej niż prezentacja dziesięciu widoków na danych demonstracyjnych.

Kiedy nie potrzebujesz nowego programu?

Nowy program nie jest potrzebny, jeśli jedna osoba prowadzi kilka niezależnych zadań, status widać w krótkiej liście, a praca rzadko przechodzi między ludźmi. W takim układzie wspólny arkusz, Planner albo Trello mogą wystarczyć.

Nie potrzebujesz też migracji, gdy obecne narzędzie ma wszystkie potrzebne funkcje, a problemem są nieustalone zasady. Najpierw nazwij właścicieli, statusy i warunki zakończenia etapów. Jeżeli firma ma już Asanę, ale każdy dział zbudował w niej co innego, sensowniejszy może być audyt procesów w Asanie niż zakup kolejnego systemu.

Jeśli wybór wskazuje na Asanę

Na co dzień wdrażam Asanę w firmach, które prowadzą wiele podobnych projektów i chcą widzieć ich status bez odtwarzania go na odprawie. Zaczynam od wybranego procesu, buduję szablon na prawdziwych projektach i usuwam wszystko, czego zespół nie używa.

Jeżeli ten sposób pasuje do Twojej sytuacji, sprawdź wdrożenie Asany ze szkoleniem zespołu. Jeśli nie wiesz jeszcze, czy potrzebujesz wdrożenia, audytu czy prostszego narzędzia, możesz też umówić 30 minut rozmowy.