IT Project

Zarządzanie organizacją i Projektami IT

W poprzednim artykule przedstawiłem wybrane aspekty kontekstu związanego ze wskaźnikami (zachęcam do zapoznania się z nim). Teraz czas na wskaźniki i miary, które warto liczyć zawsze. Zarówno dla Projektów jak i dla organizacji. Tak, aby świadomie podejmować decyzje biznesowe w oparciu o fakty. Zapraszam.

Dla Projektów IT najważniejszą sprawą jest jego, jak to się popularnie mówi, „dowiezienie”. Razem z zakładanymi celami i parametrami. To takie minimum minimorum. Oczywiście, aby to spełnić najpierw trzeba określić te cele i parametry, a następnie umieć je monitorować, kontrolować i na bieżąco podejmować działania korygujące czy zapobiegawcze. Dla firm aspirujących bycia liderem to może być nie wystarczające, ponieważ Projekt powinien przynosić również długofalowe korzyści. Zostawiać po sobie doświadczenie, know-how, Produkty i Usługi do wykorzystania w kolejnych projektach oraz działania mające na celu poprawę organizacji jak i realizację przyszłych projektów (o czy jeszcze chciałbym napisać w osobnym artykule).

Z perspektywy mojego doświadczenie poniżej przedstawiam podstawowe parametry, które moim zdaniem powinny być zawsze liczone (no może z wyjątkiem małych, szybki projektów czy przedsięwzięć).

1. Globalna statystyka Projektu.

1.1 Zysk (Profit), Marża (Margin), Narzut (Markup)

Te miary i wskaźniki służą głównie do oceny zasadności ekonomicznej prowadzonego Projektu po stronie Dostawcy. Przy czym Zysk jest miernikiem bezwzględnej wartości jaką Dostawca zarabia lub traci. Natomiast Marża i Narzut są wskaźnikami umożliwiającymi porównywanie Projektów oraz ocenę „atrakcyjności” Projektu dla organizacji Dostawcy.

UWAGA. Te wskaźniki są wyrażane procentowo, a więc czasem mogą być mylnie interpretowane np. że jak jest duży procent to jest ok, a jak mały to nie jest ok. Bez dodatkowej informacji od jakiej wartości tenże procent został policzony (czyli kontekstu), taka interpretacja nie jest uprawniona. Dlaczego? Bo jeśli wartość bazowa jest mała to łatwo ją zwiększyć, a wtedy procent wychodzi nadzwyczaj atrakcyjnie. Poza tym nie z procentu marży firma żyje, ale z bezwzględnej wartości zysku jaki Projekt przynosi. 

UWAGA. To jak wyceniane są koszty (a tym samym wskaźniki powiązane z nimi) zależy od przyjętej przez Dostawcę metody wyceny Projektów. We wszystkich przykładach w niniejszym artykule, oparto się o koszty bezpośrednie zasobów, czyi koszty brane pod uwagę przy liczeniu marży GM1. Jednak wcale tak nie musi być. Można stosować różne stawki i liczyć Projekt uwzględniając koszty jakie brane są pod uwagę przy należeniu kolejnych marż (GMx) lub uśrednionych wartości dla zespołów, ról itd. Jednak moim zdaniem najlepiej jest to liczyć jak w przykładach, ponieważ to pozwala na realną optymalizację kosztów realizacji zadań przez daną osobę w powiązaniu z jej kosztem dla firmy. Poza tym inne stawki mogą nieco (lub bardzo) fałszować "rzeczywistość kosztową" Projektu. Dlaczego? Może być tak, że np. mamy dwie osoby w zespole z kosztami X i 2xX. Przy średniej stawce wyjdzie nam stawka kosztowa 1.5X. Jeśli takiej stawki użyjemy do budżetowania Projektu, wyceny prac w Projekcie to błąd może sięgnąć 50% i całkowicie zakłamać faktyczny stan finansowy Projektu. Pomijam jeszcze inne zjawisko, że osoba która widzi, że ma Y godzin na zadanie, na pewno zrobi je w Y godzin i w swoich pracach nie uwzględni, że jego 2 razy większe koszty są prawdopodobnie związane z jego kompetencjami, a więc takie zadanie powinien zrobić szybciej, albo po prostu nie powinien dostać do realizacji, o ile jest alternatywa wykonawcza w postaci mniej kosztownych osób.

1.2 Budget bill hours, Budget nonbill hours…

To są budżety godzinowe na Projekcie. Odpowiednio, godzin płatnych (bill) i niepłatne (nonbill). Te dwie wartości (bill i nonbill) powinny być zawsze analizowane, monitorowane i kontrolowane osobno. Tylko w podsumowaniach można je pokazać sumarycznie. Szczególną uwagę powinniśmy zwracać na godziny niepłatne. To te godziny są czystym kosztem dla Dostawcy (np. planowane niezbędne prace nie obciążające Klienta, dodatkowe koszty do Produktów rozliczanych w trybie Fixed Price, inwestycji itd.). Jednak w życiu projektowych czasem tam są "ukrywane" koszty rozwiązywania problemów, popełnianych błędów, braku wiedzy zespołu itd. Tego typu koszty jeśli są planowane i monitorowane są ok. Gorzej jak się wymkną spod kontroli.

1.3 Remainig bill hours, Remaining nonbill hours

Ważna informacja wynikająca z oceny wykonawców zadań w Projekcie, ile jeszcze godzin zamierza poświęcić na dokończenie rozpoczętych działań w Projekcie. Bez tego trudno przewidywać problemy z wyprzedzeniem, bo może być tak że analizując wykonane prace jest ok, ale patrząc ile jest jeszcze do dokończenia, aby zamknąć temat, to może się okazać, że kłopoty są tuż za rogiem.
UWAGA. Ramainig - to nie jest wartość wynikającą z prostego odejmowania budżetu zadania i zrealizowane godziny, bo to co prawda też jest informacja (którą PM może sam sobie obliczyć), ale pozbawiona elementu związanego z oceną wykonawców tego co wykonawca jeszcze "widzi", że jest do zrobienia, aby domknąć zadanie. Bez tego nie ma możliwości wykryć nadciągających problemów w Projekcie i z wyprzedzeniem odpowiednio zareagować. 

1.4 Estimate bill hours, Estimate nonbill hours

Uzupełniająca informacja jakie budżety operacyjne zostały oszacowane dokładnie z uwzględnieniem realiów Projektu oraz wykonawcy w kontekście danego US nad którym pracuje zespół.

To może być przydatna informacja do oceny jak dużo prac może być lub jest już operacyjnie skierowanych do realizacji, a przy uwzględnieniu już wykonanej pracy, jak dużo jeszcze jej pozostało. Cenna informacja podczas dużych zmian w Projekcie, wstrzymania Projektu, czy odmrażaniu Projektu, słowem dużych zmian w Projekcie.

UWAGA: wartość Estimate - to nie jest estymacja do końca Projektu. O takiej wartości będzie osobny artykuł, bo to jest wielowymiarowy i dość złożony temat.

1.5 Budget Effective Rate (income/cost)

Czyli jakie stawki godzinowe (przychodów i kosztów) faktycznie były planowane, a jakie rzeczywiście są realizowane w Projekcie. To są wskaźniki głównie dedykowane PMowi (np. do aktywnego zarządzania przychodami i kosztami Projektu) oraz zarządowi, a nawet działowi handlowemu (np. pomocne w negocjacjach z Klientem lub nowymi kontraktami). To też dobra informacja do obiektywnego porównywania Projektów w zakresie stawek i "wyłapywania" Projektów, gdzie warto się zastanowić nad ich poważną zmianą lub sensownością ich kontynuacji (polecam mój inny artykuł)

1.6 Budget Effective bill

Podobny wskaźnik jak w pkt 5 powyżej, ale odnoszący się do poziomu „bilowalności” godzinowej Projektu. Czyli jaki udział mają godziny płatne we wszystkich godzinach poświęconych na Projekt. Ten wskaźnik pozwala ocenić na ile skutecznie udaje się sprzedawać wszystkie godziny w Projekcie. Sprawdzenia, czy czasem liczba godzin niepłatnych nie wymyka się nam spod kontroli. To również dobry wskaźnik do porównywania Projektów np. ile trzeba średnio doliczać kosztów związanych z niepłatnymi godzinami do Projektu, jak również do liczenia stawek przychodowych z uwzględnieniem tej wartości (bo wychodzi nam z analizy, że one zawsze istnieją) itd.

1.7 Number of Objects, Number of Objects per Person

To są wskaźniki przede wszystkim pokazujące jak zakresowo i organizacyjnie jest „duży” Projekt. To też może być informacja do oceny, jak bardzo osoby na Projekcie są dobrze lub źle zarządzane (np. jest bardzo dużo zadań, bo jest mikro management lub nie wiele, co może uniemożliwiać realną ocenę stanu prac w Projekcie (np. zadnie na 200 godzin - praca nad koncepcją - co z tego wynika? Raczej nie wiele). Poza tym, można też w jakimś zakresie użyć do obiektywnego porównania "wielkości" Projektów (co szczególnie ważne w rozmowach z zarządem czy działem handlowych, którym często się wydaje, że jakiś Projekt jest "duży", a jakiś inny "mały"  - kto robi projekty wie o czym tu mowa.)

Podsumowanie

Pkt 1 Służy do ogólnej oceny części finansowej Projektu. Pkt 2-5 służą do oceny części godzinowej (organizacyjnej) Projektu.

Z praktyki wiem, że są firmy (Dostawcy), które zarządzają wew. projektami wyłącznie poprzez część godzinową, a z Klientami rozliczają się z godzin płatnych. Niestety takie podejście, moim zdaniem, nie pozwala PMowi na kreatywne podejście do części finansowej Projektu po stronie Dostawcy. Jeśli PM ma jedynie informację o godzinach to nie ma możliwości sensownie optymalizować przychodów. Po prostu, brak mu kontekstu finansowego Projektu, więc może jedynie skupić się na przysłowiowym pilnowaniu godzin. Z tego czasem powstają Projekty, godzinowo udane, ale finansowo to już nie koniecznie, bo np. najdroższe zasoby wykonują prace, które z powodzeniem mogłyby wykonać inne osoby, czytaj tańsze.

Oczywiście to są generalne parametry pozwalające ocenić generalny stan godziono-finansowy Projektu, choć to nie wszystko (o czym w kolejnych artykułach)  

2. Szczegółowa analiza

2.1 User Story (US)

W powyższej analizie (patrz screen powyżej) założyłem, że US jest zbiorem rzeczy do dostarczenia w Projekcie (wynikających z Umowy np. deliverables) lub grupą zadań dotyczących jakiegoś zagadnienia w Projekcie (np. wynikających z przyjętej Metodyki – migracja, testy itd.). Dlatego kontrola poszczególnych US jest kluczowa dla całego Projektu. Na tym poziomie powinien operować PM lub osoba odpowiedzialna za dany US (nie tylko merytorycznie ale też za budżet tego US).

2.2 Resources

To jest analiza na ile poszczególne osoby w Projekcie realizują swoje zadania wg założeń (OE - Original Estimate - budżet operacyjny) zarówno w części godzinowej jak i finansowej. Przy czy, w części finansowej, analiza, może pokazać zjawisko, o którym pisałem wcześniej, że godziny się zgadzają, a finanse się nie zgadza. Dodatkową informacją jest sprawdzenie, na ile aktualna wycena Projektu (na poziomie US) jest bliska realizacji tzn. US. 

2.3 Department, Role

Taka sama analiza jak dla US powinna być prowadzona, ale z perspektywy Departamentów oraz Ról przez Resource Managerów oraz do wycen przyszłych Projektów. Z nich można odczytać realną stawkę w Departamencie realizującym Projekt jak i stawkę dla Roli. Analiza taka jest szczególne przydatna gdy można na nią spojrzeć z perspektywy wszystkich Projektów.

Tu mała dygresja. Resource Manager powinien mieć odpowiedzialność nie tylko za "dostarczenie" zasobów na Projekt, ale również za sam Projekt w części związanej z „jakością” prac swoich ludzi w Projekcie oraz ich kosztów. 

2.4 Contract-related budgets

Analiza głównie dla Klienta i PMa prowadzącego u niego Projekt w odniesieniu do Umowy:

1. Część godzinowa

UWAGA: na powyższym screenie, w budżecie Add-ons jest 400%, ponieważ są tu rozliczenia godzin związanych dodatkiem (Add-on) dostarczanym w trybie Fixed Price. w).

2. Część finansowa

Analiza powyższa to może być świetny wsad do raportu o stanie Projektu, odpowiednio dla Klienta i dla zarządu Dostawcy.

Uwaga: to jest prosty ekran, na którym nie widać zagadnień związanych z upustami, pracami w toku, uwzględnieniem CR (Wniosków o zmianę) itd. Do tego są dodatkowe raporty, a to jest operacyjna informacja as-is.

2.5 Deliverables

Dobrze jest, aby w Projekcie od razu analizować Produkty dostarczane w Projekcie oraz gotowe Produkty i Usług (z katalogów Dostawcy).

1. Project Deliverables (T&M)

Czyli Produkty wytwarzane i dostarczane w ramach Projektu (w tym w części wskazane w Umowie z Klientem). Mogą to być Produkty kandydujące do nowych Produktów Dostawcy lub do zastosowania w innych Projektach. Taka analiza daje możliwość np. porównania przychodów i kosztów tych samych Produktów między Projektami i przyczynek do głębszych wniosków, doskonalenia, standaryzacji itd.

2. Catalogue and Fixed Price Deliverables

Czyli Produkty gotowe, dostarczane z katalogu Dostawcy. Taka analiza może służyć do oceny na ile dany Produkt jest kosztowny w implementacji w Projektach. Zabrania wszystkich przychodów i kosztów Produktu, sprawdzenia jego rentowności itd. To jest zakres informacji, którymi powinien być zainteresowany Product Owner.

Natomiast trzeba też zaznaczyć, że do powyższych analiz musi być spełniony pkt 1 z poprzedniego artykułu (jakość danych) oraz odpowiednia metodyka realizacji prac, która pozwoli realizować Projekt, skupić się zespołowi na jego realizacji, a równocześnie nie zamęczyć zespołu liczbą koniecznych danych do wprowadzenia, aby powyższe mierniki i wskaźniki pozyskać.

Jak zawsze zachęcam do współpracy i do następnego artykułu 😊

Oczywiście to nie są wszystkie tematy związane z kontrolą i realizacją Projektu. O tych innych aspektach będzie w kolejnych artykułach. Jak zwykle zachęcam do współpracy.

PS

W artykule wykorzystałem zrzuty części ekranów z mojego autorskiego rozwiązania do zarządzania firmą IT i projektami IT IMS4POs.

#ITProjectManagement #PMO #ProjectManagement #ProjectBudgeting #CostManagement #ProjectFinance #CostOptimization #KPIs #FinanceAnalysis #Profitability #MarginManagement

Zaproszenie

Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.

Zaproszenie

Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.

tel. +48 605-960-037 

jacek.baran@poczta.onet.pl