Pułapki bezkrytycznego wdrażania rozwiązań

Klient ma zawsze rację, prawda? A może wykonawca usług IT powinien kwestionować pomysły zamawiającego? Dla jego własnego dobra? Tak, ta dwuznaczność w poprzednim zdaniu była zamierzona.

Problem pierwszy „narzędzia rozwiązują problemy”

Typowy scenariusz wygląda następująco: klient jest pewny, że wdrożenie odpowiedniego narzędzia rozwiąże jakieś jego (widoczne gołym okiem) problemy. Zakłada, że zainwestowanie 5, 50 lub 500k w jakiś system, jego wdrożenie i konfigurację przyniesie mu mniej pracy i kłopotów a więcej czasu i pieniędzy.

I żeby nie było – nie twierdzę, że jest to niemożliwe! Zdarzają się takie przypadki, ale są one ekstremalną rzadkością. Często nikt tego nawet nie próbuje liczyć przed uruchomieniem projektu. Zwrot z inwestycji jest brany za pewnik. Wdrożenie zaczyna się “bo szef kazał”, „bo inni tak robią i działa”, „bo trzeba zagasić jakiś pożar”.

Niekiedy mam wrażenie, że biznes działa wedle poniższego schematu:

Pali się? Dzwońcie po IT i sypcie pieniędzmi, może przydusimy ogień!

Masz problem i myślisz, że projekt IT go rozwiąże? No to masz już 2 problemy.

Nierealistyczne oczekiwania względem narzędzi to dopiero początek kłopotów. Potem zaczyna się praca z wykonawcą, który próbuje zrozumieć organizację, proces, i… zadaje niewygodne pytania.

Klienci (a szczególnie pomysłodawcy wdrożeń) mają tendencję do skupiania się na wymyślonych przez siebie rozwiązaniach, zanim dokładnie przeanalizują problem. Jak do tego dochodzi? To proste:

• pracownicy widzą, że coś nie działa optymalnie, więc na podstawie obserwacji objawów malują w swojej głowie obraz jakiegoś gotowego narzędzia, rozwiązania,
• z tym wyobrażeniem idą do szefa, namawiając go na uruchomienie projektu,
• szef często przyjmuje punkt widzenia pracowników i zaczyna szukać firmy, która wdroży coś, co wymyślili…
• …dorzucając do ich wizji tonę swoich pomysłów przy okazji (to odrębny problem, który muszę kiedyś opisać).

Koncentrując się na objawach i wymyślonym przez siebie rozwiązaniu, tracą z oczu prawdziwy cel. Brak jest kluczowego etapu, czyli analizy przyczyn źródłowych (root cause analysis). Budowane jest jakieś rozwiązanie, ale pudruje ono jedynie objawy, nie lecząc choroby.

Takie projekty mogą potoczyć się na dwa główne sposoby:

• wykonawca sam sobie (i klientowi) szkodzi przyjmując, że zamawiający odrobił lekcję z analizy problemu i buduje rozwiązanie dokładnie tak jak klient każe. Efekt jest taki, że na końcu projektu wszyscy są zaskoczeni:
  • użytkownicy – że to co zbudowano nie rozwiązuje ich problemu,
  • kierownictwo – że wydano kasę a mimo to użytkownicy narzekają,
  • wykonawca – że klient jest wkurwiony i próbuje na koniec projektu wrzucić szereg zmian, które może jakoś uratują sytuację (niespodzianka – nie uratują),
• wykonawca od początku (najlepiej jeszcze przed podpisaniem umowy) dopytuje, kontestuje, drąży – próbuje najpierw potwierdzić sens biznesowy a potem dopiero zobowiązać się do jego dowiezienia.

Ten drugi przypadek jest dla klienta dużo trudniejszy (ale znacznie korzystniejszy!), no bo…

…na @#uj drążyć?!

Niestety, gdy – jako wykonawca – próbuję rozmawiać z klientami o prawdziwym problemie, często czują się z tym niekomfortowo. Odbierają to jako próbę podważenia ich kompetencji czy kreatywności. Myślą, że staram się wyszukiwać dodatkowe problemy w ich firmie lub sugerować, że jest źle zarządzana. Niektórzy podejrzewają nawet, że chcę zarobić dodatkowe pieniądze „wciskając im w brzuch” proces analizy problemu.

Bywa, iż zniechęcam klienta do wydawania kasy na dany projekt w jego obecnym zakresie/brzmieniu. Czyli (pozornie) podcinam gałąź na której siedzę. Pozornie, bo tym samym oszczędzam klientowi finalnego zawodu i w efekcie chronię własną reputację. Nie chcę być wykonawcą, który zostanie zapamiętany jako ten typ co – wiedząc że coś nie ma sensu – zbuduje to i weźmie za to kasę.

Klienci często uważają, że skoro już mają rozwiązanie, to rola IT powinna ograniczać się do jego wdrożenia. Gdy zadajemy pytania pomagające namierzyć źródłowy problem a czasem nawet podważyć zasadność projektu, czują się atakowani.

To dla nich niewygodna sytuacja. Oni przecież mają w głowie gotowe recepty na sukces, do których są przywiązani emocjonalnie a tu jakiś bezczelny typ sugeruje, że trzeba to jeszcze przemyśleć!

Burzymy w ten sposób pewien ułożony w głowie klienta plan, którego wykonania od nas oczekiwał. Nie każdy jest gotowy przyznać, że jego pomysł nie jest optymalnym środkiem do osiągnięcia celu. Albo, że sam cel był źle zdefiniowany.

Warto rozmawiać?

Wyzwaniem jest znalezienie odpowiedniego sposobu prowadzenia takiej dyskusji – takiego, w którym klient czuje się bezpiecznie i komfortowo, nie odbiera naszych pytań jako agresji czy podważania jego kompetencji. To umiejętność, która na pewno nie zaszkodzi w kontakcie z klientem.

Też tak masz?

Jakie są Twoje doświadczenia? Czy zdarzyła Ci się taka sytuacja? Jaki był jej finał? Czy uważasz, że należy odwieść klienta od spalenia kasy na projekt, który nie przyniesie nic dobrego? Nawet jeśli to oznacza mniejszy (lub żaden) zarobek dla Ciebie?

Czy wdzięczność klienta, ocalonego przed „złym dotykiem IT” zapłaci Twoje rachunki? A może masz szczęście i Twoi klienci z otwartymi ramionami przyjmowali pomysł kwestionowania ich zdania?