W poprzednim artykule wskazałem na specyficzną dynamikę wymagań związanych z realizacją projektów informatycznych oraz wymaganą (po stronie klienta) dozę elastyczności i zaangażowania. Poniżej kolejna porcja wskazówek i rad jak taką współpracę organizować.

Właściciel Produktu - najważniejsza osoba w projekcie

Z prowadzonych przez dziesiątki lat na rynku IT statystyk wynika, że brak zaangażowania klienta w projekt jest kluczową przyczyną niepowodzeń projektów budowania oprogramowania „szytego na miarę”.

To wyraźnie pokazuje, że do realizacji projektu, po stronie klienta, potrzebna jest osoba posiadająca nie tylko wiedzę, ale przede wszystkim czas, który może poświęcić na współpracę.

W zwinnych metodykach zarządzania projektem rolę taką pełni tzw. właściciel produktu (ang. Product Owner). Osoba ją pełniąca realizuje w imieniu klienta większość obowiązków związanych z zarządzaniem i przekazywaniem wiedzy dostawcy. Przede wszystkim jednak właściciel produktu ma osobistą odpowiedzialność za projekt i wynikającą z niej moc decyzyjną. Jego kluczowym obowiązkiem jest regularna ocena stanu realizacji projektu i budżetu, sterowanie kierunkiem rozwoju działań lub też decyzja o ich zakończeniu. To on dla projektu jest najważniejszą osobą w firmie i on podejmuje ostateczne decyzje.

---

Partnerzy cyklu IT w biznesie:

Dlatego też dostawcy często oczekują zagwarantowania w kontrakcie dostępności właściciela produktu w określonym wymiarze godzin w tygodniu, tak by on wspólnie z dostawcą stanowił jeden zespół projektowy.

… i wcale nie musi być informatykiem

Czy właściciel produktu musi znać się na IT? Oczywiście lepiej by tak było, ale nie jest to warunek konieczny. Kluczowe są jego umiejętności komunikacyjne i zarządcze.

Natomiast, do sprawnego wykonania swojej pracy, dostawca usług IT potrzebuje rzetelnej informacji o poziomie wiedzy z zakresu technologii informacyjnych, jaką dysponuje klient, a w szczególności właściciel produktu. Ułatwi to dostawcy przystosowanie jego przekazu tak, by był on dla klienta zrozumiały i skuteczny, a informacje potrzebne klientowi w podejmowaniu ważnych decyzji projektowych będą dostarczone w przystępny dla niego sposób. Oczywistym jest, iż dostawca, którego angażujemy do projektu musi dysponować znacznie większą wiedzą informatyczną od swojego klienta - bez tego nie byłby ekspertem. Przy odpowiednim poziomie zaufania, a przez to wzajemnej otwartości, klient ma możliwość nabyć, dodatkowo, praktyczną wiedzę.

Transparentność postępów prac jest dziś standardem i należy jej oczekiwać

Obecnie standardem na rynku B2B staje się całkowita transparentność i możliwość cotygodniowego, a nawet codziennego obserwowania postępów prac dostawcy przez klienta. Dzięki cyklicznemu nadzorowi strony mają czas na wspólną ocenę postępów w projekcie. Umożliwia to szybką reakcję na pojawiające się problemy i ewentualne szybsze zakończenie projektu, co pozwoli ograniczać dalsze jego koszty. Stąd z punktu widzenia klienta zapis umowny o transparentności jest kluczowym elementem umowy z dostawcą.

Zapewniając w kontrakcie właścicielowi produktu możliwość częstej kontroli i szybkiego zakończenia projektu, a nawet współpracy z dostawcą, unikamy jako firma sytuacji, o których słyszymy w kontekście przetargów na realizację projektów informatycznych w administracji państwowej. Tam mechanizm kontrolny uruchamiany jest rzadko, niekiedy dopiero na końcu projektu, czyli najczęściej po latach od jego startu. Niestety może się wtedy okazać, że wytworzone oprogramowanie nie odpowiada na aktualne potrzeby rynku, lub np. nie jest zgodne z obowiązującymi obecnie przepisami prawa albo też użytkownicy stworzonego rozwiązania po prostu nie chcą go używać. W konsekwencji słyszymy o zmarnowanych setkach tysięcy lub nawet dziesiątkach milionów złotych na informatyzację administracji państwowej. Opisywane tutaj rozwiązania pozwalają w praktyce zminimalizować powyższe ryzyko.

Wiele projektów powinno zakończyć się wcześniej niż planowano

Co w przypadku, kiedy współpraca z dostawcą układa się doskonale, ale projekt traci swoje uzasadnienie biznesowe? Z taką sytuacją mamy do czynienia, gdy np. w trakcie realizacji okazuje się, że konkurencja stworzyła podobne rozwiązanie szybciej, a bycie drugim na rynku nie pozwoli nam osiągnąć zamierzonych dla projektu celów finansowych. Może też być tak, że o funkcjonalność, którą w projekcie chcieliśmy stworzyć, zostanie rozbudowane oprogramowanie, jakie już w firmie mamy. Alternatywnie, że na rynku pojawi się gotowe rozwiązanie, które możemy zakupić szybko oraz kosztem znacznie mniejszym, niż inwestycja w jego budowanie tylko dla naszej firmy. Właśnie wtedy rozsądnym jest skorzystanie z możliwości szybkiego zatrzymania dalszych prac projektowych.

Podsumowując, wcześniejsze zakończenie projektu nie zawsze jest złą decyzją. Wręcz przeciwnie, często bywa uzasadniona - stąd zadbać należy o taką możliwość w kontrakcie z dostawcą.

Marcin Kaczmarek
CEO Consileon Polska