Blog: Zarzadzanie projektami

Jak ustalić wspólną wizję projektu?

Jak ustalić wspólną wizję projektu?
  • 631 views

Nie jest tajemnicą, że zdecydowana większość prowadzonych w Polsce projektów kończy się po upływie zaplanowanego czasu i przekracza ustalony budżet, a zamawiający często nie do końca są zadowoleni z osiągniętego rezultatu. Z mojego doświadczenia w pracy projektowej wynika, że w wielu wypadkach klienci nie poświęcają wystarczająco dużo czasu na dokładne wyjaśnienie dostawcy, co tak naprawdę chcieliby otrzymać oraz na przedstawienie własnej wizji projektu. Z kolei dostawca zazwyczaj nie próbuje skłonić zamawiającego do rzeczowej odpowiedzi na pytania i omówienia oczekiwanego zakresu.

Udostępnij!

Co można wykorzystać do uwspólnienia wizji projektu?

Ten moment w projekcie jest kluczowy – zależy od niego wzajemne zrozumienie i satysfakcja.  Warto usiąść z klientem i zapytać go o potrzeby oraz to jak wyobraża sobie uzyskany efekt, a więc jaka jest jego wizja projektu. Dzięki takiej rozmowie łatwiej będzie zrozumieć zakres oczekiwanej zmiany. Zgłaszane przez klientów pomysły opierają się zwykle na wiedzy potocznej i niespecjalistycznej; zrozumiawszy wizję zamawiającego, dostawca będzie mógł zaproponować lepsze rozwiązanie.

Przedstawmy to na konkretnym biznesowym przypadku. Firma „A” zajmuje się podnajmem –  szuka dużych mieszkań w tak zwanych miastach studenckich, dzieli je na więcej pokoi i wynajmuje je poszukującym osobom. W pewnym momencie oferta  zawiera już ponad dwa tysiące pokoi i firma A przestaje sobie radzić  z ręcznym weryfikowaniem płatności. Aby zaradzić temu problemowi, decyduje się na zamówienie aplikacji, w której po opłaceniu czynszu każdy najemca musi zaznaczyć dokonanie przelewu. Łatwo zauważyć, że bez dodatkowych zabezpieczeń łatwo obejść ten warunek – zaznaczyć płatność w aplikacji bez  dokonania przelewu,  a także dokonać przelewu bez zaznaczania. Na szczęście jednak dostawca zapytał  swojego klienta – czyli firmę A –  jakiej zmiany potrzebuje i mógł podpowiedzieć, że wystarczy połączyć system bankowy z  systemem do wystawiania umów. Właśnie dlatego tak ważne jest zrozumienie, czego dokładnie potrzebuje zamawiający i jakiego zakresu projektu się spodziewa.

We wspólnej pracy nad wizją projektu może pomóc wygodny i prosty model as is…….to be….(jak jest? jak ma być?). Jego szczegóły są przedstawione na poniższym schemacie:

Jak negocjować zaangażowanie klienta w ustalaniu zakresu projektu?

Bardzo często spotykam się z sytuacją, w której klient zleca dostawcy realizację projektu i najchętniej zapomniałby o niej aż do otrzymania gotowego rozwiązania. Wprowadzanie zmian i zarządzanie wizją projektu musi się opierać na komunikacji. Jeśli obie strony potrafią jasno ustalić parametry produktu końcowego, zaangażowanie klienta będzie wymagało po prostu okresowych przeglądów tworzonego produktu. Dzięki temu zarówno klient, jak i dostawca mogą sprawdzać, czy projekt na pewno zmierza we właściwym kierunku.

Obecnie bardzo wielu klientów jest w stanie powiedzieć co ma się zmienić w ich otoczeniu biznesowym, nie bardzo jednak wiedzą, jakie parametry powinien posiadać produkt końcowy. To właśnie w takich projektach zaangażowanie zamawiającego jest absolutnie niezbędne. Coraz częściej zakłada się, że klient powinien wydelegować do projektu specjalną osobę, która będzie brać w nim udział. Takie podejście umożliwia podejmowanie decyzji na bieżąco oraz ułatwia szybkie przedstawianie informacji zwrotnych na temat zakresu projektu.

Jak ważne są pytania „dlaczego tego potrzebujesz” i ”co chcesz osiągnąć”?

Ku mojemu zdziwieniu, dostawcy wciąż oczekują od klienta informacji o tym, czym jest produkt końcowy.  We wspomnianej firmie zajmującej się podnajmem mieszkań, kluczowe okazało się inne pytanie, a mianowicie co firma chce osiągnąć dzięki nowej aplikacji. Pewnego razu uczestniczyłam w projekcie optymalizacji linii produkcyjnej. Klientowi zależało na tym, aby linia produkowała więcej. Zadałam klasyczne pytanie – dlaczego właściwie tego chciał? Oparłam je o bieżącą analizę sytuacji, z której wynikało, że linia nigdy nie była wykorzystywana na 100% swojej mocy. W trakcie rozmowy wyszło na jaw, że tak naprawdę nie chodziło wcale o linię, tylko o koszty zatrudniania pracowników. Klient uznał, że jeśli linia będzie działać szybciej, to zapłaci za mniejszą liczbę roboczogodzin. Jest to oczywiście jakaś metoda, ale znaleźliśmy lepszą i zdecydowanie bardziej odpowiadającą na zaistniałą potrzebę. Chodziło rzecz jasna o robotyzację linii produkcyjnej.

Próbuję w ten sposób pokazać, że wiedza o przyczynach realizowania projektów jest niezbędna – właśnie po to, by ustalić zakres projektu i znaleźć najbardziej pasujące rozwiązanie.