KPI w zarządzaniu projektami - jak mierzyć sukces projektów?

W projektach IT pytanie „ile wydano pieniędzy na wdrożenie tego projektu” brzmi jak prośba o jedną liczbę, ale w praktyce jest pytaniem o definicję, granice i jakość danych. „Wdrożenie” bywa utożsamiane z wytworzeniem systemu, podczas gdy koszt wdrożenia to zwykle suma: wytworzenia, integracji, migracji danych, testów akceptacyjnych, uruchomienia produkcyjnego, stabilizacji oraz przygotowania organizacji (szkolenia, zmiany procesowe, komunikacja, wsparcie). Jeśli organizacja chce wiarygodnie odpowiadać na pytanie ile wydano pieniędzy na wdrożenie tego projektu, musi z góry ustalić, co wchodzi do kosztu, a co jest utrzymaniem (run), rozwojem po wdrożeniu (change) albo kosztem ogólnym.

Co w praktyce oznacza „koszt wdrożenia” i gdzie uciekają pieniądze
Najczęstsze „wycieki” kosztowe wynikają z trzech obszarów. Po pierwsze: niejednoznaczne granice (czy liczymy tylko dostawcę i IT, czy też czas kluczowych użytkowników biznesowych, warsztaty, UAT, szkolenia, przygotowanie danych, nadgodziny operacji). Po drugie: koszty technologii ukryte w rachunkach zbiorczych (chmura, licencje, narzędzia, środowiska testowe), które nie są przypisywane do projektu konsekwentnie. Po trzecie: prace „naprawcze” i zmiany zakresu, które formalnie wyglądają jak drobne doprecyzowania, a realnie tworzą rework (przeróbki po testach, zmiany integracji, dodatkowe wymagania bezpieczeństwa, korekty danych). Bez uporządkowania tych trzech obszarów odpowiedź na pytanie ile wydano pieniędzy na wdrożenie tego projektu będzie zawsze sporna, bo różne strony będą liczyły „to samo wdrożenie” w inny sposób.

Trzy wskaźniki KPI, które najlepiej odpowiadają na pytanie „ile wydano…”
KPI 1: Rzeczywisty koszt skumulowany (Actual Cost) z kategoryzacją.
To jest „prawda księgowa” projektu: ile wydano pieniędzy na wdrożenie tego projektu do dziś, ale z obowiązkowym rozbiciem na kategorie, bo sama suma nie jest sterowalna. Minimalny, praktyczny podział, który daje wartość zarządczą, to: (a) ludzie: praca wewnętrzna i zewnętrzna, (b) technologia: licencje, chmura/sprzęt, narzędzia, (c) usługi: integracje, audyty, bezpieczeństwo, (d) koszt biznesu: czas SME, szkolenia, komunikacja, testy akceptacyjne. Ten KPI pozwala szybko zidentyfikować, czy „drożeje” wykonawstwo, infrastruktura, czy raczej absorpcja biznesu.

KPI 2: Prognoza kosztu zakończenia (Forecast at Completion).
W praktyce najważniejsze decyzje podejmuje się nie na podstawie tego, ile już wydano, tylko ile jeszcze trzeba będzie wydać, aby dowieźć uzgodniony efekt i przejść stabilizację po uruchomieniu. Prognoza powinna uwzględniać tempo wydatków, otwarte ryzyka (dane, integracje, zależności dostawców, dostępność środowisk), prawdopodobny poziom zmian oraz realny koszt „dociągnięcia jakości” (defekty krytyczne, wydajność, bezpieczeństwo). Ten KPI odpowiada na pytanie: jeśli dziś wiemy, ile wydano pieniędzy na wdrożenie tego projektu, to czy zmierzamy do kontrolowanego domknięcia budżetu, czy do eskalacji kosztów.

KPI 3: Udział kosztu zmian zakresu (Scope Change Cost Ratio).
Najczęściej budżet nie „pęka” jedną dużą fakturą, tylko sumą małych decyzji. Ten KPI pokazuje, jak duża część kosztów pochodzi z prac nieplanowanych: change requestów, dodatkowych integracji, przeróbek po testach, doprecyzowań wymagań, zmian regulacyjnych, twardych wymagań bezpieczeństwa, których nie było w baseline. Nie chodzi o to, by blokować zmiany, tylko by nadawać im cenę, priorytet i właściciela. Gdy udział kosztu zmian rośnie, odpowiedź na „ile wydano pieniędzy na wdrożenie tego projektu” musi mieć dopowiedzenie: wydano tyle, ponieważ kupiono dodatkowy zakres albo zapłacono za rework wynikający z jakości/ryzyk.

Jeden wskaźnik KPI, który łączy koszt z efektem wdrożenia
KPI 4: Adopcja i wykorzystanie (Adoption & Utilization).
Można zakończyć projekt „na papierze” i nadal przepalić budżet, jeśli rozwiązanie nie jest używane albo procesy nie przeszły na nowy system. Dlatego obok liczb finansowych warto mieć jeden KPI efektu: odsetek aktywnych użytkowników, stopień przejścia kluczowych procesów na nowy system, wolumen transakcji, redukcję pracy ręcznej lub spadek liczby zgłoszeń blokujących pracę po uruchomieniu. Ten KPI zamyka pętlę: pozwala ocenić, czy to, ile wydano pieniędzy na wdrożenie tego projektu, przełożyło się na realną zmianę operacyjną i biznesową.

Podsumowanie: rzetelna odpowiedź na „ile wydano pieniędzy na wdrożenie tego projektu” nie wynika z jednej tabeli, tylko z dyscypliny definicji, alokacji kosztów i konsekwentnego raportowania kilku KPI. Jeśli ograniczysz się do rzeczywistego kosztu skumulowanego (z kategoryzacją), prognozy kosztu zakończenia, udziału kosztu zmian zakresu oraz adopcji, uzyskasz obraz porównywalny między projektami i odporny na „spory o definicje”, a jednocześnie wystarczająco prosty, by na jego podstawie podejmować decyzje.

Sukces projektu

Sukces projektu nie zawsze oznacza tylko jego ukończenie. Projekt może zostać zrealizowany, ale przekroczyć budżet, opóźnić się o kilka miesięcy czy nie dostarczyć wartości biznesowej klientowi. Aby uniknąć takich sytuacji, organizacje coraz częściej sięgają po KPI - kluczowe wskaźniki efektywności.

KPI pozwalają mierzyć nie tylko to, czy projekt został ukończony, ale również jak został zrealizowany - czy zgodnie z harmonogramem, w ramach budżetu, z zachowaniem jakości i z satysfakcją interesariuszy.

W tym artykule omówimy:

• czym są KPI w zarządzaniu projektami,
• jakie mają znaczenie,
• przykłady kluczowych wskaźników,
• jak wdrożyć system KPI w firmie,
• najczęstsze błędy, których warto unikać.

Czym są KPI w projektach?

KPI (Key Performance Indicators) to mierzalne wskaźniki, które pozwalają ocenić, na ile projekt realizuje założone cele.

Mogą dotyczyć różnych obszarów:

• czasowych (terminowość),
• finansowych (budżet),
• jakościowych (spełnienie wymagań),
• zespołowych (efektywność pracy),
• biznesowych (wartość dostarczona klientowi).

Przykład: „Projekt zostanie uznany za sukces, jeśli zostanie zakończony w ciągu 6 miesięcy, w budżecie 500 000 zł i z satysfakcją klienta ocenioną na minimum 8/10”.

Dlaczego KPI są ważne w zarządzaniu projektami?

1. Obiektywna ocena postępów
   KPI dostarczają danych, które zastępują subiektywne oceny.
2. Wczesne wykrywanie problemów
   Regularne monitorowanie wskaźników pozwala szybko reagować na odchylenia.
3. Motywacja zespołu
   Jasno określone cele i mierniki pomagają w utrzymaniu motywacji i poczucia odpowiedzialności.
4. Lepsza komunikacja z interesariuszami
   Klient i zarząd mają przejrzysty obraz postępu i jakości projektu.
5. Ciągłe doskonalenie
   Analiza KPI po zakończeniu projektu pozwala wyciągać wnioski i ulepszać procesy w kolejnych projektach.

Przykłady KPI w zarządzaniu projektami

1. Wskaźniki czasu

• On-Time Delivery (OTD) - procent zadań/projektów ukończonych na czas.
• Schedule Variance (SV) - różnica między planowanym a faktycznym postępem w czasie.
• Ścieżka krytyczna - liczba dni opóźnień w zadaniach krytycznych.

2. Wskaźniki kosztów

• Budget Variance (BV) - różnica między budżetem planowanym a faktycznie wydanym.
• Cost Performance Index (CPI) - stosunek wartości wykonanej pracy do rzeczywistych kosztów.
• Forecasted Cost at Completion (EAC) - prognoza całkowitych kosztów projektu.

3. Wskaźniki jakości

• liczba błędów/testów niezdanych,
• procent zadań wymagających poprawek,
• zgodność dostarczonych rezultatów z wymaganiami klienta.

4. Wskaźniki zespołowe

• Productivity Rate - średnia liczba zadań ukończonych na osobę w danym czasie,
• poziom absencji,
• satysfakcja zespołu (ankiety wewnętrzne).

5. Wskaźniki biznesowe

• ROI (Return on Investment) projektu,
• satysfakcja klienta (np. NPS - Net Promoter Score),
• stopień realizacji celów strategicznych organizacji.

Jak wdrożyć KPI w zarządzaniu projektami?

1. Zdefiniuj cele projektu

KPI muszą być powiązane z realnymi celami. Jeśli celem jest wdrożenie nowego sklepu e-commerce, KPI mogą dotyczyć czasu wdrożenia, liczby błędów w testach oraz ruchu w sklepie w pierwszym miesiącu.

2. Stosuj zasadę SMART

KPI muszą być:

• S - konkretne (Specific),
• M - mierzalne (Measurable),
• A - osiągalne (Achievable),
• R - istotne (Relevant),
• T - określone w czasie (Time-bound).

3. Dobierz odpowiednie wskaźniki

Nie ma sensu mierzyć wszystkiego. Lepiej wybrać kilka kluczowych KPI, które naprawdę odzwierciedlają sukces projektu.

4. Zadbaj o system monitorowania

KPI muszą być mierzone na bieżąco - najlepiej w systemie zarządzania projektami (CRM, Asana, Jira, MS Project).

5. Raportuj i analizuj

Regularne raporty pomagają nie tylko kontrolować bieżący projekt, ale także budować bazę wiedzy do przyszłych przedsięwzięć.

Narzędzia wspierające KPI w projektach

• Asana - raporty postępów, wskaźniki ukończenia zadań.
• Jira - burndown charts, velocity, backlog health.
• MS Project - rozbudowane raportowanie budżetu i harmonogramu.
• CRM z modułem projektowym - KPI powiązane z klientami i finansami.
• BI Tools (Power BI, Tableau) - zaawansowana analityka i wizualizacje KPI.

Najczęstsze błędy przy stosowaniu KPI

1. Zbyt wiele wskaźników - zamiast pomagać, tworzą chaos.
2. Mierzenie rzeczy nieistotnych - KPI powinny być powiązane z celami, nie z „ładnymi tabelkami”.
3. Brak powiązania KPI z decyzjami - zbieranie danych bez analizy i działań korygujących.
4. Ignorowanie aspektu jakości - czas i budżet są ważne, ale projekt niskiej jakości jest porażką.
5. Brak komunikacji KPI - jeśli zespół nie zna mierników, nie może do nich dążyć.

Przykład praktyczny KPI w zarządzaniu projektami

Firma wdraża nową platformę CRM.

Cele projektu:

• zakończenie wdrożenia w 6 miesięcy,
• budżet maksymalnie 400 000 zł,
• satysfakcja użytkowników końcowych ≥ 80%.

Proponowane KPI:

• On-Time Delivery ≥ 95%,
• Budget Variance ≤ 5%,
• liczba błędów krytycznych w testach ≤ 10,
• ocena satysfakcji użytkowników ≥ 8/10.

Dzięki temu można jednoznacznie stwierdzić, czy projekt zakończył się sukcesem, i na bieżąco reagować na problemy.

KPI w zarządzaniu projektami

KPI w zarządzaniu projektami to nie tylko liczby - to narzędzie, które pomaga organizacji skupić się na tym, co naprawdę istotne.

Dzięki dobrze dobranym KPI:

• zespoły pracują efektywniej,
• kierownicy projektów podejmują lepsze decyzje,
• klienci i interesariusze mają większe zaufanie do procesu,
• firma uczy się na każdym projekcie i stale podnosi jakość swoich działań.

Najważniejsze, aby KPI były proste, powiązane z celami i konsekwentnie monitorowane. To właśnie one odróżniają projekty przypadkowe od projektów profesjonalnie zarządzanych.

Porownanie KPI w zarządzaniu projektami

 Tabela KPI w zarządzaniu projektami

Kategoria	KPI	Opis / Cel	Wzór liczenia
Czas	On-Time Delivery (OTD)	Procent zadań ukończonych w terminie	(Zadania na czas ÷ Wszystkie zadania) × 100%
	Schedule Variance (SV)	Odchylenie od harmonogramu	SV = EV - PV
	Schedule Performance Index (SPI)	Wydajność realizacji w czasie	SPI = EV ÷ PV
Koszty	Budget Variance (BV)	Różnica między budżetem a kosztami	BV = Budżet planowany - Koszt rzeczywisty
	Cost Performance Index (CPI)	Efektywność kosztowa projektu	CPI = EV ÷ AC
	Estimate at Completion (EAC)	Prognoza całkowitego kosztu	EAC = Budżet planowany ÷ CPI
Jakość	Defect Density	Liczba błędów na jednostkę produktu	Defect Density = Błędy ÷ Jednostka produktu
	First Pass Yield (FPY)	Procent rezultatów zaakceptowanych bez poprawek	(Rezultaty zaakceptowane ÷ Wszystkie rezultaty) × 100%
	Customer Satisfaction (CSAT)	Ocena satysfakcji klienta	(Pozytywne odpowiedzi ÷ Wszystkie odpowiedzi) × 100%
Zespół	Team Productivity	Średnia liczba ukończonych zadań	Productivity = Ukończone zadania ÷ Okres czasu
	Utilization Rate	Procent wykorzystania czasu pracownika	(Czas projektowy ÷ Całkowity czas pracy) × 100%
	Employee Satisfaction (ESI)	Satysfakcja zespołu	ESI = Suma ocen ÷ Liczba odpowiedzi
Biznes	ROI projektu	Zwrot z inwestycji	ROI = (Zysk netto ÷ Koszt projektu) × 100%
	Net Promoter Score (NPS)	Lojalność klienta	NPS = % Promotorów - % Krytyków
	Benefit Realization Rate (BRR)	Stopień realizacji korzyści biznesowych	BRR = (Korzyści osiągnięte ÷ Korzyści planowane) × 100%

Legenda:

• EV - Earned Value (wartość wykonanej pracy)
• PV - Planned Value (wartość zaplanowanej pracy)
• AC - Actual Cost (koszt rzeczywisty)

KPI w projektach IT pełnią kluczową rolę w ocenie nie tylko tego, czy projekt został ukończony, ale przede wszystkim jak został zrealizowany. Jednym z najczęściej zadawanych pytań przez zarząd i interesariuszy jest to, ile wydano pieniędzy na wdrożenie tego projektu oraz czy poniesione koszty są uzasadnione w stosunku do osiągniętych rezultatów. W praktyce KPI finansowe pozwalają w sposób uporządkowany odpowiedzieć na pytanie, ile wydano na wdrożenie projektu, bez opierania się wyłącznie na subiektywnych ocenach.

Równie istotny jak koszty jest harmonogram projektu, który w projektach IT bywa szczególnie narażony na zmiany wynikające z modyfikacji zakresu lub problemów technicznych. Dzięki odpowiednio dobranym KPI możliwe jest bieżące monitorowanie, czy realizacja przebiega zgodnie z planem oraz czy opóźnienia nie generują dodatkowych kosztów. W takich sytuacjach analiza KPI pozwala szybko powiązać harmonogram projektu z informacją, ile wydano pieniędzy na wdrożenie projektu na danym etapie.

Z perspektywy biznesowej kluczowe znaczenie ma także transparentność. Interesariusze chcą wiedzieć nie tylko, ile wydano na wdrożenie tego projektu, ale również jakie decyzje doprowadziły do określonego poziomu kosztów. KPI umożliwiają przedstawienie tych danych w spójnej formie, co ułatwia komunikację i buduje zaufanie do zespołu projektowego.

W projektach IT KPI pomagają również ocenić zależność między postępem prac a kosztami. Dzięki temu można jasno wskazać, ile wydano pieniędzy na wdrożenie tego projektu w odniesieniu do faktycznie dostarczonych funkcjonalności, a nie tylko do upływu czasu. Pozwala to lepiej kontrolować budżet i unikać sytuacji, w których ile wydano na wdrożenie projektu znacząco odbiega od pierwotnych założeń.

Ostatecznie dobrze zdefiniowane KPI sprawiają, że pytania o harmonogram projektu i o to, ile wydano pieniędzy na wdrożenie projektu, przestają być problemem, a stają się elementem regularnego, świadomego zarządzania. Dzięki temu organizacja może podejmować decyzje w oparciu o dane, a nie domysły, oraz skuteczniej realizować kolejne projekty IT.

KPI w zarządzaniu projektami - wartość wykonanej pracy

Czym jest „wartość wykonanej pracy” (EV)?

EV (Earned Value) to wartość budżetu przypisana do faktycznie wykonanej pracy w projekcie do danego momentu.

Innymi słowy: pokazuje, ile wartości projektowej „zarobiliśmy” wykonując część prac, biorąc pod uwagę zaplanowany budżet, a nie tylko rzeczywiste koszty.

Jak liczyć wartość wykonanej pracy - Earned Value - EV?

EV=Budz˙etcałkowity×ProcentwykonanejpracyEV = Budżet całkowity × Procent wykonanej pracy

• Budżet całkowity (BAC - Budget at Completion) - planowany koszt całego projektu.
• Procent wykonanej pracy - na ile procent faktycznie ukończono dany projekt/etap.

Przykład 1: Obliczenie wskaźnika KPI - wartość wykonanej pracy - Earned Value - EV

Projekt ma budżet 100 000 zł.
Na dzień kontroli wykonano 40% prac.

EV=100000×40%=40000złEV = 100 000 × 40\% = 40 000 zł

Oznacza to, że zrealizowano pracę o wartości 40 000 zł względem planu.

Przykład 2 (dla zadań): Obliczenie wskaźnika KPI - wartość wykonanej pracy - Earned Value - EV

Projekt składa się z 5 zadań, każde o wartości 20 000 zł.

• Zadanie 1 - ukończone w 100% → EV = 20 000 zł
• Zadanie 2 - ukończone w 50% → EV = 10 000 zł
• Zadanie 3 - rozpoczęte w 25% → EV = 5 000 zł
• Zadania 4 i 5 - jeszcze nie rozpoczęte → EV = 0 zł

EV=20000+10000+5000=35000złEV = 20 000 + 10 000 + 5 000 = 35 000 zł

Dlaczego wartość wykonanej pracy - Earned Value - EV jest ważne?

EV daje obiektywną miarę postępu, bo odnosi się do tego, co naprawdę zostało wykonane, a nie do tego:

• ile zaplanowano (PV),
• ile wydano (AC).

Dzięki temu kierownik projektu może sprawdzić:

• czy jesteśmy przed/za harmonogramem (SV, SPI),
• czy projekt jest droższy/tańszy od planu (CPI),
• czy prognozowane koszty końcowe są zgodne z budżetem (EAC).

Krótko mówiąc: EV = planowa wartość tego, co zostało faktycznie zrobione w projekcie.

 KPI w zarządzaniu projektami - wartość zaplanowanej pracy - Planned Value - PV

Planned Value (PV) to wartość zaplanowanej pracy, którą powinniśmy zrealizować do określonego momentu w projekcie.

Można o nim myśleć jako o budżecie „zatwierdzonym” na konkretną datę.
Nie mówi on o tym, co faktycznie wykonaliśmy (to EV), ani ile wydaliśmy (to AC), ale o tym, ile mieliśmy już zrobić według planu.

Jak liczyć wartość zaplanowanej pracy - Planned Value - PV?

PV=BAC×% zaplanowanejpracy na daną datęPV = BAC \times \% \ zaplanowanej pracy \ na \ daną \ datę

• BAC (Budget at Completion) - budżet całkowity projektu,
• % zaplanowanej pracy - ile procent projektu miało być ukończone do daty kontrolnej, według harmonogramu.

Przykład 1: Obliczenie KPI w projektach wartość zaplanowanej pracy - Planned Value - PV

Projekt: 100 000 zł, czas realizacji 10 miesięcy.
Po 4 miesiącach powinniśmy być na etapie 40% planu.

PV=100000×40%=40000złPV = 100 000 \times 40\% = 40 000 zł

To znaczy, że według harmonogramu do 4 miesiąca powinniśmy mieć wykonane prace o wartości 40 000 zł.

Przykład 2 Obliczenie KPI w projektach wartość zaplanowanej pracy dla zadań - Planned Value - PV

Projekt składa się z 5 etapów (po 20 000 zł każdy).
Plan mówi:

• Etap 1 - miesiąc 1,
• Etap 2 - miesiąc 2,
• Etap 3 - miesiąc 3,
• Etap 4 - miesiąc 4,
• Etap 5 - miesiąc 5.

Jeśli jesteśmy na końcu 3 miesiąca, PV = 60 000 zł (bo trzy etapy powinny być już zrealizowane wg planu).

Wskaźnik wartości zaplanowanej pracy dla zadań - Planned Value - PV w praktyce

PV jest kluczowy do porównania z innymi wskaźnikami:

• EV (Earned Value) - pokazuje, co naprawdę zrobiono.
• AC (Actual Cost) - pokazuje, ile naprawdę wydano.

Dzięki temu możemy obliczyć:

• SV (Schedule Variance) = EV - PV → różnica między planem a wykonaniem w czasie.
• SPI (Schedule Performance Index) = EV ÷ PV → wskaźnik terminowości.

Krótko mówiąc: PV = wartość pracy, którą powinniśmy byli wykonać zgodnie z planem na dany moment projektu.

Chcesz, żebym przygotował podobnie jasne wyjaśnienia dla AC (Actual Cost) i reszty wskaźników EVM (SV, SPI, CPI, EAC) - i złożył to w kompletny artykuł o metodzie Earned Value Management?

Koszt aktualny - Actual Cost AC -

Czym jest koszt aktualny - Actual Cost - AC?

Koszt aktualny - Actual Cost - AC, czyli koszt rzeczywisty, to suma wszystkich faktycznych wydatków poniesionych na wykonanie pracy w projekcie do danego momentu.

W odróżnieniu od:

• EV (Earned Value) - który mówi, ile wartości wytworzono,
• PV (Planned Value) - który mówi, ile wartości planowano wytworzyć,
• AC mówi ile naprawdę wydano pieniędzy na osiągnięcie obecnego poziomu wykonania projektu.

Jak liczyć koszt aktualny - Actual Cost - AC?

AC=Suma wszystkich poniesionych kosztoˊw do daty kontrolnejAC = \text{Suma wszystkich poniesionych kosztów do daty kontrolnej}

Koszty obejmują m.in.:

• wynagrodzenia zespołu,
• koszty podwykonawców,
• zakup materiałów,
• koszty licencji i narzędzi,
• koszty administracyjne i operacyjne przypisane do projektu.

Przykład 1: Obliczenie wskaźnika KPI - koszt aktualny - Actual Cost - AC

Projekt budżet: 100 000 zł.
Do końca 3. miesiąca:

• wypłacono wynagrodzenia: 25 000 zł,
• kupiono sprzęt: 10 000 zł,
• opłacono podwykonawcę: 5 000 zł.

AC=25000+10000+5000=40000złAC = 25 000 + 10 000 + 5 000 = 40 000 zł

Przykład 2 - dla zadań - obliczenie wskaźnika KPI - koszt aktualny - Actual Cost - AC

Projekt składa się z 3 etapów:

• Etap 1: koszty rzeczywiste = 15 000 zł
• Etap 2: koszty rzeczywiste = 20 000 zł
• Etap 3: koszty rzeczywiste = 5 000 zł (częściowo wykonany)

Do daty kontrolnej AC = 40 000 zł.

Dlaczego koszt aktualny - Actual Cost - AC jest ważny?

AC pozwala sprawdzić ile naprawdę kosztuje wykonana praca, a w połączeniu z EV daje odpowiedź:

• Czy wydaliśmy za dużo względem tego, co wykonaliśmy?
• Czy projekt jest kosztowo efektywny?

To właśnie dzięki AC obliczamy wskaźniki:

• Cost Variance (CV) = EV - AC
  → pokazuje, czy projekt jest w budżecie, czy nie.
• Cost Performance Index (CPI) = EV ÷ AC
  → pokazuje efektywność kosztową.

Podsumowanie:
Koszt aktualny - Actual Cost - AC = wszystkie realne koszty poniesione do określonej daty w projekcie.
Jest fundamentem, aby porównywać plan (PV) i wykonaną wartość (EV) z tym, ile faktycznie zapłaciliśmy (AC).

 

Zarządzanie wartością wypracowaną - Earned Value Management - EVM. Mierzenie efektywności projektów

Wielu menedżerów projektów spotyka się z tym samym problemem: projekt formalnie „postępuje”, ale trudno jednoznacznie ocenić, czy jest realizowany zgodnie z harmonogramem i budżetem. Zespół raportuje, że „prace trwają”, ale co to właściwie znaczy? Czy jesteśmy przed planem? Czy wydaliśmy już za dużo? Czy na pewno zakończymy projekt w terminie?

Odpowiedzi na te pytania dostarcza Earned Value Management - EVM - metoda analizy, która łączy trzy kluczowe elementy: czas, koszt i zakres.

W tym artykule krok po kroku wyjaśnimy, czym jest EVM, jak liczyć podstawowe wskaźniki (EV, PV, AC) i jak dzięki nim oceniać stan projektu przy pomocy CV, SV, CPI, SPI i EAC.

Czym jest zarządzanie wartością wypracowaną - Earned Value Management - EVM?

Zarządzanie wartością wypracowaną - Earned Value Management - EVM to metoda zarządzania projektami, która pozwala monitorować:

• ile pracy zaplanowano (PV),
• ile pracy faktycznie wykonano (EV),
• ile kosztowała ta praca (AC).

Na tej podstawie wylicza się wskaźniki pokazujące:

• czy projekt jest w budżecie,
• czy mieści się w harmonogramie,
• jakie będą przewidywane koszty zakończenia.

Trzy filary zarządzania wartością wypracowaną - Earned Value Management - EVM

1. Wartość zaplanowanej pracy - Planned Value - PV

To wartość budżetu przypisana pracy, którą powinniśmy zrealizować do danego momentu zgodnie z harmonogramem.

Wzór:

PV=BAC×% zaplanowanej pracyPV = BAC \times \% \ zaplanowanej \ pracy

gdzie BAC to Budget at Completion (całkowity budżet projektu).

Przykład:
Projekt ma budżet 100 000 zł i czas 10 miesięcy. Po 4 miesiącach plan zakłada 40% postępu.

PV=100000×40%=40000złPV = 100 000 \times 40\% = 40 000 zł

2. Wartość wykonanej pracy - Earned Value - EV

To wartość budżetu przypisana faktycznie ukończonej pracy do danego momentu.

Wzór:

EV=BAC×% wykonanej pracyEV = BAC \times \% \ wykonanej \ pracy

Przykład:
Ten sam projekt (100 000 zł). Faktycznie ukończono 30% pracy.

EV=100000×30%=30000złEV = 100 000 \times 30\% = 30 000 zł

3. Koszt rzeczywisty - Actual Cost - AC

To suma wszystkich rzeczywistych kosztów poniesionych do danego momentu.

Wzór:

AC=∑kosztoˊw rzeczywistychAC = \sum \text{kosztów rzeczywistych}

Przykład:
Na projekt wydano do tej pory 45 000 zł.

AC=45000złAC = 45 000 zł

Wskaźniki EVM - jak je interpretować?

Mając PV, EV i AC, możemy policzyć wskaźniki, które dają pełny obraz projektu.

1. Odchylenie kosztowe - Cost Variance - CV

Pokazuje różnicę między wartością wykonanej pracy (EV) a rzeczywistym kosztem (AC).

Wzór:

CV=EV−ACCV = EV - AC

Interpretacja:

• CV > 0 → projekt jest poniżej budżetu (wydaliśmy mniej niż wartość wykonanej pracy).
• CV < 0 → projekt jest powyżej budżetu.

Przykład:
EV = 30 000 zł, AC = 45 000 zł

CV=30000−45000=−15000złCV = 30 000 - 45 000 = -15 000 zł

projekt przekroczył budżet.

2. Odchylenie harmonogramu - Schedule Variance - SV

Pokazuje różnicę między wartością wykonanej pracy (EV) a wartością zaplanowanej pracy (PV).

Wzór:

SV=EV−PVSV = EV - PV

Interpretacja:

• SV > 0 → projekt przed harmonogramem,
• SV < 0 → projekt opóźniony.

Przykład: Obliczenie odchylenia harmonogramu - Schedule Variance - SV
EV = 30 000 zł, PV = 40 000 zł

SV=30000−40000=−10000złSV = 30 000 - 40 000 = -10 000 zł

projekt jest opóźniony względem planu.

3. Wskaźnik efektywności kosztowej - Cost Performance Index - CPI

Pokazuje, ile wartości „zarabiamy” na każdą wydaną złotówkę.

Wzór:

CPI=EVACCPI = \frac{EV}{AC}

Interpretacja:

• CPI > 1 → projekt kosztowo efektywny,
• CPI < 1 → projekt zbyt drogi.

Przykład: Obliczenie wskaźnika efektywności kosztowej - Cost Performance Index - CPI
EV = 30 000 zł, AC = 45 000 zł

CPI=3000045000=0,67CPI = \frac{30 000}{45 000} = 0,67

za każdą wydaną złotówkę zrealizowano pracę wartą tylko 67 groszy.

4. Wskaźnik efektywności harmonogramu - Schedule Performance Index - SPI

Pokazuje, jak sprawnie projekt realizuje harmonogram.

Wzór:

SPI=EVPVSPI = \frac{EV}{PV}

Interpretacja:

• SPI > 1 → projekt idzie szybciej niż planowano,
• SPI = 1 → zgodnie z planem,
• SPI < 1 → projekt opóźniony.

Przykład: Obliczenie wskaźnika efektywności harmonogramu - Schedule Performance Index - SPI
EV = 30 000 zł, PV = 40 000 zł

SPI=3000040000=0,75SPI = \frac{30 000}{40 000} = 0,75

wykonano tylko 75% tego, co było zaplanowane.

5. Prognoza kosztów końcowych - Estimate at Completion - EAC

Pokazuje, ile będzie kosztował cały projekt, jeśli obecne tempo kosztów się utrzyma.

Najprostszy wzór:

EAC=BACCPIEAC = \frac{BAC}{CPI}

Przykład: Obliczenie wskaźnika prognozy kosztów końcowych - Estimate at Completion - EAC
BAC = 100 000 zł, CPI = 0,67

EAC=1000000,67≈149000złEAC = \frac{100 000}{0,67} \approx 149 000 zł

przy obecnej efektywności projekt zakończy się z kosztem 149 000 zł zamiast planowanych 100 000 zł.

Tabela wzorów EVM

Skrót	Nazwa	Wzór	Interpretacja
PV	Planned Value	BAC × % planowanej pracy	Plan na dany moment
EV	Earned Value	BAC × % wykonanej pracy	Wartość faktycznie zrealizowanej pracy
AC	Actual Cost	Suma kosztów rzeczywistych	Ile naprawdę wydano
CV	Cost Variance	EV - AC	+ = oszczędność, - = przekroczenie budżetu
SV	Schedule Variance	EV - PV	+ = przed planem, - = opóźnienie
CPI	Cost Performance Index	EV ÷ AC	>1 = efektywnie, <1 = nieefektywnie
SPI	Schedule Performance Index	EV ÷ PV	>1 = szybciej, <1 = wolniej
EAC	Estimate at Completion	BAC ÷ CPI	Prognozowany koszt końcowy

Kompletny przykład wskaźnika zarządzanie wartością wypracowaną - Earned Value Management - EVM

Założenia projektu:

• Budżet całkowity (BAC): 100 000 zł
• Czas: 10 miesięcy
• Po 4 miesiącach:
  • Plan (PV): 40% → 40 000 zł
  • Wykonanie (EV): 30% → 30 000 zł
  • Koszty rzeczywiste (AC): 45 000 zł

Obliczenia:

• CV = EV - AC = 30 000 - 45 000 = -15 000 zł (przekroczenie budżetu)
• SV = EV - PV = 30 000 - 40 000 = -10 000 zł (opóźnienie)
• CPI = EV ÷ AC = 30 000 ÷ 45 000 = 0,67 (kosztowo nieefektywnie)
• SPI = EV ÷ PV = 30 000 ÷ 40 000 = 0,75 (opóźnienie w harmonogramie)
• EAC = BAC ÷ CPI = 100 000 ÷ 0,67 = ~149 000 zł (prognoza zakończenia z dużym przekroczeniem budżetu).

Wniosek:

Projekt jest opóźniony i za drogi. Jeśli nic się nie zmieni, koszty końcowe będą o ~49% wyższe niż plan.

Zalety stosowania wskaźnika zarządzanie wartością wypracowaną - Earned Value Management - EVM

• daje realny obraz postępów, a nie tylko deklaracje,
• pozwala wcześnie wykrywać problemy,
• umożliwia prognozowanie kosztów i terminów,
• zwiększa przejrzystość wobec interesariuszy,
• wspiera podejmowanie decyzji na danych, a nie intuicji.

Wyzwania i ograniczenia zarządzania wartością wypracowaną - Earned Value Management - EVM

• wymaga dokładnego planowania i estymacji kosztów,
• bywa postrzegany jako „zbyt biurokratyczny”,
• nie wszystkie organizacje mają kulturę pracy opartą na liczbach,
• w projektach z bardzo zmiennym zakresem trudniej go stosować w czystej formie.

Zarządzanie wartością wypracowaną - Earned Value Management - EVM

Podsumowanie

Earned Value Management (EVM) to jedno z najskuteczniejszych narzędzi monitorowania projektów.
Dzięki prostym wskaźnikom (EV, PV, AC) i ich kombinacjom (CV, SV, CPI, SPI, EAC) menedżerowie mogą w każdej chwili odpowiedzieć na trzy fundamentalne pytania:

1. Czy projekt mieści się w harmonogramie?
2. Czy projekt mieści się w budżecie?
3. Ile ostatecznie będzie kosztował?

EVM zmienia zarządzanie projektami z intuicji w twardą, mierzalną analizę. A w dzisiejszym świecie biznesu - to przewaga, której nie można lekceważyć.

KPI projektu IT – wzory, objaśnienia i przykłady

1. On-Time Delivery (OTD) – terminowość realizacji zadań

Co mierzy: procent zadań dostarczonych zgodnie z planem.

Dlaczego ważne: pokazuje, czy projekt jest realizowany zgodnie z harmonogramem.

Interpretacja:

• wysoka terminowość realizacji zadań - OTD → dobrze planujemy, zespół dowozi, ryzyko opóźnień małe
• niska terminowość realizacji zadań - OTD → możliwe złe planowanie, przeciążenie zespołu, opóźnienia

Gdzie stosować: w każdym projekcie IT, szczególnie w projektach z jasnymi milestone’ami.

Wzór:

OTD = {Liczba_zadań_dostarczonych_na_czas}{Liczba_zadań_planowanych} \times 100%

Opis: Mierzy, jak dobrze projekt trzyma harmonogram.

Przykład:

Zaplanowano 40 zadań, wykonano 32 na czas

OTD = {32}{40} \times 100% = 80%

2. Budget Variance (BV) – odchylenie budżetu

Co mierzy: różnicę między planowanym budżetem a rzeczywistymi wydatkami.

Dlaczego ważne: pozwala kontrolować koszty projektu.

Interpretacja:

• dodatnie odchylenie budżetu - BV → wydano mniej niż planowano
• ujemne odchylenie budżetu - BV → projekt przekracza budżet

Gdzie stosować: przy rozliczeniach projektów fixed-price oraz w projektach korporacyjnych.

Wzór:

BV = {Budżet_planowany - Budżet_wykorzystany}{Budżet_planowany} \times 100%

Opis: Pokazuje procentową różnicę między planowanym a wydanym budżetem.

Przykład:

Plan: 200 000 zł, wydano 180 000 zł

BV = {200000 - 180000}{200000} \times 100% = 10%

3. Scope Change (SC) – zmiany zakresu

Co mierzy: ile wymagań zostało dodanych do projektu po jego rozpoczęciu.

Dlaczego ważne: pozwala identyfikować „scope creep”, który prowadzi do opóźnień i wzrostu kosztów.

Interpretacja:

• niska wartość zmian zakresu → stabilny zakres
• wysoka wartość zmian zakresu → ryzyko niedowiezienia projektu

Gdzie stosować: w projektach, które często zmieniają założenia lub wymagania.

Wzór KPI zmiany zakresu :

SC = {Liczba_nowych_wymagań}{Liczba_oryginalnych_wymagań} \times 100%

Opis: Mierzy jak bardzo zmienił się zakres projektu (np. creep).

Przykład:

Początkowo 50 wymagań, dodano 10

SC = {10}{50} \times 100% = 20%

4. Defect Density (DD) – liczba błędów

Co mierzy: liczbę błędów przypadających na jednostkę (np. 1000 linii kodu).

Dlaczego ważne: wskaźnik jakości kodu i procesu wytwarzania.

Interpretacja:

• niska wartość liczby błędów → kod jest dobrej jakości
• wysoka wartość liczby błędów → problemy w architekturze, szybka produkcja kosztem jakości

Gdzie stosować: w projektach, gdzie kluczowa jest stabilność i jakość.

Wzór KPI DD - gęstość błędów :

DD = {Liczba_błędów}{Liczba_jednostek_miar}

Najczęściej jednostkami są: 1000 linii kodu (KLOC), moduł, sprint itp.

Przykład:

25 błędów na 10 000 linii kodu

DD = {25}{10} = 2.5 \text{ błędu/KLOC}

5. Test Coverage (TC) – pokrycie testami

Co mierzy: jaka część funkcjonalności systemu jest pokryta testami.

Dlaczego ważne: ogranicza ryzyko błędów produkcyjnych.

Interpretacja:

• wysokie pokrycie testami - TC → większa pewność stabilności
• niskie pokrycie testami - TC → większe ryzyko awarii, szczególnie po wdrożeniach

Gdzie stosować: w projektach DevOps, CI/CD, z częstymi wdrożeniami.

Wzór KPI TC - pokrycie testami:

TC = {Liczba_przetestowanych_funkcji}{Liczba_wszystkich_funkcji} \times 100%

Opis: Mierzy jak duża część aplikacji została przetestowana.

Przykład:

80 funkcji istnieje, przetestowano 60

TC = {60}{80} \times 100% = 75%

6. Customer Satisfaction (CSAT) – satysfakcja użytkownika

Co mierzy: oceny użytkowników projektu (np. w ankietach).

Dlaczego ważne: dobrze zrobiony projekt, który nie satysfakcjonuje klienta, nie ma wartości.

Interpretacja:

• wysoki wynik satysfakcji użytkownika → projekt trafia w potrzeby
• niski wynik satysfakcji użytkownika → niezrozumienie wymagań lub niska jakość produktu

Gdzie stosować: szczególnie przy projektach SaaS i systemach dla klienta.

Wzór:

CSAT = {\sum{ocen_klientów}}{Liczba_odpowiedzi} \times 100%

Opis: Najczęściej występuje w ankietach (skala 1–5 lub 1–10).

Przykład:

Oceny: 8, 9, 7, 9, 10

CSAT = {8+9+7+9+10}{5} = 8.6

7. Velocity (VEL) – prędkość realizacji sprintów (Agile)

Co mierzy: ile pracy (story points) zespół wykonuje w sprincie.

Dlaczego ważne: pozwala planować backlog i estymować kolejne sprinty.

Interpretacja:

• stabilna prędkość realizacji sprintów - velocity → dobre planowanie sprintów
• duże wahania prędkości realizacji sprintów - velocity → problemy organizacyjne lub niejasne wymagania

Gdzie stosować: w metodykach Agile (Scrum, Kanban).

Wzór:

VEL = {Punkty_story_zrealizowane}{Czas_sprintu}

Opis: Pokazuje ile zespołowi udaje się wykonać pracy w jednym sprincie.

Przykład:

Sprint: 2 tygodnie, wykonano 35 punktów story

VEL = 35 \text{ pkt/sprint}

8. Mean Time to Resolve (MTTR) – średni czas rozwiązania problemu

Co mierzy: ile czasu zajmuje usunięcie problemu od jego zgłoszenia.

Dlaczego ważne: wpływa na dostępność, SLA oraz doświadczenie użytkowników.

Interpretacja:

• niski średni czas rozwiązania problemu MTTR → szybkie wsparcie, dobra dokumentacja
• wysoki średni czas rozwiązania problemu MTTR → chaos, brak procedur, przeciążenie

Gdzie stosować: w utrzymaniu systemów produkcyjnych.

Wzór:

MTTR = {Suma_czasów_rozwiązania_incydentów}{Liczba_incydentów}

Opis: Kluczowy w utrzymaniu aplikacji.

Przykład:

Trzy incydenty: 4h, 6h, 2h

MTTR = {4+6+2}{3} = 4h

9. Deployment Frequency (DF) – częstotliwość wdrożeń

Co mierzy: jak często projekt jest wdrażany na środowisko produkcyjne.

Dlaczego ważne: częstsze wdrożenia = szybszy time-to-market i mniejsze zaległości.

Interpretacja:

• wysoka częstotliwość wdrożeń - DF → automatyzacja, DevOps, szybki rozwój
• niska częstotliwość wdrożeń - DF → długa integracja, problemy jakościowe

Gdzie stosować: w zespołach CI/CD, DevOps, SaaS.

Wzór:

DF = {Liczba_wdrożeń}{Okres_pomiarowy}

Opis: Kluczowy wskaźnik DevOps (częściej = lepsza automatyzacja).

Przykład:

12 wdrożeń w miesiącu

DF = 12 \text{/ miesiąc}

10. Team Utilization Rate (TUR) – wykorzystanie zasobów

Co mierzy: jaki procent czasu zespół poświęca na pracę projektową.

Dlaczego ważne: pomaga analizować obciążenie zespołu i efektywność.

Interpretacja:

• 70–85% → optymalny poziom (realistyczne)
• <50% → słabe zarządzanie zadaniami
• 90% → ryzyko wypalenia, spadek jakości

Gdzie stosować: w zarządzaniu zasobami w długich projektach.

Wzór:

TUR = {Czas_rzeczywistej_pracy_nad_projektem}{Czas_dostępny} \times 100%

Opis: Pokazuje czy zespół jest przeciążony lub niedowykorzystany.

Przykład:

Dostępne 160h, praca projektowa 120h

TUR = {120}{160} \times 100% = 75%

Nazwa KPI projektu	Zastosowanie
OTD	Czy dotrzymujemy terminów
BV	Czy mieścimy się w budżecie
SC	Kontrola zmian zakresu
DD	Jakość kodu
TC	Jakość testów
CSAT	Zadowolenie klientów
VEL	Wydajność zespołu Agile
MTTR	Jakość wsparcia
DF	Poziom automatyzacji DevOps
TUR	Wydajność wykorzystania zasobów