Zamknięcie projektu wygląda prawie zawsze tak samo. Ostatni sprint, protokół odbioru, mail do sponsora z podziękowaniami i tort w kuchni. Tydzień później zespół siedzi w nowym temacie, budżet jest rozliczony, system działa. Na tym kończy się historia, choć z punktu widzenia firmy dopiero się zaczyna, bo nikt nie sprawdził jednej rzeczy: czy to, po co ten projekt uruchomiono, w ogóle się wydarzyło.
Sam mam na koncie projekty "dowiezione" w ten sposób. Wdrożenie odebrane, użytkownicy przeszkoleni, a pół roku później stara tabelka w arkuszu wciąż żyła obok nowego systemu, bo tak było szybciej. Formalnie sukces. Realnie porażka, o której nikt nie wiedział, bo nikt nie zapytał.
Ten wpis jest o tym, jak zadać to pytanie i dostać odpowiedź, którą da się obronić.
Wdrożone, działa, dowiozło wartość: trzy różne rzeczy
Zacznę od rozróżnienia, bo bez niego reszta nie ma sensu.
"Wdrożone" znaczy, że rozwiązanie jest na produkcji. Odbiór podpisany, testy akceptacyjne zaliczone. To miara dostarczenia i mówi tylko tyle, że projekt zrobił to, co miał w zakresie.
"Działa" znaczy, że rozwiązanie jest używane i nie sypie się. Ludzie się logują, proces przechodzi od początku do końca bez ręcznych obejść. To już więcej, bo obejmuje adopcję, ale nadal nic nie mówi o tym, czy firmie się to opłaciło.
"Dowiozło wartość" znaczy, że stało się to, co obiecywał business case. Proces jest szybszy, błędów jest mniej, klient dostaje odpowiedź w krótszym czasie. To jedyna z trzech miar, która interesowała sponsora w dniu, w którym zatwierdzał budżet. I paradoksalnie jedyna, której prawie nigdy nie sprawdzamy.
W BABOK-u ta praca ma swoją nazwę: ocena rozwiązania. Sprawdzasz, jak wdrożone rozwiązanie radzi sobie w realnym użyciu, mierzysz jego wyniki wobec oczekiwań i szukasz ograniczeń, które blokują pełną wartość. Na papierze osobny obszar wiedzy. W praktyce najczęściej pomijany etap całej analizy.
Dlaczego prawie nikt tego nie robi
Nie z lenistwa. Z konstrukcji projektu.
Projekt ma początek i koniec. W dniu zamknięcia zespół się rozchodzi, kierownik dostaje kolejny temat, a budżet przestaje istnieć. Analiza powdrożeniowa musiałaby się wydarzyć kilka miesięcy po tym końcu, czyli w momencie, w którym formalnie nie ma już ani ludzi, ani budżetu.
Sponsor też jest już gdzie indziej. Zatwierdzał business case dawno temu, w międzyczasie miał reorganizację i nowy priorytet. Wracanie do starego tematu z pytaniem "czy to się opłaciło" jest dla niego niewygodne z dwóch powodów naraz: jeśli tak, to nic nowego, a jeśli nie, to musi coś z tym zrobić.
Jest jeszcze trzeci powód, najmniej wygodny. Nikt nie chce być osobą, która po zakończonym i świętowanym projekcie przynosi wiadomość, że efekt jest inny niż zakładano. Więc pytanie nie pada, a organizacja uczy się, że projekty "się udają", bo zostały odebrane.
Analityk jest w tej układance najlepiej ustawiony, żeby to zmienić. Zna business case, bo często sam go pisał. Zna proces sprzed zmiany, bo go modelował. Zna użytkowników, bo zbierał od nich wymagania. Nikt inny nie ma tego kompletu.
Co mierzyć
Lista jest krótsza, niż się wydaje. Sześć obszarów, każdy z jednym pytaniem.
Wskaźniki z business case'u. Punkt wyjścia. Jeśli projekt obiecywał krótszy czas obsługi wniosku albo mniej reklamacji, to właśnie te liczby sprawdzasz jako pierwsze. Jeśli business case nie miał liczb, to już jest pierwszy wniosek do raportu. Jak powinno wyglądać uzasadnienie z miarami, żeby dało się je później sprawdzić, opisałem we wpisie o business case i uzasadnieniu projektu.
Użycie. Ilu ludzi realnie pracuje w nowym rozwiązaniu wobec tych, którzy mieli w nim pracować. Jak często. Które funkcje są dotykane, a które leżą odłogiem. System, w którym loguje się połowa docelowych użytkowników, nie dowozi połowy wartości, tylko zwykle dużo mniej, bo druga połowa i tak musi jakoś dostać swoje dane.
Obejścia. Najbardziej niedoceniana miara. Arkusz "tymczasowy", który ma dwa lata. Mail z załącznikiem wysyłany równolegle do wpisu w systemie, na wszelki wypadek. Ręczne przepisywanie danych między dwoma ekranami. Każde obejście to miejsce, w którym rozwiązanie nie zrobiło tego, co miało, a użytkownik sam sobie poradził. Obejść nie ma w logach. Trzeba iść i zobaczyć.
Koszty utrzymania. Licencje, wsparcie, czas zespołu IT, integracje, które trzeba doglądać. Business case zakładał jakiś poziom kosztu po wdrożeniu. Sprawdź, czy rzeczywistość się w nim mieści.
Incydenty. Liczba zgłoszeń, ich rodzaj, czas naprawy. Przede wszystkim: czy powtarza się ten sam typ błędu, bo to sygnał, że problem siedzi w rozwiązaniu, nie w użytkownikach.
Czas procesu przed i po. Jeśli zmiana dotyczyła procesu, a prawie zawsze dotyczy, porównujesz przebieg końcowy z tym sprzed wdrożenia. Ile trwa od zgłoszenia do zamknięcia, ile kroków, ile przekazań między osobami. Przydaje się tu warsztat z analizy procesów as-is i to-be, tylko że tym razem model "to-be" konfrontujesz z tym, co realnie się dzieje.
Procedura krok po kroku
Tak to robię, gdy mam wolną rękę. Gdy nie mam, robię tyle, ile się da, ale w tej kolejności.
1. Wróć do business case'u i miar bazowych
Otwórz dokument, na podstawie którego projekt dostał budżet. Wypisz z niego wszystkie obietnice, które da się zmierzyć. Obok każdej dopisz wartość sprzed projektu, jeśli ktoś ją zebrał. Jeśli nie zebrał, dopisz "brak danych bazowych" i nie udawaj, że to nie jest problem. Wróci w kroku czwartym.
2. Ustal okno pomiaru
Nie mierz w pierwszym tygodniu po wdrożeniu, bo zmierzysz chaos przejścia, nie rozwiązanie. Typowe okna to trzydzieści dni dla adopcji i incydentów oraz dziewięćdziesiąt dla wskaźników biznesowych, które potrzebują czasu, żeby się ustabilizować. Wybierz i zapisz przed pomiarem, nie po, bo pokusa dopasowania okna do wyniku jest zbyt duża.
3. Zbierz dane ilościowe i głos użytkowników
Liczby weź z systemu: logi, raporty, zgłoszenia, czasy. Osobno idź do ludzi. Nie z ankietą, tylko z dwoma pytaniami: co robisz inaczej niż przed wdrożeniem i gdzie sobie radzisz obok systemu. Pół godziny z trzema osobami z różnych ról daje więcej niż stos wypełnionych formularzy. Obejścia wychodzą właśnie tam.
4. Porównaj z oczekiwaniem
Tabela z trzema kolumnami: obiecane, bazowe, zmierzone. Nic więcej. Wiersze, w których "zmierzone" jest gorsze od "obiecanego", to Twoje luki. Wiersze bez wartości bazowej to luki w pomiarze i też trzeba je nazwać, bo bez nich część obietnic pozostaje niesprawdzalna.
5. Nazwij luki i ich przyczyny
Każda luka ma jedną z czterech przyczyn i od tej diagnozy zależy wszystko dalej.
Rozwiązanie: system nie robi tego, co miał, albo robi to źle. Wdrożenie: rozwiązanie jest dobre, ale migracja, konfiguracja lub uruchomienie zostały skopane. Proces: system działa, ale proces wokół niego nie został zmieniony i ludzie pracują po staremu z nowym narzędziem. Ludzie: brak umiejętności, brak motywacji, brak czasu na naukę.
Ta sama luka, na przykład niska adopcja, może mieć każdą z tych przyczyn. Poprawianie systemu, gdy problem jest w procesie, spala budżet i nic nie zmienia.
6. Rekomendacje
Dla każdej luki jedna z czterech opcji: poprawić, douczyć, wycofać, zaakceptować. Ta ostatnia jest legalna. Czasem luka jest realna, ale jej zamknięcie kosztuje więcej, niż daje, i uczciwiej powiedzieć to wprost, niż udawać plan naprawczy.
7. Raport na jedną stronę i decyzja
Jedna strona. Tabela z kroku czwartego, lista luk z przyczynami, rekomendacje z kosztem i terminem. Na dole miejsce na decyzję sponsora z datą. Raport, pod którym nikt niczego nie zdecydował, jest notatką, nie analizą.
Jak zabezpieczyć pomiar już na etapie wymagań
Największa dźwignia nie leży po wdrożeniu. Leży w pierwszych tygodniach projektu, gdy jeszcze nikt nie myśli o ocenie. Trzy rzeczy do zrobienia wtedy, gdy zbierasz wymagania.
Miary bazowe. Zanim ktokolwiek zacznie budować, zmierz proces w obecnym kształcie: czas, liczbę kroków, liczbę błędów. To zwykle jeden dzień pracy i jedyny moment, w którym te dane da się zebrać, bo po wdrożeniu stary proces przestaje istnieć.
Kryteria sukcesu. Nie "poprawa obsługi klienta", tylko konkretny wskaźnik z wartością docelową i oknem pomiaru. Jak dobierać wskaźniki, żeby mierzyły skutek, a nie aktywność, rozpisałem we wpisie o metrykach i KPI. Kryteria sukcesu różnią się od kryteriów akceptacji: te drugie mówią, kiedy rozwiązanie jest gotowe do odbioru, te pierwsze, kiedy projekt się opłacił. Testy akceptacyjne UAT sprawdzają "wdrożone". Kryteria sukcesu sprawdzają "dowiozło wartość". Jedno nie zastępuje drugiego.
Właściciel pomiaru. Imię i nazwisko osoby, która po zamknięciu okna pomiaru wróci z liczbami. Zapisane w dokumencie projektu, z datą. Bez tego pomiar nie ma szansy, bo w dniu, w którym miałby się wydarzyć, projekt już nie istnieje. Zwykle tą osobą jest analityk, bo zostaje w organizacji dłużej niż projekt.
Jeśli te trzy rzeczy są na miejscu, analiza powdrożeniowa to dwa dni pracy. Jeśli ich nie ma, to archeologia.
Przykład: typowy proces obsługi zgłoszeń
Weźmy typową sytuację, bez nazw i bez kwot. Firma wdraża nowy system do obsługi zgłoszeń wewnętrznych, na przykład wniosków o dostępy. Business case obiecywał krótszy czas realizacji, mniej pytań "co z moim wnioskiem" i odciążenie zespołu, który te wnioski obsługuje.
Wdrożenie zamknięte, testy akceptacyjne zaliczone, formularz w intranecie działa. Po kwartale analityk wraca do tematu.
Liczby z systemu: czas realizacji nieco krótszy niż wcześniej, ale daleko od obietnicy. Adopcja wysoka, bo starą ścieżkę wyłączono. Incydentów mało. Na papierze umiarkowany sukces.
Rozmowy z użytkownikami pokazują coś innego. Wnioskodawcy wypełniają formularz, a potem i tak piszą maila do osoby z zespołu obsługi, bo w systemie nie widać, na jakim etapie jest wniosek. Zespół obsługi z kolei prowadzi własny arkusz, w którym śledzi wnioski wymagające dodatkowej zgody przełożonego, bo system tego kroku nie obsługuje. Dwa obejścia, których żaden log nie pokazał.
Diagnoza: luka w czasie realizacji ma przyczynę w procesie (krok zgody przełożonego istnieje, ale poza systemem) i częściowo w rozwiązaniu (brak widoczności statusu dla wnioskodawcy). Ludzie i wdrożenie są w porządku.
Rekomendacje: poprawić system o widok statusu, włączyć krok zgody do procesu w systemie zamiast obok, zaakceptować pozostałą lukę w czasie do kolejnego pomiaru. Sponsor decyduje w tydzień, bo dostał jedną stronę z konkretami, nie prezentację na czterdzieści slajdów.
Bez tej analizy firma miałaby "wdrożony system" i dwa nieformalne procesy obok niego przez kolejne lata.
Typowe błędy
Mierzenie dostarczenia zamiast skutku. Raport powdrożeniowy, w którym stoi "wdrożono w terminie i w budżecie", odpowiada na pytanie, którego nikt nie zadał. Termin i budżet to miary projektu. Skutek to miara rozwiązania.
Ankieta zadowolenia jako jedyna miara. Ludzie w ankietach są uprzejmi, a zadowolenie użytkownika i wartość dla firmy to różne rzeczy. Można lubić system, który niczego nie zmienił. Ankieta może być jednym ze źródeł, nigdy jedynym.
Brak danych "przed". Najczęstszy powód, dla którego analiza powdrożeniowa kończy się zdaniem "trudno powiedzieć". Bez punktu odniesienia każda liczba po wdrożeniu jest tylko liczbą. Dlatego miary bazowe z etapu wymagań ważą więcej niż cała reszta tej procedury razem wzięta.
Raport bez decyzji. Trzydzieści stron, dwadzieścia wykresów, zero podpisów. Analiza, która nie prowadzi do decyzji, nie zmienia niczego i uczy organizację, że oceny robi się do szuflady.
Mylenie z retrospektywą. Retrospektywa patrzy na to, jak zespół pracował, i uczy zespół. Analiza powdrożeniowa patrzy na to, co rozwiązanie zmieniło w firmie, i uczy organizację. Obie są potrzebne i nie zastępują się nawzajem; o tej pierwszej napisałem osobno we wpisie o retrospektywie projektu i lessons learned.
Co z tym zrobić w poniedziałek
Jeśli masz za sobą zamknięty projekt, wróć do jego business case'u i sprawdź, czy da się z niego wypisać choć jedną mierzalną obietnicę. Jeśli tak, zmierz ją. Jeśli nie, to jest Twój pierwszy wniosek i pierwsza rzecz do poprawy w kolejnym projekcie.
Jeśli jesteś na początku projektu, dopisz do wymagań trzy linijki: miary bazowe, kryteria sukcesu, właściciel pomiaru. To najtańsza rzecz, jaką możesz zrobić dla wartości, którą ten projekt ma dowieźć.
Ocena rozwiązania to jedna z kompetencji, które odróżniają analityka dostarczającego dokumenty od analityka, przy którym firma podejmuje lepsze decyzje. Jeśli chcesz zobaczyć, gdzie ta umiejętność leży na mapie całego zawodu i co jeszcze wchodzi w skład warsztatu, zajrzyj do roadmapy kompetencji analityka biznesowego. Jest publiczna, bez zakładania konta.