Świat IT to duża zmienność. Dzisiejsze rozwiązania są już jutro przestarzałe. A rotacja pracowników sięga 20-30%. Zarządzanie kosztami projektu IT to prawdziwy sprawdzian umiejętności i odporności Kierownika Projektu. Zajęcie tylko dla ludzi o mocnych nerwach.
Ale nie musi tak być. Możesz wyjść poza schemat i odwrócić zależności. Założyć, że budżet jest nieprzekraczalny, a zamiast tego…o tym co zrobić przeczytasz w dalszej części artykułu.
Standardowa ścieżka
Typowy proces przygotowywania budżetu w projekcie IT wygląda jak na diagramie poniżej.

Czyli w skrócie:
- Najpierw następuje zebranie oczekiwań, wymagań i wszelkich ograniczeń.
- Potem powstaje projekt rozwiązania.
- Tak przygotowany projekt jest wyceniany.
- Jeżeli są wątpliwości, to zakres jest zmieniany aż do uzyskania akceptacji.
- Po akceptacji budżetu i zakresu rozpoczynają się prace.
- Prace się kończą jak cały zakres zostanie zrealizowany (lub strony zmienią ustalenia).
Kiedy może być problem?
Takie podejście sprawdza się dobrze w przewidywalnych środowiskach. Wtedy zarządzanie kosztami projektu IT jest łatwe i przyjemne.
Gdy projekt zawiera elementy innowacyjne lub zwyczajnie nowe dla zespołu, to może być różnie. Problemy z kosztami projektu pojawią się jeżeli:
- Rozwiązania, które dostarczamy nie realizują założonych celów.
- Rozwiązanie jest ok, ale budowanie go trwa dłużej niż zakładaliśmy.
W pierwszym przypadku utopimy budżet w czymś, co nie będzie potrzebne. W drugim budżet może puchnąć w nieskończoność, poza granice opłacalności.
Przykład
Planowaliśmy wdrożenie ekranów dotykowych aby usprawnić produkcję o 20%. Okazało się, że ze względu na warunki w hali produkcyjnej używanie ekranów dotykowych jest utrudnione. Pracownicy korzystają więc z zewnętrznej klawiatury, co w połączeniu z tabletem spowalnia proces o 10% względem poprzedniego rozwiązania.
Ponieśliśmy więc spore koszty, w zamian nie osiągając celu. Jeżeli zakres jest potwierdzony i nie można go łatwo zmienić, to projekt wygeneruje ogromne straty.
Zarządzanie kosztami projektu IT od drugiej strony
A gdyby tak ustalić, że koszty projektu są stałe i nieprzekraczalne?
Jeżeli dobrze określisz cel projektu to takie założenie nabiera jeszcze więcej sensu (przeczytaj więcej o określaniu celu projektu).
Wtedy po jednej stronie równania stawiasz korzyści z osiągnięcia celu projektu, a po drugiej zakładane koszty.
Jeżeli korzyści przekraczają koszty, to projekt ma sens.

Podejście Design to Cost
Na tym właśnie polega podejście Design to Cost.
Podstawowe założenia:
- Koszt projektu IT jest stały.
- Celem projektu jest osiągnięcie konkretnych korzyści, a nie zrealizowanie całego zaplanowanego zakresu.
- Nie jesteś w stanie na 100% przewidzieć ile zużyjesz budżetu, czasu i zasobów na osiągnięcie każdego z celów.
- Nie zobowiązujesz się więc z wyprzedzeniem do wdrożenia wszystkich zaplanowanych rozwiązań. Podejmujesz decyzję w danym momencie, mając wiedzę o aktualnym postępie, pozostałym budżecie, czasie trwania i zasobach.
- Efektywność strategii (rozwiązań) zmienia się w zależności od posiadanych zasobów, czasu i budżetu.
- Projektowanie rozwiązania to ciągły proces, w którym każdy kolejny krok wynika z efektów poprzednich działań.
Proces
W uproszczeniu zarządzanie kosztami projektu IT wygląda wtedy następująco:

- Określane są kluczowe cele projektu i budżet (oraz czas, zasoby) przeznaczony na ich realizację.
- Opracowywane są rozwiązania, które mieszczą się w ograniczeniach budżetu, czasu i zasobów. I oczywiście wspierają cele projektu.
- Budowane jest rozwiązanie, które powinno dostarczyć najwięcej wartości w relacji do budżetu.
- W budowę takiego rozwiązania inwestowana jest niewielka część budżetu – 2 do 5%
- Po zakończeniu iteracji podejmowana jest decyzja na temat dalszych działań, uwzględniając:
- Bieżący efekt realizacji – czy zbliżamy się do celu? może już osiągnęliśmy któryś z celów? a może trzeba zmienić rozwiązanie?
- Pozostały budżet (czas, zasoby).
- Proces wraca do pkt. 2 – czyli opracowywane są rozwiązania (strategie) na kolejną iterację.
- I tak w kółko, aż do osiągnięcia wszystkich celów, lub wyczerpania budżetu.
A co, jeżeli budżet się skończy?
Jeżeli zasoby czy to finansowe, czasowe czy ludzkie wyczerpią się przed osięgnięciem wszystkich celów, to cały projekt się kończy.
Co wtedy?
W tym podejsćiu już od samego początku projektowane są rozwiązania dające konkretne korzyści. Jeżeli wszystko poszło zgodnie z planem, to interesariusze otrzymali masę przydatnych i kompletnych rozwiązań w trakcie dotychczasowej realizacji projektu. Niezrealizowanie jednego czy dwóch z nich nie jest wtedy tak dużym problemem.

Dzięki osiągnięciu mierzalnych korzyści jest bardzo duża szansa, że znajdzie się budżet na zrealizowanie kolejnych projektów.
Zarządzanie kosztami projektu z perspektywy celów – przykłady wdrożenia
Wróćmy do przykładu z tabletem na produkcji. W podejściu Design to Cost mogłoby to wyglądać następująco.
- Celem jest przyspieszenie produkcji o 20%. Jednym z rozwiązań jest zastosowanie ekranów dotykowych do raportowania postępu prac. Wg założenia ma to zwiększyć efektywność o 15%.
- Rozwiązanie to jest wdrażane na małą skalę (5% budżetu). Tylko jako panel do raportowania wadliwych towarów (jeden przycisk). I tylko na jednej linii produkcyjnej.
- Testy pokazują, że takie rozwiązanie nie działa ze względu na niekorzystne warunki. W ramach pozostałych 95% budżetu należy znaleźć inne rozwiązania.
- Sprawdzane jest kolejne rozwiązanie, na przykład interfejs sterowany głosem. Również na małą skalę.
- Końcowe rozwiązanie być może nie pokryje wszystkich możliwych zastosowań. Na przykład zwiększy efektywność tylko o 12% i to na 4 z 6 linii. Ale dzięki temu sfinansuje kolejne etapy projektu.
Jest to dużo lepszy efekt, niż zbudowanie kompletnego rozwiązania, które w realnych warunkach nie przynosi korzyści.
Przykład na dużą skalę
Przykładem wdrożenia takiego podejścia na dużą skalę jest metoda Cleanroom, której początki sięgają przełomu lat ’80 i ’90 ubiegłego wieku. Stosowana w IBM do realizacji wielkich projektów militarnych czy kosmicznych.
Cleanroom to krótkie cykle, po których weryfikowana jest jakość rozwiązania w oparciu o modele statystyczne, a następnie podejmowane są decyzje co do kolejnych etapów. Technika ta pozwoliła realizować projekty o czasie i w budżecie przez wiele lat.
Podsumowanie – jak wdrożyć Design to Cost?
Pierwszą przeszkodą we wdrażaniu takiego podejścia jest zmiana sposobu myślenia. Większość interesariuszy przyzwyczajona jest do tego, że zamawia konkretny produkt i potem go otrzymuje. Jeżeli produkt nie działa, to zgłasza się Change Requesty albo dyskutuje długimi godzinami nad interpretacją zapisów z kontraktu.
Dlatego najlepiej zacząć zarządzanie kosztami projektu IT wg zasad Design to Cost od małej skali. Uruchomić niezbyt złożony, ale ważny projekt wg tych zasad. I jeżeli zadziała, to dalsze wdrożenie będzie dużo prostsze.
Przedstawione treści bazują na opracowaniach Toma Gilba „Value Planning” oraz „Competitive Engineering”, do których przeczytania serdecznie Cię zachęcam.
W tym artykule przedstawiłem sposoby na ograniczanie budżetu projektu gdy współpracujesz z zewnętrznym wykonawcą:
