W ostatnich latach miałem przyjemność liderować kilku udanym wdrożeniem informatycznym. Były to hurtownie danych, narzędzia analizy online, portale raportowe i in. Brałem też udział w procesach naprawczych wdrożeń nieudanych. Liderowałem też projektom nieudanym - takim które dostarczyły rozwiązanie, ale np. nie udało się zmieścić w budżecie czy harmonogramie albo osiągnąć wszystkich założeń.
Na tych ostatnich projektach chciałbym skupić się w niniejszym blogu.
Co charakteryzowało projekty problematyczne?
Wdrożenie na siłę.
A innymi słowy - nikt o to nie prosił, ale o to macie. Pod tym pojęciem klasyfikują się następujące przedsięwzięcia:
Zaczynamy od narzędzia - najczęściej zainspirowani fantastyczną prezentacją na konferencji czy innym wydarzeniu branżowym, jak również dyskusją w kuluarach (no my to już mamy, my aktualnie wdrażamy, my już mamy zatwierdzony budżet itp.) podejmujemy decyzję, że musimy dane rozwiązanie wdrożyć. Z tą decyzją "w kieszeni" szukamy miejsca gdzie...
I co, zawsze to będziesz robić w Excelu? - jest to osobna kategoria, wychodząca w założenia, że wszystko co robimy ręcznie, jest złe. Nie bierzemy pod uwagę specyfiki danych, precyzyjnego charakteru ręcznej pracy tudzież jakie straty poniesiemy, całkowicie automatyzując proces (i np. tracąc dostęp do pewnych informacji, które były produktem dodatkowym ręcznej obróbki)
Brak agentów zmiany - nie można realizować projektu bez zaangażowania osób, które mają korzystać z proponowanego rozwiązania już od samego początku. Jeżeli tak nie zrobimy, ryzykujemy wywołanie poczucia narzucania czegoś, czasem wręcz obaw o przyszłość itd. Warto angażować osoby, które fizycznie będą pracować z narzędziem już od dnia "0" i dawać im odczuć, że ich zdanie będzie uwzględniane.
Złe planowanie
Znowu zaczynamy od narzędzia - skuteczny projekt to tylko taki, gdzie istnieje faktyczna potrzeba np. analizy określonej informacji.
Wszystkie grzyby w jednej zupie - błąd zdarza się zwłaszcza młodszym doświadczeniem ale aspirującym project managerom z ramienia kontrolingu. Robimy tour po wszystkich interesariuszach, zbieramy ich potrzeby, a potem staramy się wszystkie na raz zrealizować. To błąd, gdyż w praktyce 80% tych potrzeb to jest tzw. nice to have, z którego realnie nikt nie będzie korzystać. Często wręcz okazuje się, że wdrożenie tych pierwszych 20% jest już tak dużym skokiem jakościowym, że o pozostałych potrzebach stakeholderzy wręcz zapominają i trzeba im o nich przypominać. Warto też zastanowić się, czy np. potrzebujemy od razu wszystkich możliwych szczegółów, przecięć, wymiarów i faktów. Odpowiedzią na ten problem jest przede wszystkim doświadczenie i znajomość biznesu. Np. jeżeli dana potrzeba dotyczy obszaru o mniejszym znaczeniu dla przedsiębiorstwa, to może chwilę poczekać. Ewentualnie widzimy, że dana potrzeba pojawia się częściej u różnych interesariuszy. Wtedy możemy zdecydować o nadaniu jej wyższego priorytetu.
Szacujemy korzyści na siłę - tu problem jest skomplikowany. Wiemy ile zajmuje np. ręczna obróbka jakichś danych. W trakcie prezentacji jakiegoś narzędzia widzimy, jak to wszystko sprawnie i fajnie wygląda. Tylko nikt nie mówi, ile czasu potrzeba na opracowanie np. modelu w narzędziu i jak wygląda proces jego zasilania. Np. czy jest w ogóle możliwe włożenie pewnych danych do narzędzia bez ich ręcznej obróbki. Czasem okazuje się, że kosztuje to więcej czasu (zwłaszcza na początku) niż sprawnie wykonywany proces "ręczny". Dobrym pomysłem jest tu wykonanie z dostawcą proof of concept, polegającego np. na warsztacie gdzie próbujemy rozwiązać określone (przygotowane przez nas) problemy.
Nie trzymamy się planu - a jak już mamy plan z celem i dobrze oszacowanymi korzyściami, to rozjeżdża nam się plan. Bo akurat mamy prognozę, bo wpada nieplanowana prezentacja. Na spotkanie dotyczące tego projektu nie przychodzi nikt z interesariuszy. Rozwiązaniem jest np. włączenie realizacji takiego projektu do indywidualnych KPI zaangażowanych osób.
Współpraca z dostawcą
Źle zdefiniowany zakres współpracy - np. okazuje się, że pewnych rzeczy dostawca nam nie dostarczy (choć obiecywał w prezentacji). Np. pamiętam sytuację, gdzie wymagaliśmy wdrożenia pewnej funkcjonalności. Zostało to nam obiecane, niemniej na etapie wdrożenia okazało się, że ta funkcjonalność jest dopiero na roadmapie producenta narzędzia które wybraliśmy. I nie wiadomo, kiedy powstanie. Ważny jest też zakres współpracy po wdrożeniu - gwarancja, SLA itd.
Brak kompetencji do rozmowy z dostawcą - często cedujemy ten aspekt na project managerów IT. To błąd. Biznes musi uczestniczyć w rozmowach i rozumieć o czym się rozmawia. Jedyna odpowiedź na to, to doświadczenie. Na podstawie własnoręcznie wykonywanych prac lub wcześniejszych projektów. Warto zadbać, aby w naszym zespole były osoby, które takiemu zadaniu przynajmniej na papierze są w stanie podołać (piszę o tym w poście "Kontroler - kto to właściwie jest?".
Źle oszacowana wydajność - na papierze i w demo, wszystko wygląda super. W praktyce okazuje się, że super to było zanim władowaliśmy wszystkie nasze dane, albo że nasza infrastruktura IT jest niewystarczająca. Warto zadbać o upewnienie się, że wszystkie niezbędne parametry techniczne są oszacowane, zrozumiane i potwierdzone. Często pomaga też sięgnięcie po referencje od stron trzecich, np. współpracujących wcześnie z dostawcą z zapytaniem o m.in. ten właśnie aspekt wdrożenia.
Brak wsparcia
Sukces wdrożenia zależy od wsparcia dwu obszarów. Po pierwsze korzystających z wdrażanego narzędzia, o czym wyżej.
Bardzo często jest jednak potrzebne wsparcie kierownictwa przedsiębiorstwa, np. zarządu. Nadaje to odpowiednią rangę wdrożeniu, służy jako element motywacji i dopingowania do działania.
Działanie w izolacji
Trochę zaprzeczając jednemu z powyższych punktów, uważam że warto inspirować się doświadczeniami innych. Podpatrywać rozwiązania, uczestniczyć w dyskusjach i konferencjach. Nie zawsze, ale często może okazać się, że próbujemy wyważyć otwarte już dla nas szeroko drzwi, a problemu jakie mamy są już przez kogoś rozwiązane. Działa to na zasadzie wzajemności. W przyszłości również i my możemy zacząć dzielić się naszymi doświadczeniami i wiedzą w tym właśnie obszarze.
Comments