Spis treści5 sekcji
Jeden Project Manager prowadzi budżet w arkuszu. Drugi kontroluje głównie terminy i zadania. Trzeci regularnie analizuje czas pracy, ale nie przypisuje kosztów zespołu do projektu. Czwarty reaguje dopiero wtedy, gdy pracownicy zgłaszają przeciążenie albo klient zaczyna kwestionować zakres.
Każda z tych osób może skutecznie prowadzić własne projekty. Problem zaczyna się wtedy, gdy zarząd chce porównać ich wyniki.
Dane mają różną strukturę, statusy znaczą coś innego, a informacje o kosztach i ryzykach są zbierane w odmiennych momentach. Jeden projekt jest uznawany za zagrożony po przekroczeniu budżetu godzinowego, inny dopiero po spadku marży, a jeszcze inny na podstawie subiektywnej oceny Project Managera.
Wiemy, jak to jest, gdy kontrola projektu zależy od doświadczenia konkretnej osoby. Dopóki firma jest mała, właściciel może osobiście dopytać o najważniejsze kwestie. Wraz ze wzrostem liczby klientów i zespołu taki model przestaje działać.
Dlatego procedury w software house nie powinny być rozbudowanym zbiorem dokumentów, których nikt nie czyta. Ich zadaniem jest ujednolicenie kluczowych decyzji, danych i etapów kontroli, aby każdy projekt był oceniany według tych samych zasad.
Jeden Project Manager prowadzi budżet w arkuszu. Drugi kontroluje głównie terminy i zadania. Trzeci regularnie analizuje czas pracy, ale nie przypisuje kosztów zespołu do projektu. Czwarty reaguje dopiero wtedy, gdy pracownicy zgłaszają przeciążenie albo klient zaczyna kwestionować zakres.
Dlaczego różne sposoby prowadzenia projektów utrudniają zarządzanie software house’em?
Swoboda Project Managerów może być wartością. Każdy klient i projekt mają inną specyfikę, dlatego nie wszystkie działania da się ujednolicić.
Problemem nie jest indywidualny styl pracy. Problemem jest brak wspólnych standardów dotyczących danych, budżetu, ryzyka i rentowności.
Projekty są nieporównywalne
Jeżeli każdy Project Manager używa innych statusy, kategorii i sposobów raportowania, zarząd nie może szybko porównać:
- wykorzystania budżetów,
- marży projektów,
- kosztu pracy zespołu,
- liczby dodatkowych godzin,
- zakresu pozostałego do wykonania,
- ryzyka opóźnienia,
- wysokości należności,
- kosztu potrzebnego do zakończenia.
Jeden raport może pokazywać liczbę godzin, drugi procent wykonania, a trzeci wyłącznie listę otwartych zadań.
Każdy z nich może być poprawny, ale razem nie tworzą spójnego obrazu firmy.
Problemy są zgłaszane w różnych momentach
Doświadczony Project Manager może zauważyć spadek rentowności na podstawie kilku sygnałów:
- rosnącej liczba poprawek,
- większego zaangażowanie seniorów,
- opóźnień po stronie klienta,
- przekraczania estymacji,
- niepełnego raportowania czasu.
Mniej doświadczona osoba może zauważyć problem dopiero wtedy, gdy projekt wykorzysta cały budżet.
Jeżeli firma nie ustalić wspólnych progów ostrzegawczych, szybkość reakcji zależy od intuicji i kompetencji konkretnego pracownika.
Właściciel musi ręcznie zbierać informacje
Przy braku standardu zarząd często zadaje każdemu Project Managerowi osobne pytania:
- Ile godzin już wykorzystaliśmy?
- Jaka jest aktualna marża?
- Co zostało jeszcze do wykonania?
- Czy klient zaakceptował dodatkowy zakres?
- Ile zostało zafakturowane?
- Czy płatności wpłynęły?
- Jakie koszty pojawią się do końca projektu?
Informacje są dostępne, ale wymagają rozmów, wiadomości, arkuszy i ręcznego łączenia danych.
Właściciel nie zarządza wtedy portfelem projektów. Zajmuje się zbieraniem podstawowych informacji operacyjnych.
Zastępowalność Project Managerów jest ograniczona
Jeżeli sposób prowadzenia projektu istnieje głównie w głowie jednej osoby, jej nieobecność powoduje chaos.
Osoba przejmująca projekt musi ustalić:
- co oznaczają poszczególne statusy,
- gdzie znajduje się aktualny budżet,
- które ustalenia z klientem są wiążące,
- jakie zmiany zostały dodatkowo wycenione,
- ile godzin pozostało,
- które faktury zostały wystawione,
- jakie ryzyka wymagają reakcji.
Brak wspólnego standardu zwiększa zależność firmy od pojedynczych pracowników i utrudnia przekazywanie projektów.
Firma nie może uczyć się na własnych danych
Jeżeli dane z projektów są zbierane inaczej, trudno przeprowadzić analizę historyczną.
Firma nie potrafi jednoznacznie określić:
- które typy projektów są najbardziej rentowne,
- jakie etapy najczęściej przekraczają budżet,
- gdzie pojawia się scope creep,
- którzy klienci wymagają najwięcej dodatkowej pracy,
- jakie estymacje są regularnie zaniżane,
- które modele rozliczeń generują najlepszy wynik.
Bez porównywalnych danych każdy nowy projekt jest planowany niemal od początku.
Jak wdrożyć procedury w software house bez tworzenia biurokracji?
Standaryzacja nie powinna oznaczać opisywania każdej możliwej sytuacji. Najlepiej zacząć od kilku elementów, które mają największy wpływ na wynik finansowy i bezpieczeństwo realizacji.
1. Ustal wspólne etapy prowadzenia projektu
Każdy projekt powinien przechodzić przez podobny cykl, nawet jeśli jego zakres i technologia są inne.
Przykładowe etapy:
- Kwalifikacja i wycena.
- Przekazanie ze sprzedaży do realizacji.
- Planowanie budżetu oraz zespołu.
- Realizacja i bieżąca kontrola.
- Zarządzanie zmianami zakresu.
- Odbiór i fakturowanie.
- Zamknięcie oraz analiza rentowności.
Dla każdego etapu warto określić:
- wymagane dane,
- osobę odpowiedzialną,
- warunek rozpoczęcia,
- warunek zakończenia,
- decyzje wymagające akceptacji.
Dzięki temu projekt nie przechodzi do realizacji bez budżetu, właściciela, harmonogramu i ustalonego sposobu fakturowania.
2. Ujednolić statusy i kategorie
Status powinien mieć takie samo znaczenie we wszystkich projektach.
Można wprowadzić wspólne statusy, na przykład:
- planowany,
- oczekuje na rozpoczęcie,
- w realizacji,
- oczekuje na klienta,
- zagrożony,
- wstrzymany,
- zakończony,
- zamknięty finansowo.
Podobnie warto ujednolicić kategorie czasu i kosztów:
- development,
- design,
- testy,
- zarządzanie projektem,
- komunikacja z klientem,
- poprawki błędów,
- dodatkowy zakres,
- działania wewnętrzne.
Dzięki temu dane z kilku projektów można zestawić bez ręcznego tłumaczenia, co oznaczają lokalne oznaczenia.
3. Zdefiniuj obowiązkowe wskaźniki projektowe
Każdy Project Manager powinnik regularnie kontrolować ten sam zestaw informacji.
Najważniejsze wskaźniki mogą obejmować:
- wartość kontraktu,
- kwotę zafakturowaną,
- wartość otrzymanych płatności,
- planowany budżet godzinowy,
- wykorzystane godziny,
- rzeczywisty koszt pracy,
- koszty zewnętrzne,
- koszt potrzebny do zakończenia,
- bieżąca marżę,
- prognozowaną marżę,
- cash gap,
- wartość dodatkowego zakresu.
Nie oznacza to, że wszystkie projekty muszą mieć identyczny budżet. Chodzi o to, aby ich wynik był oceniany według tych samych parametrów.
4. Ustal progi wymagające reakcji
Sam raport nie zabezpiecza projektu. Potrzebne są zasady określające, kiedy Project Manager powinien podjąć działanie albo eskalować problem.
Przykładowe progi:
- wykorzystano 70% godzin, ale ukończono mniej niż połowę zakresu,
- prognozowana marża spadła poniżej minimalnego poziomu,
- klient nie zaakceptował etapu w ustalonym terminie,
- dodatkowe prace przekroczyły ustalony bufor,
- należność pozostaje nieopłacona, a zespół realizuje kolejny etap,
- koszt seniorów jest wyższy niż w estymacji,
- projekt generuje ujemny cash gap.
Każdy próg powinien mieć przypisaną reakcję, na przykład:
- weryfikację pozostałego zakresu,
- zatrzymanie prac dodatkowych,
- rozmowę z klientem,
- nową wycenę,
- zmianę składu zespołu,
- aktualizację harmonogramu,
- eskalację do właściciela lub dyrektora operacyjnego.
Jak rozwiązaliśmy standaryzację projektów w Administy?
Prowadząc agencje i projekty cyfrowe, widzieliśmy, że każdy Project Manager ma własny sposób pracy.
Jedna osoba bardzo dokładnie kontrolowała czas, ale rzadziej analizowała wpływ kosztów zewnętrznych. Inna dobrze zarządzała relacją z klientem, lecz dane finansowe aktualizowała okresowo. Kolejna prowadziła rozbudowany arkusz, którego struktura była zrozumiała głównie dla niej.
Każdy projekt mógł być prowadzony poprawnie, ale dane nie były porównywalne.
Gdy chcieliśmy ocenić cały portfel, musieliśmy najpierw ustalić:
- gdzie znajduje się aktualna wersja danych,
- jakie koszty zostały uwzględnione,
- co oznacza konkretny status,
- czy czas pracy jest kompletny,
- jak została policzona marża,
- czy uwzględniono koszt zakończenia,
- czy dodatkowe prace są oddzielone od podstawowego zakresu.
Kontrola zależała więc od doświadczenia konkretnej osoby oraz jakości przygotowanego przez nią raportu.
Dlatego w Administy wprowadziliśmy wspólne:
- kategorie projektów,
- typy umów,
- statusy realizacji,
- etapy kontroli,
- kategorie kosztów,
- wskaźniki finansowe,
- zasady przypisywania czasu i wydatków.
Każdy projekt jest analizowany według podobnego schematu.
W jednym miejscu widzimy:
- wartość kontraktu,
- wystawione faktury,
- otrzymane płatności,
- planowany budżet,
- czas pracy zespołu,
- indywidualny koszt specjalistów,
- faktury podwykonawców,
- koszty dodatkowe,
- marżę bieżącą,
- marżę prognozowaną,
- cash gap,
- środki potrzebne do zakończenia projektu.
Czas pracy importowany z systemu projektowego jest przeliczany na koszt według stawek konkretnych osób. Przychody i wydatki są przypisywane do właściwego projektu, a dodatkowy zakres może być analizowany oddzielnie od podstawowej realizacji.
Dzięki temu każdy Project Manager pracuje na wspólnej definicji wyniku.
Projekt nie jest uznawany za bezpieczny tylko dlatego, że zadania są realizowane zgodnie z harmonogramem. Musi również spełniać ustalone kryteria finansowe.
Standaryzacja pomaga nam zauważyć między innymi, że:
- projekt realizowany terminowo traci marżę,
- dodatkowe godziny nie zostały wycenione,
- zespół wykorzystuje droższe zasoby, niż planowano,
- faktury nie pokrywają dotychczasowych kosztów,
- klient opóźnia płatność, ale realizacja nadal trwa,
- koszt potrzebny do zakończenia przekracza pozostały budżet.
Wspólne dane ułatwiają też przekazywanie projektów. Nowa osoba nie musi odtwarzać sposobu pracy poprzedniego Project Managera. Otrzymuje projekt ze znanymi statusami, wskaźnikami i etapami kontroli.
Najważniejsza zmiana polega na odejściu od pytania:
„Czy Project Manager ma projekt pod kontrolą?”
na rzecz pytań:
- Jaki jest aktualny koszt?
- Jaka jest prognozowana marża?
- Ile pracy pozostało?
- Jakie ryzyka przekroczyły ustalony próg?
- Jakiej decyzji wymaga projekt?
Odpowiedzi nie zależą wtedy wyłącznie od opinii osoby prowadzącej projektu.
Standaryzuj dane i decyzje, nie osobowość Project Managera
Dobre procedury nie powinnie odbierać Project Managerom elastyczności. Klienci, technologie i zespoły nadal wymagają indywidualnego podejścia.
Standaryzacji powinny podlegać przede wszystkim:
- najważniejsze dane,
- etapy kontroli,
- wskaźniki finansowe,
- progi ostrzegawcze,
- zasady eskalacji,
- sposób zamykania projektu.
Procedury w software house mają sprawić, że firma może porównywać projekty, szybciej wykrywać ryzyko i utrzymywać kontrolę niezależnie od tego, kto aktualnie odpowiada za realizację.
Uporządkuj sposób kontroli wszystkich projektów
Administy pomaga połączyć czas pracy, koszty, faktury, płatności, marżę i cash gap według wspólnego standardu.
Umów prezentację Administy i zobacz, jak stworzyć jeden model kontroli projektów, bez odbierania Project Managerom swobody działania.
