IT Project
Zarządzanie organizacją i Projektami IT
Permanentne urealnianie budżetu Projektu
Po co permanentnie urealniać raz ustalony budżet Projekt? A po to, aby elastycznie, dynamicznie i realnie zarządzać Projektem, lepiej planować przychody, koszty, zasobowanie w Projekcie i w organizacji Dostawcy. Jak również jest to informacja zwrotna do osób decyzyjnych o tym jak może się skończyć Projekt.
Trzy kroki do permanentnego urealniania budżetu Projektu.
Pierwszy krok to pomysł na Projekt
Pomysł na Projekt rozumiem jako wizję Stron (Klienta i Dostawcy) w jaki sposób zamierzają zrealizować Projekt. Czyli co będzie realizowane najpierw, co później, co równolegle, gdzie są Kamienie Milowe, gdzie jest ścieżka krytyczna dla danego Projektu i na jakie Ryzyka Projekt jest narażony. Pomysł na Projekt to niekoniecznie jest wspaniały i szczegółowy harmonogram, bo to jest część operacyjna. W idealnych warunkach taki pomysł powinien powstać już na etapie presales, ale jak wiadomo rzadko tak się dzieje. Dlatego na początku Projektu należy taką wizję opracować i „sprzedaż” do zespołów projektowych i organizacji Klienta. Pisząc „sprzedać” mam na myśli, że wszystkie zainteresowane osoby rozumieją tę wizję, identyfikują się z nią i będą ją wspierać podczas prac projektowych. Ktoś spyta, dlaczego to takie ważne? Odpowiadam, bo od tego zależy poparcie dla Projektu, budżet, harmonogram i zasobowanie na Projekcie. Aby zilustrować to, podam przykład. Mamy do wdrożenia system w 3 spółkach. I taki Projekt można zrealizować na wiele sposobów i w wielu budżetach i harmonogramach:
1. Wszystkie firmy równocześnie (tzw. big bang).
2. Firma po firmie (jako niezależnie wdrożenia)
3. Wypracowanie modelu (w tym współdzielonych danych) i wdrożenie w pierwszej firmie, a potem rollout na kolejne spółki
4. Wdrożenie paru modułów (najczęściej finanse), ich stabilizacja, potem kolejne moduły.
5. i pewnie z 5 innych pomysłów
W każdym z powyższych przykładów będzie nieco inna analiza, inne podejście do testów, szkoleń, budowania interfejsów i rozwiązań (np. tymczasowych dla pkt 3 powyżej) itd. Bez takiej ogólnej wizji trudno zaplanować budżet, harmonogram oraz zasobowanie na projekcie, które potem będzie faktycznie realizowalne.
PS Taka wizja może być traktowana jako drogowskaz projektowy, jak również jako ogólne informowanie osób w projekcie i poza projektem, w którym miejscu jest projekt (co poprawia komunikację i tworzy przestrzeń do marketingu projektowego).
Drugi krok to szacowanie budżetu Projektu
Jak mamy pomysł na Projekt to możemy go przełożyć na budżet i harmonogram Projektu oraz zaplanować pierwsze zasobowania na Projekt. W Projektach dużych i trwających więcej niż 8 miesięcy nie zawsze znamy szczegółowy zakres prac, bo te pojawią się w trakcie realizacji. W związku z tym trudno jest przypisać zasoby. Do tego dochodzi pewna dynamiczność zwalniania prac do realizacji (w szczególności, gdy projekt jest realizowany metodyką Agile). Dlatego jest konieczność podejść do tematu szacowania budżetu w sposób mieszany tzn. część budżetu Projektu wycenić ogólnie, a część szczegółowo.
Szacowanie ogólne
W zakresie Projektu, gdzie nie ma pewności co do zakresu, budżetu, harmonogramu, czy możliwości zdefiniowania zasobów.
Tu można oprzeć się o zakładaną liczbę godzin oraz średnie stawki dla tego typu zadań. Jednak trzeba się wtedy liczyć z dużym marginesem błędu dochodzącym do 50% (patrz link). Aby nieco urealnić budżet można:
1. Stworzyć budżety godzinowe na te prace w oparciu o wiedzę jaką posiadamy
2. Oprzeć się o stawki kosztowe ról jakie będą niezbędne do realizacji zadań
3. Zawiązać budżet na niedoszacowania budżetu w tym zakresie.
Przy okazji, taka refleksja. Planowanie Projektu wg liczby etatów jakie będą potrzebne do realizacji Projektu, to nie jest dobre podejście. Nie uwzględnia faktycznych potrzeb Projektu, dynamiki Projektu. To bardziej wizja Resource Managera „utylizacji” zasobów na projekcie niż realna szansa na zarządzanie zasobami na Projekcie.
Szacowanie szczegółowe
W zakresie budżetu, gdy mamy wiedzę lub uzgodnienia z Umowie co do zakresu i możemy zdefiniować zadania oraz konkretne zasoby do ich realizacji. Takie budżetowanie potem wyceniamy wg stawek kosztowych wskazanych zasobów (lub stawek w dziale, z którego pochodzi zasób, stawek roli w jakiej pracuje zasobów to w przypadku firm, które mają problem z ujawnianiem realnych stawek zasobów).
Szacowanie uzupełniające
1. Budżet zapasowy
Do wykorzystania lub nie w Projekcie przez PMa, związany z prawdopodobieństwem realizacji zadań dodatkowych w Projekcie (np. szacowanego na początku budżetu Modyfikacji, „szarych” zapisów z Umowy itp.
2. Budżet Ryzyka umowy
Budżet Ryzyka związany z Klientem, zapisami Umowy nie związanymi bezpośrednio z pracami projektowymi, specyfiką Projektu, które nie uwzględniony w pkt 3a.
3. Budżet premiowy
Dobrą praktyką jest uwzględnienie takiego budżetu. Osobą kwestią jest sprawa jego upublicznienia i sposób zarządzania nim.
4. Budżet inwestycyjny
Budżet związany z inwestycją Dostawcy w Projekt (np. pozyskanie wiedzy, nowego Produktu czy usługi, referencji itp.)
Tak oszacowane przychody, koszty oraz marża stają się bazowym budżetem Projektu.
Mała uwaga: W przypadku ujemnej marży, powinien być zawiązany budżet inwestycyjny w wysokości powodującej wyzerowanie marży, bo de facto nim jest. Taki zabieg ma na celu świadome określenia budżetu jaki Dostawca zamierza zainwestować w Projekt, a PM informację na jaki budżet ma zgodę. Jego późniejsze ewentualne zmniejszenie powinno być traktowane jako „dodatkowy zysk” na projekcie wygenerowany przez zespół projektowy Dostawcy.
Trzeci krok to permanentne urealnianie budżetu Projektu
Na etapie realizacji, w analizie ilościowo-wartościowej Projektu, planowane wartości są sukcesywnie zastępowane rzeczywistymi wartościami. Na kolejny miesiąc w przód zadania są planowane w trybie planowania szczegółowego (tzn. zadania ogólnie są zastępowane konkretnymi zadaniami i przypisanymi konkretnymi zasobami realizacyjnymi). Pozostał części Projektu pozostaje wg bazowych założeń o ile nie ma konieczności zmian w tym zakresie. W ten sposób powstaje co miesięczna aktualizacja szacowanego budżetu i marży Projektu. Takie podejście pozwala dynamicznie zadaniami, zasobami po stronie Dostawcy i jednocześnie posiadać urealniony budżet Projektu. Można w tych działaniach pójść jeszcze dalej i jeszcze bardziej go doprecyzować. W systemie IMS4POs planowanie jest oparte na kilku poziomach. Główne planowanie odbywa się na US (User Story), w podziale na T&M (Time & Material) oraz FP (Fixed Price) i wskazaniem na część płatną i nie płatną godzin. W ten sposób można zaplanować budżety poszczególnych zadań całościowych w Projekcie (np. analizy, szkoleń, migracji itd.). Dodatkowo PM ma możliwość „zejścia” z planowaniem operacyjnym do poziomu zlecanych zadań, przypisując poszczególnym zadaniom budżety wykonawcze - OE (Orginal Estimate) również w podziale na godziny płatne i niepłatne. Wykonawca zadania zwrotnie wypełnia CW (Completed Work), godziny jakie już poświęcił na zadanie oraz szacowane godziny aby dokończyć zadanie RW (Remaining Work). Bazując na powyższych mechanizmach system IMS4POs może przeprowadzić symulację wyników projektu w 4 scenariuszach:
1. Szacowanie budżetu i marży wg budżetów US oraz CW
W tej symulacji, wartości ilościowe i wartościowe budżetu US dla okresów zrealizowanych są zastępowane wartościami rzeczywistymi (CW), a pozostała część jest wg budżetu US oryginalnego. W ten sposób uzyskujemy urealnienie budżetu Projektu uwzględniające rzeczywisty stan już zrealizowanych
2. Szacowanie budżetu i marży wg budżetów US oraz CW, RW
Tak jak w punkcie 1 powyżej, ale z uwzględnieniem wartości RW. Ta perspektywa może nam pokazać budżet z punktu widzenia nie dokończonych prac. Co jak znam życie nie jednego może zaskoczyć i pokazać nadchodzący sukces lub problem w Projekcie.
3. Szacowanie budżetu i marży wg budżetów US i CW oraz efektywnych stawek
Część zrealizowana Projektu jest traktowana jak w pkt 1. Natomiast część nie zrealizowana jest szacowana wartościowo wg efektywnych stawek kosztowych i przychodowych. Czyli to może dać odpowiedź odpowiedź na pytanie, jak może zakończyć się projekt, jeśli będziemy utrzymywać dotychczasowe parametry Projektu. Taka symulacja jest przydatna w projektach z dużą liczbą godzin, jak również, gdy nie do końca wiadomo, ile godzin ostatecznie będzie w Projekcie.
4. Szacowanie budżetu i marży na podstawie CW, RW oraz efektywnych stawek
Jak w pkt 3 powyżej z uwzględnieniem RW, a wnioski jak w pkt 2 i 3 powyżej
Oczywiście scenariuszy jest więcej. Choćby można bazować na wartości wypracowanej w oparciu o EVM (Earned Value Management i wskaźników EV, PV, AV itd).
Reasumując: Szacowanie budżetu i jego sukcesywne przeszacowywanie w trakcie realizacji Projektu pozwala na lepszą kontrolę ilościowo-wartościową Projektu i predykcję w jakim kierunku zmierza Projekt. Na czas podjąć odpowiednie działania zapobiegawcze. Przy odpowiednim systemie wspierającym taką filozofię prowadzenia Projektu, nakład pracy wcale nie musi to być duży. Za to pozyskana informacja może być niezwykle cenna.
Jak zawsze zachęcam do współpracy. W kolejnych wpisach chciałby nieco przybliżyć filozofie i rozwiązanie IMS4POs (Integrated Management System for Project Organizations).
PS
EVM w klasycznym ujęciu wydaje mi się nie do końca prawidłowe i skuteczne. Zakłada ono, że porównujemy to co sobie założyliśmy z tym co mamy na dany moment. To trochę tak jakbyśmy nasze marzenia i porównywali do rzeczywistości. A nam chodzi o to, aby ocenę projektu opierać o rzeczywistość projektową. Dlatego nieco inaczej podchodzę to tematu, przypisując poszczególnym Produktom Projektu schematy ich dostawy (wskaźniki zaawansowania w procesie dostarczaniu Produktu, które potem są uwzględniane w wyliczaniu faktycznej wartości wypracowanej), ale to jest już osobne zagadnienie
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.