Keep People Informed (informuj ludzi na bieżąco), Keep People Involved (utrzymuj zaangażowanie ludzi), … to rozwinięcia skrótu KPI, które często można znaleźć na forach i w sieciach społecznościowych. To z pewnością kreatywne rozwinięcia tego skrótu i ważne spojrzenie na rolę przywództwa. W tym artykule nawiązuję do pierwotnego rozwinięcia skrótu KPI, czyli Key Pefromance Indicator (kluczowe wskaźniki wydajności) lub czasem Key Process Indicator (kluczowe wskaźniki procesu) z perspektywy projektów, mających na celu dostarczenie na rynek nowego produktu.
Szukając przykładowych wskaźników (KPI) w literaturze, znajdziemy dziesiątki ich przykładów. Taka ilość nie może być kluczowa dla każdego rodzaju projektu. Wybieram więc te, które pomagają szybko zweryfikować kondycję projektu, i zlokalizować te obszary, którymi należy się natychmiast zająć. Lokalizuję je, analizując różnice w czasie – pomiędzy wartością aktualną, przewidywaną oraz budżetową. Uczestnicząc w wielu projektach w obszarze R&D proponuję 6 wskaźników, które pozwalają prowadzić projekt w sposób zapewniający kontrolę nad znaną trójką wymagań/oczekiwań: Jakością, Kosztami oraz Czasem dostarczenia (z ang. QCD – quality, cost, delivery).
Zacznę jednak od tego co powinno łączyć wszystkie wskaźniki, skupiając się nad tym jakie powinny one być. Zlekceważenie jednej z poniższych zasad sprawia, że stają się one mniej lub bardziej bezużyteczne, a co gorsza zaczynają być postrzegane jako „obowiązkowa czynność bez wartości dodanej” – innymi słowy „jest początek miesiąca, więc robię wskaźniki, bo mi kazali”. Jeżeli słyszałeś takie komentarze tzn. że system wskaźników nie działa w sposób prawidłowy i najprawdopodobniej zapomniano o jednej z poniższych 4 zasad.
Na potrzeby tego artykułu wyobraźmy sobie hipotetyczny projekt, z krótkim czasem realizacji. Celem projektu jest zaprojektowanie nowego produktu i uruchomienie go w produkcji seryjnej. Główne parametry projektu:
- Czas trwania: dwa lata
- Cztery poziomy dojrzałości produktowej, z podanym celem na końcu każdego z nich (w nawiasie zakładany czas trwania poziomu)
POZIOM 1 – Mam pomysły na prototypy (4 miesiące)
POZIOM 2 – Mam działający i przetestowany prototyp (6 miesięcy)
POZIOM 3 – Mam proces, który pozwala na seryjną produkcję produktu (10 miesięcy)
POZIOM 4 – Mam przetestowany produkt wyprodukowany w seryjnym procesie, który mogę produkować i sprzedawać (4 miesiące)
- każdy poziom kończy się kamieniem milowym, spotkaniem z poszerzonym zespołem projektowym i decyzją o kolejnym kroku

Zasada 1. Wskaźniki są potrzebne
Jeżeli mam wskaźnik, który nigdy nie zaalarmował mnie o jakimkolwiek ryzyku, najprawdopodniej nie potrzebuję go. Po co śledzić coś co działa dobrze? Trzymając się tej zasady zestaw wskaźników wykorzystywanych w projektach może mieć charakter dynamiczny. Jeżeli coś nas w projekcie boleśnie zaskoczyło, powinniśmy się zastanowić, czy nie można zbudować wskaźnika, który pomoże nam w przyszłości temu zapobiec.
Te wskaźniki, które mają bezpośredni wpływ na (QCD) jakość, koszty i czas dostarczenia, warto śledzić podczas trwania całego projektu. Niedostarczenie któregokolwiek z nich, będzie z pewnością ocenione jako większa lub mniejsza porażka.
Zasada 2. Wskaźniki są dobrze zaprojektowane
Każdy wskaźnik musi mieć określony cel, który planujemy osiągnąć (np. poziom ryzyka) lub którego nie możemy przekroczyć (np. poziom wydatków). Wskaźnik bez ustalonego celu staje się licznikiem (coś zliczamy, ale nie mamy pojęcia, czy otrzymana wartość jest bezpieczna, czy jest zagrożeniem). Wartość celu ustalamy na początku projektu. Każda zmiana celu jest związana ze zmianą projektową i wymaga zgody na poziomie zespołu, który podjął decyzję o aktywacji projektu.
Cel powinien być zróżnicowany w czasie, tzn. cel końcowy projektu powinien być przetłumaczony na cele pośrednie dla każdego poziomu dojrzałości produktu. . Zróżnicowanie celu w czasie, wynikające z naszej najlepszej wiedzy o fazach projektu (nie z przypadku lub przeczucia) bardzo pomaga w zarządzaniu projektem, szczególnie jeżeli jest to projekt kilkuletni.
Kolejnym elementem projektu wskaźnika, jest wartość przewidywana (z ang. forecast).
Zachęcam liderów projektu do dołożenia linii przewidywanego poziomu wskaźnika. Jest to krzywa, która pokazuje przewidywany poziom wskaźnika w przyszłości, w oparciu o istniejący plan. Jeżeli plan się zmieni – poziom przewidywanej wartości wskaźnika również się zmieni. W ten sposób możemy zweryfikować, czy aktualny plan pozwoli osiągnąć założony cel.
Jeżeli chodzi o sposób prezentowania wskaźników, preferuję wartości skumulowane – ułatwiają szybką analizę wartości aktualnych względem oczekiwanych, z perspektywy całego projektu lub poziomu dojrzałości.
Spójrzmy na przykład wskaźnika, który posiada cel (budżetowy), wartość przewidywaną oraz zrealizowaną. Jest to wskaźnik wydatków operacyjnych w projekcie (wykres poniżej). Poziom całkowitych zaplanowanych wydatków w projekcie to 1 milion złotych. Kwota ta została podzielona na 4 nierówne kwoty, uwzględniające kolejne planowane poziomy dojrzałości produktu. Lider projektu bazując na planowanych zadaniach przygotował linię przewidywanych wydatków, która przekroczyła linię zakładanego budżetu w trzecim okresie, ale nie przekroczyła ona całkowitej wartości budżetu projektu.

W takiej sytuacji warto podjąć wysiłek i zweryfikować wydatki na kolejne miesiące (w tym przypadku do końca planowanego projektu). Pisząc zaplanować, mam na myśli zbudowanie listy wydatków, które mają nazwę, ilość i wartość. Część z tak planowanych wydatków, może mieć szacunkową wartość (nie potwierdzoną wyceną / ofertą). Jeżeli linia tak zaplanowanych wydatków zbliży się do końcowej wartości budżetu, a większość wydatków będzie miała charakter szacunkowy – to ryzyko przekroczenia budżetu jest znaczne i warto przeprowadzić optymalizację planu tak szybko jak to możliwe.
Zwróćmy uwagę, że to ostrzeżenie pojawiło się w styczniu drugiego roku projektu. 11 miesięcy przed zakończeniem projektu. Przewidywana linia wydatków uratowała już niejeden projekt przed „bankructwem”.
Zasada 3. Wskaźniki są systematycznie i rzetelnie uzupełniane
Jak każdy proces, również ten będzie wartościowy i użyteczny jeżeli będzie systematycznie zasilany wiarygodnymi danymi. Nie spotkałem systemu informatycznego, który umożliwia dowolne tworzenie wskaźników bazujące na wspólnej bazie danych. Najczęściej jest to kilka systemów, które lepiej, gorzej albo wcale ze sobą nie współpracują. Dlatego najczęściej istnieje konieczność stworzenia dodatkowej „bazy danych”, która będzie źródłem danych dla wskaźników. To co się da, warto zautomatyzować. Moim celem jest to, aby aktualizowanie takiej bazy nie zajmowało jednej osobie dłużej niż 15-30 minut miesięcznie. Z pomocą przychodzą tu, niezastąpiony Excel oraz Power BI.
Źródła danych muszą opierać się na wiarygodnych danych (szczegółowych), do których można zajrzeć w przypadku wątpliwości lub wtedy kiedy istnieje konieczność zmiany przewidywanej wartości wskaźnika. Jeżeli w przytoczonym przykładzie, zespół projektowy planuje zmianę przewidywanych wydatków, to najpierw zmieni zawartość listy planowanych wydatków (dokument powiązany ze wskaźnikiem zawierający szczegółowe informacje), z której ta wartość będzie wynikać. W oparciu o tak zmodyfikowaną listę zmieni wartość wskaźnika.
Pokusa zmiany wartości wskaźnika bez wcześniejszej analizy dokumentów źródłowych jest prostą drogą do utraty kontroli nad projektem.
Zasada 4. Wskaźniki są analizowane i traktowane jako narzędzie wspomagające planowanie kolejnych kroków projektowych
Wspomniana pokusa może pojawić się przede wszystkim wtedy, kiedy rola wskaźników nie jest prawidłowo rozumiana. Poniżej kilka przykładów, które świadczą o konieczności zaplanowania sesji szkoleniowych, które pozwolą zmienić nastawienie do wskaźników oraz rozpocząć efektywnie korzystać z informacji w nich zawartych:
- Cytat: „Podkolorowałem wynik, żeby nie musieć się tłumaczyć dlaczego wydałem w tym miesiącu więcej niż zaplanowałem” – prawidłowe wykorzystanie wskaźnika polega na zastanowieniu się jakie to ma konsekwencje dla całego projektu. Chwilowe przekroczenie celu wskaźnika jest nieistotne, jeżeli cel etapu projektu jest niezagrożony i mamy plan na powrót do właściwego trendu. Jeżeli jednak trend przekroczenia jest stały i nie mamy planu na jego odwrócenie, to budżet na pewno zostanie przekroczony. Mając taką informację, zespół jest w stanie zareagować wcześniej, nie stawiając projektu i siebie „pod ścianą”, w miejscu w którym opcje są już bardzo ograniczone.
- Cytat: „Uzupełniłem wskaźniki jak co miesiąc, ale nie wiem kto to w ogóle czyta…” – jeżeli tak mówi lider projektu, to znaczy, że nie ma świadomości ich roli, oraz tego, jak pomocne są w osiągnięciu finalnego sukcesu zespołu. Jeżeli tak mówi członek zespołu, który uzupełnia jakiś wskaźnik, to znaczy, że lider projektu nie wytłumaczył właściwie celu tego zadania. Brak zrozumienia celu może prowadzić do nieintencjonalnego obniżenia jakości danych źródłowych wskaźnika – na zasadzie – nie rozumiem jakie to ważne, więc się nie przykładam.
Dobrze zaprojektowane wskaźniki, regularnie i rzetelnie aktualizowane, są dla liderów projektu jak interaktywne drogowskazy, które pozwalają na:
- Wczesną identyfikację ryzyka nieosiągnięcia celów projektowych i podjęcie działań korygujących.
- Identyfikację błędnych założeń projektowych i ich korygowanie poprzez formalną ich zmianę. Te błędy mogą polegać zarówno na niedoszacowaniu niezbędnych zasobów, jak również ich przeszacowaniu. Dobrze jest mieć w projekcie (transparentny) bufor bezpieczeństwa. Jeżeli jest on jednak zbyt duży – to z punktu widzenia całej organizacji – takie bufory, które nie mają szans na wykorzystanie, są źródłem obniżonej efektywności.
- Potwierdzenie skuteczności podjętych działań korygujących lub po prostu skuteczne zarządzanie projektem.
- Wyciągniecie wniosków i uwzględnienie ich w trakcie przygotowania założeń do kolejnego projektu.
- Szybki przegląd wielu projektów i skoncentrowanie się na najważniejszych i najpilniejszych potrzebach.
- Porównanie projektów pomiędzy sobą i dzielenie się doświadczeniem.
Poniżej opisuję te wskaźniki, które oceniam jako potrzebne, dobrze zaprojektowane, łatwe do regularnej aktualizacji, które wykorzystuję w pracy ze swoim zespołem. Podzieliłem je na dwie grupy, ze względu na rodzaj wykresów jaki stosuję. W pierwszej grupie obserwuję wartości skumulowane w perspektywie całego projektu. W drugiej grupie, wartości skumulowane w perspektywie poziomu jego dojrzałości. W dalszej części wytłumaczę powód tej różnicy, którym jest dług technologiczny.
Wydatki operacyjne, Wydatki inwestycyjne, Wykorzystanie dostępnego czasu zespołu
Wydatki operacyjne (z ang. OPEX), Wydatki inwestycyjne (z ang. CAPEX), Wykorzystanie dostępnego czasu zespołu (z ang. FTE)- dla tych trzech wskaźników można zastosować jeden typ wykresu, który przedstawia:
- Założone wartości budżetowe
- Zrealizowane wartości na koniec każdego miesiąca
- Przewidywane wartości (w bliskiej perspektywie wiarygodne/potwierdzone wartości, w dalszej przybliżone/szacowane)
Wszystkie wartości są skumulowane, narastająco sumowane – tzn. w bieżącym miesiącu jest przedstawiona wartość dla bieżącego miesiąca łącznie z sumą wartości wszystkich poprzednich miesięcy.
Zakładam, że wydatki operacyjne i inwestycyjne są na tyle często używane, że nie wymagają wyjaśnienia.
Zatrzymam się na chwilę przy wykorzystaniu dostępnego czasu zespołu.
Jak interpretować ekwiwalent pełnego czasu pracy (FTE)?
Jeżeli na etapie budżetowania założymy, że potrzebujemy w danym miesiącu 1 inżyniera, który będzie na 100% zaangażowany w projekt to FTE=1 i oznacza 160h dyspozycji tego inżyniera w projekcie, w danym miesiącu. Jeżeli założymy, że potrzebujemy 2 inżynierów w miesiącu zaangażowanych na 100% w projekcie to FTE=2. Ale jeżeli założymy, że potrzebujemy 2 inżynierów w miesiącu i każdy z nich będzie zaangażowany na 50% w projekt, to FTE znowu równa się 1.
Żeby móc efektywnie korzystać z tego wskaźnika, pracownicy muszą mieć system, w którym będą mogli raportować swój czas pracy na konkretne projekty. Wiele firm, większych i globalnych stosuje gotowe rozwiązania, ale w przypadku mniejszych firm lub działów można stworzyć własny prosty system raportowania. Te zaraportowane godziny będziemy obserwować jako „słupki’ realizacja skumulowana.

Kilka słów na temat interpretacji tego co możemy zobaczyć na wykresach.
Jeden przykład opisałem wcześniej, kiedy planowane wydatki przekroczyły budżet etapu, ale nie przekroczyły całkowitej wartości budżetu.
Inną często obserwowaną sytuacją będą różnice pomiędzy wartością przewidywaną i rzeczywistą (zrealizowaną). Jak zaznaczyłem na poniższym wykresie, wartości rzeczywiste będą oscylowały wokół przewidywanej. Raz będą niższe, raz wyższe. To nie stanowi problemu i nie powinno niepokoić. Jeżeli jednak różnice te są duże i powtarzające się, zazwyczaj świadczy to o tym, że lider projektu nie aktualizuje na bieżąco planowanych wydatków i nie urealnia wartości założonych (oszacowanych) kilka miesięcy wcześniej.
Drugi wniosek, który można wyciągnąć z poniższego wykresu, to krzywa budżetowa która nie jest dopasowana do realnych wydatków na 2 i 3 poziomie dojrzałości produktu. Warto w takiej sytuacji wrócić do początkowych założeń, zastanowić się nad tym co się zmieniło i spróbować wykorzystać tę wiedzę do zaktualizowania kolejnych poziomów dojrzałości. Ten proces analizy i nauki powinien być wykorzystany również podczas przygotowania następnego projektu.

Dla celów tego artykułu i ilustracji poprzedniego przykładu, poziom wydatków przewidywanych w przeszłości jest różny od aktualnych (zrealizowanych) w danym miesiącu. Zrobiłem to w celu ilustracji różnic, jakie zawsze będziemy obserwować. W rzeczywistości, powinno się wyrównywać poziom przewidywany do poziomu zrealizowanego w bieżącym miesiącu , a wszystkie kolejne planowane wydatki odnosić do tej wyrównanej wartości (jest to nowy punkt odniesienia). Taka operacja pozwala na urealnienie krzywej przewidywanych wydatków. Jeżeli tego nie zrobimy, to przewidywane wydatki będą oderwane od aktualnie wydanych środków – więc bezużyteczne. Wskaźnik ten na styczeń drugiego roku projektu wyglądałby więc tak:

Ta sama zasad dotyczy wydatków inwestycyjnych.
Nie dotyczy natomiast dostępnego czasu zespołu (FTE). Czasu w przeciwieństwie do pieniędzy nie możemy kumulować (zbierać na koncie w celu późniejszego wykorzystania). Jeżeli nie wykorzystaliśmy w poprzednim miesiącu zaplanowanego 0.5 FTE a w bieżącym planujemy 1FTE, to nie oznacza to, że możemy wykorzystać w tym miesiącu 1.5 FTE. Pamiętajmy, że 1 FTE oznacza 160h dostępności w miesiącu. Jeżeli ten czas minął, to dostępność tych pracowników również. Warto w tym miejscu zaznaczyć, że FTE jest rozliczane nie tylko z poziomu projektu, ale również z poziomu działu, a często również na poziomie globalny. Firmy robią to w celu weryfikacji poprawności alokacji zasobów do projektów w dłuższej perspektywie (3-5 lat), którą znajdziemy na mapie drogowej projektów. Pozwala to na planowanie właściwej ilości projektów z punktu widzenia dostępnych zasobów. Nie za dużej, bo wtedy będzie brakowało zasobów i nie za małej, bo wtedy ludzie nie będą mieli projektów, w których mogliby uczestniczyć.
Dostarczone rezultaty, wypełnienie technicznych wymagań, Minimalizacja ryzyk konstrukcji / koncepcji
Dostarczone rezultaty (z ang. Deliverables), Wypełnienie technicznych wymogów (z ang. Technical requirements), Minimalizacja ryzyk konstrukcji, koncepcji (z ang. Risk assessment FMEA) – dla tych trzech wskaźników, również można wykorzystać jeden typ wykresu (z drobną modyfikacją dla ostatniego), który zawiera:
- Założone ilości zadań dla każdego poziomu dojrzałości produktu
- Zrealizowane / dostarczone ilości zadań na koniec każdego miesiąca
- Rozpoczęte / będące w trakcie realizacji ilości zadań
W tym miejscu wracam do pojęcia długu technologicznego. On jest powodem, dla którego trzy wymienione powyżej wskaźniki projektu obserwuję z perspektywy wartości skumulowanych ale tylko w obrębie jednego poziomu dojrzałości produktu.
O ile dostępność zasobów w projekcie mogę traktować całościowo, o tyle rezultaty dostarczane przez zespół projektowy już nie.
Dlaczego?
Przypomnę w tym miejscu definicje poziomów dojrzałości produktu, które wprowadziłem na początku projektu:
POZIOM 1 – Mam pomysły na prototypy
POZIOM 2 – Mam działający i przetestowany prototyp
POZIOM 3 – Mam proces, który pozwala na seryjną produkcję produktu
POZIOM 4 – Mam przetestowany produkt wyprodukowany w seryjnym procesie, który mogę produkować i sprzedawać
Tak zdefiniowane poziomy nie są przypadkowe. Pierwszy poziom można uznać za ukończony w momencie, kiedy zespół wygenerował i wybrał pomysły do realizacji pierwszych prototypów (o tym jak wybrać dobry pomysł piszę w tym artykule Recepta na dobry pomysł)
W ramach tego poziomu dojrzałości, zespół ma do wykonania szereg czynności, które są reprezentowane przez 3 wskaźniki związane z dostarczeniem rezultatu, wypełnieniem wymogów i minimalizacji ryzyk. Nie da się przejść do następnego etapu, który polega na budowie prototypów i ich testowaniu, jeżeli zespół nie ma jeszcze wybranego pomysłu na produkt.
Ale czy na pewno?
Zdarza się, że lider projektu wraz z zespołem, nie dostarczył wszystkiego co zostało założone w ramach danego poziomu, w założonym czasie. Wtedy lider ma do dyspozycji dwa rozwiązania:
- Wydłużyć czas trwania poziomu dojrzałości produktu
- Zaciągnąć dług technologiczny (w ramach następnego poziomu) i przejść do następnego zgodnie z harmonogramem
Pierwsze rozwiązanie nie wymaga wyjaśnień, czas trwania poziomu zostaje wydłużony. Trzeba zweryfikować, czy całkowity czas trwania projektu jest zagrożony. Jeżeli tak, to trzeba wnioskować o zmianę projektową, polegającą na zmianie terminu końcowego projektu z uwzględnieniem wszystkich konsekwencji.
Druga opcja polega na formalnym zamknięciu etapu, przejściu do następnego, w którym będą „dokańczane” czynności nie zakończone w poprzednim etapie. Stąd określenie dług (trzeba w ramach istniejących zasobów nadrobić zaległości z poprzedniego etapu).
Jednym z głównych powodów wprowadzenia do projektu poziomów dojrzałości produktu, jest możliwość dokonania oceny postępów. Oceny, która kończy się rekomendacją poszerzonego zespołu projektowego o rozpoczęciu następnego poziomu lub decyzją o modyfikacji zakresu projektu lub zamknięciem projektu.
Zaciągnięcie długu technologicznego zmniejsza transparentność i rodzi ryzyko, że podjęta decyzja w oparciu o niepełne dane (no bo przecież zespół nie dostarczył wszystkich rezultatów) jest wadliwa i może prowadzić do narażenia firmy na koszty, których ponosić nie powinna.
Osobiście nie jestem zwolennikiem takich długów. Zgadzam się na nie tylko w wyjątkowych sytuacjach, w których cały zespół ocenia ryzyko związane z niedostarczonymi rezultatami jako pomijalne, nie mające wpływu na podjecie decyzji o przejściu do następnego poziomu. Zaciąganie długów na dłużej niż jeden poziom dojrzałości, jest w mojej ocenie nieakceptowalną patologią i nie powinno się tego praktykować.
Przejdę teraz do wyjaśnienia co rozumiem pod nazwą każdego z trzech wskaźników tej grupy.
Dostarczone rezultaty
W każdym systemie zarządzania projektami są zdefiniowane czynności, które należy wykonać na danym etapie projektu (z ang. „deliverables”). Kilka przykładów:
- Aktualizacja biznesplanu o aktualny poziom planowanych kosztów produktu i procesu
- Wykonanie analizy „zrób lub kup” (z ang. “make or buy”)
- Wykonanie dokumentacji technicznej
- Wykonanie analizy wykonalności
- Weryfikacja możliwości patentowych
- Przygotowanie planu testów
- Potwierdzenie zgodności ze standardem “XYZ”
- Realizacja planu testów i prezentacja wyników walidacji
- Weryfikacja poziomu cen porównywalnych produktów konkurencji i poziomu akceptacji ceny przez potencjalnych Klientów
- Weryfikacja obecnej i planowanej funkcjonalności produktu z oczekiwaniami potencjalnych Klientów, tzw. Głos Klienta (z ang. VoC Voice of Customer)
- Itd
Połączenie wszystkich czynności z poziomami dojrzałości produktu tworzy macierz, która jasno określa, co na koniec każdego poziomu dojrzałości musi być dostarczone.
I to właśnie pozwala nam śledzić wskaźnik, który nazwałem dostarczone rezultaty i jest pokazany na poniższym wykresie.
Niebieska linia określa liczbę zakończonych czynności, które należy wykonać na każdym poziomie dojrzałości. Żółte słupki pokazują ile czynności zespół już zainicjował, rozpoczął nad nimi pracę i są one w trakcie realizacji. Zielone słupki pokazują ile rezultatów zespół już przygotował i jest gotowy do ich zaprezentowania.

Kilka słów na temat interpretacji tego co możemy zobaczyć na wykresie.
Pierwsze dwa etapy zostały zakończone prawidłowo. Wszystkie zaplanowane rezultaty zostały dostarczone w ostatnim miesiącu każdego poziomu.
Spójrzmy na etap pierwszy, Przez pierwsze dwa miesiące zespół zainicjował pracę nad dwoma czynnościami (zaznaczone strzałką na wykresie powyżej). Gdyby utrzymał takie (niskie) tempo to szanse na dostarczenie 10 rezultatów w maju byłyby bardzo małe. Lider projektu widząc dynamikę rozpoczynania i dostarczania rezultatów na bieżąco powinien reagować. Reakcja może polegać na inicjowaniu czynności, które pozwolą osiągnąć założony rezultat lub z wyprzedzeniem wnioskować o przedłużenie poziomu. Ewentualnie można jeszcze w ramach poszerzonego zespołu projektowego zrewidować cel poziomu, w zakresie ilości rezultatów lub ich definicji. Siłą tego wskaźnika jest pełna transparentność podczas trwania wszystkich etapów oraz możliwość wcześniejszej reakcji, co pozwala uniknąć zaskoczenia oraz gorączkowych przygotowań przed zakończeniem etapu.
W trzecim etapie zespół nie dostarczył wszystkich rezultatów na czas (zaznaczone strzałką na wykresie poniżej), więc będzie musiał wybrać pomiędzy wydłużeniem czasu trwania poziomu lub długiem technologicznym.

Wypełnienie technicznych wymagań
Lista technicznych wymagań, zawiera wszystkie parametry techniczne produktu, które produkt musi lub byłoby dobrze gdyby je spełniał. Te dwa rodzaje kryterium oceny muszą być zdefiniowane na początku projektu. Te które muszą być spełnione, są niezbędne do tego, aby produkt był uznany na końcu projektu jako gotowy do oferowania Klientom. Nie spełnienie chociaż jednego jest dyskwalifikujące. Kryterium “dobrze by było gdyby spełniał” (z ang. nice to have) to te wymagania, które podnoszą atrakcyjność produktu ale nie są niezbędne.
Lista ta jest rodzajem zobowiązania zespołu projektowego, do dostarczenia produktu, który będzie spełniał zdefiniowane kryteria techniczne. Potwierdzeniem każdego wymagania musi być wynik testu, analizy lub inny dokument jasno weryfikujący zdefiniowane kryterium. Wyniki te będą podstawą do stworzenia dokumentacji technicznej produktu przedstawianej Klientom. Bedą również ważnym źródłem informacji, w analizach późniejszych potencjalnych reklamacji z rynku.
Budowa wskaźnika i sposób jego realizacji jest analogiczny jak w przypadku opisanej powyżej ilości dostarczonych rezultatów.
Minimalizacja ryzyk konstrukcji / koncepcji – FMEA
Często powtarzam członkom zespołów projektowych, że ich najważniejszym zadaniem jest praca z ryzykiem. W początkowej fazie projektu muszą te ryzyka znaleźć, nazwać i oszacować ich istotność. Później znaleźć sposób na ich eliminację lub minimalizację, żeby w końcu zweryfikować skuteczność podjętych działań.
W projektach technicznych narzędziem, które wspiera te procesy jest FMEA (z ang. Failure Mode and Effects Analysis – analiza rodzajów i skutków możliwych błędów), zarówno to pierwsze związane w początkowej fazie projektu z konstrukcją – DesignFMEA jak i te tworzone na potrzeby analizy procesu produkcyjnego ProcessFMEA.
Z punktu widzenia budowy wskaźnika, który mierzy te ryzyka ważny jest cel, który zespół projektowy musi osiągnąć na końcu projektu. Firmy różnie definiują ten poziom. Jeszcze niedawno określano go poziomem maksymalnej wartości RPN-ów (Risk priority number – priorytet ważności ryzyka wrażany liczbowo), teraz poziomem AP (action priority – priorytet istotności ryzyka określany jako wysoki, średni, niski). Bez względu na to, jak mierzymy ryzyko sugeruję przetłumaczenie celu na poziomy dojrzałości i powiązanie go w czasie z kampaniami testowym, które pozwalają na weryfikację ryzyk w warunkach testowych – czyli najbardziej zbliżonych do rzeczywistych w warunkach projektu.
Budowa wskaźnika i sposób jego realizacji są trochę inne od poprzednich. Wynika to z faktu, że drogę dojścia do celu można zbudować dopiero po zbudowaniu pierwszego DFMEA (wcześniej nie wiadomo jakie i ile ryzyk jest poniżej wymaganego progu). Pierwsze DFMEA można zbudować dopiero wtedy, kiedy koncepcja techniczna jest gotowa i można rozpocząć jej analizę.
Podobnie sytuacja wygląda w przypadku PFMEA, którego rozpoczęcie jest możliwe po zdefiniowaniu kroków procesowych produkcji.
Na poniższym przykładzie pokazano obraz ryzyk na koniec projektu. Należy zauważyć, że przewidywania różniły się od realizacji, ale patrząc na krzywą „plan weryfikacji ryzyk” widać, że zespół miał plan na minimalizację i weryfikację każdego z nich.

Jest sytuacją zupełnie normalną w przypadku tego wskaźnika, że cel (ilość ryzyk) będzie się zmieniał. Pamiętajmy, że pierwszy cel powstał w momencie zainicjowania analizy FMEA. Wiedza zespołu była wtedy ograniczona. Wraz z rozwojem projektu, kolejnymi testami, kontaktami z klientami i zrozumieniem tego co można osiągnąć w ramach tej konstrukcji (designu), ilość ryzyk może spadać lub rosnąć. Na poniższym wykresie jest pokazany przypadek podobnej sytuacji jak na poprzednim, z tym że teraz (w marcu drugiego roku projektu), zespół zidentyfikował 5 nowych ryzyk (20 zwiększyło się do 25). W związku z tym zespól przygotował plan ich weryfikacji oraz przebudował krzywą planu weryfikacji. Plan weryfikacji ryzyk to lista testów albo innych czynności, z określonym kryterium oceny, które po ich wykonaniu pozwalają zmienić lub utrzymać status ryzyka ze względu na jego poziom (poniżej lub powyżej celu). To jeden z dokumentów powiązanych, o których wspomniałem wcześniej, które należy na bieżąco uzupełniać aby zachować wiarygodność obserwowanego wskaźnika.

Podsumowując, w mojej opinii ilość kluczowych wskaźników w projekcie można zawęzić do sześciu (siedmiu, jeżeli rozbić FMEA na DesignFMEA i ProcessFMEA).
Co z jednej strony minimalizuje czas ich przygotowania oraz analizy, z drugiej, pokazuje kondycję projektu z perspektywy założonej jakości, kosztów oraz czasu dostarczenia.
Wybór potrzebnych wskaźników, ich poprawne zaprojektowanie, systematyczne i rzetelne aktualizowanie oraz analiza, pozwala na pełną kontrolę głównych parametrów projektu, przy minimalnym nakładzie pracy i koncentracji zasobów na najważniejszych i najpilniejszych aspektach.
Jest to niezastąpione narzędzie do dyspozycji każdego lidera projektu lub osoby odpowiedzialnej za grupę projektów, które może jadnak stać się uciążliwym balastem, jeżeli zapomnimy o czterech wspomnianych zasadach ich efektywnego używania.
-

[…] Proces generowania danych wejściowych i wyjściowych trwa tak długo, jak długo wartość ryzyk jest na nieakceptowalnym przez organizację poziomie. Takie podejście pozwala na zdefiniowanie jasnego kryterium zakończenia prac projektowych. Zdarza się, że zespół projektowy nie potrafi jasno zdeklarować kiedy nastąpi koniec ich prac – no bo przecież zawsze można coś poprawić lub zrobić trochę inaczej… Ocena poziomu ryzyk jest tu bardzo pomocna i pomimo swojego subiektywnego charakteru, może być obiektywnym kryterium końca prac projektowych. Łatwo też w oparciu o to kryterium zbudować projektowy wskaźnik KPI (patrz artykuł “6 kluczowych wskaźników projektowych“). […]
LikeLike

Leave a comment