Komunikacja w projekcie – bez rozmowy się nie obejdzie

Opublikowany
27.2.2017
Komunikacja w projekcie – bez rozmowy się nie obejdzie
Opublikuj
Chcesz wiedzieć więcej?
Napisz do nas

Komunikacja to jeden z najważniejszych czynników (nie)powodzenia w projekcie. Badania The Standish Group wskazują na to, że zdaniem menadżerów IT brak zaangażowania końcowego użytkownika i niepełna specyfikacja wymagań są głównymi czynnikami pojawienia się wyzwań i niepowodzeń (całkowite niepowodzenie projektu lub rezygnacja z systemu) w projektach informatycznych.

ch.factors.pl2
f.factors.pl

W przypadku braku zaangażowania użytkowników w projekcie nie można mówić o jakiejkolwiek komunikacji. W przypadku utrudnionej komunikacji nie można mówić o zebraniu wszystkich wymagań klienta.

Komunikacja w projekcie to przepływ informacji miedzy klientem a dostawcą. Jest elementem stałym każdego projektu. Komunikacja może być wewnętrzna (w naszym zespole) i zewnętrzna (z drugim zespołem). Sprawne zarządzanie komunikacja w projekcie oszczędzi nam frustracji, nieporozumień i niedomówień. Pozwoli nam zaoszczędzić czas i pieniądze i zwiększy nasze szanse na sprawne wdrożenie systemu.

Matryca komunikacji

Niezależnie od przyjętej metodyki prowadzenia projektu, jednym z elementów, który musi zostać wypracowany wspólnie między zespołami projektowymi, jest sposób komunikacji. Na początku wspólnej pracy przy projekcie musimy określić, kto i z kim będzie wchodził w interakcje i w jakim zakresie będą prowadzone rozmowy. Jeśli tego nie zrobimy, w projekcie będzie panował chaos – informacje nie będą docierały do zainteresowanych osób. Niedotrzymanie prostego warunku:

Ola komunikuje się z panią Łucją w sprawach związanych z realizacją wymagań funkcjonalnych, a Piotrek negocjuje z panem Pawłem kwestie związane z rozliczeniem za oddaną pracę

może spowodować, że wymagania zostaną źle określone lub pominięte, a faktura źle wystawiona.

Przygotowanie do spotkania – wypracowanie wspólnego frontu

Spotkania są nieodłącznym elementem realizacji projektu wdrożeniowego. Nie ma znaczenia, czy chodzi tu o wielogodzinne spotkania analityczne na początku projektu realizowanego modelem kaskadowym, czy krótkie stand-up meetingi znane z metodyk zwinnych. Nie liczy się czy jest to spotkanie wewnętrzne czy zewnętrzne. Do każdego z nich należy się przygotować.

I tu jest cały pies pogrzebany. Nie przygotowując się do spotkania analitycznego z dostawcą ryzykujemy, że spotkanie zakończy się fiaskiem. Co prawda wydaje nam się, że pracując 4 lata jako specjalista sprzedaży w naszej firmie, doskonale orientujemy się w procesach biznesowych. Przecież wiemy, o czym będziemy rozmawiać z dostawcą. Opowiemy mu jak wygląda nasz dzień pracy, jakich informacji potrzebujemy z systemu, z jakimi problemami się zmagamy. Zbyt często, niestety, okazuje się, że Michał, z którym siedzimy biurko w biurko, pracuje zupełnie inaczej. W rezultacie, w trakcie spotkania analitycznego, którego założeniem jest przekazanie dostawcy naszych wymagań, okazuje się, że wymagania są rozbieżne.

Prosty przykład?

My do komunikacji z klientem używamy Skype. Michał przeważnie dzwoni.

My chcemy, aby konwersacja z klientem była zapisana w naszym nowym CRM, a Michał chce, aby nagranie z jego rozmowy było dostępne do odsłuchu. Dostawca musi zintegrować nasz system ze Skype i z centralą telefoniczną – koszt wdrożenia rośnie, a budżet jest ograniczony.

Wdrożenie nowego systemu to okazja do przekształcenia naszej firmy. Do uproszczenia naszych procesów biznesowych. Do usystematyzowania pracy naszych zespołów. Możemy to zrobić sami, wewnętrznie, albo możemy skorzystać z pomocy analityków dostawcy. Być może będziemy musieli zrezygnować z komunikacji za pomocą Skype. Być może Skype zostanie głównym narzędziem komunikacji z klientem.

Wypracowanie wspólnego frontu jest ważnie nie tylko w przypadku dużego spotkania analitycznego. W ramach każdej rozmowy, negocjacji czy analizy istotne jest, aby podejmować świadome i spójne decyzje.

Za długi dokument, którego nikomu się nie chce pisać i nikomu nie chce się czytać

To jest w dużym stopniu przesada – instrukcja obsługi, dokument analizy czy notatka ze spotkania nie są aż taką solą w oku.

W przypadku instrukcji obsługi, możemy podejść do niej jak pies do jeża; stwierdzić, że przecież nie mamy problemu z obsługą innych programów, a z komputerem jesteśmy za pan brat i wyrzucić ją przez okno (w przenośni). A skoro spodziewamy się, że tak do niej podejdziemy, to po co w ogóle ją pisać (i płacić za nią). Instrukcja obsługi nie istnieje jednak bez powodu. Jest niezbędna dla użytkownika – pozwala przekazać wiedzę o systemie w usystematyzowanej formie. Nie wyrzucajmy jej przez okno, bo prędzej czy później będziemy musieli do niej zajrzeć.

Dokument analizy stanowi podstawę dla dalszej pracy przy projekcie. Powstaje na bazie spotkań analitycznych. Jest rezultatem rozmowy z konsultantem. Musimy go przeczytać, nawet jeśli wydaje nam się, że skoro opisuje nasza sytuacje w firmie, to wiemy co w nim jest i nie ma po co tego czytać. Zwłaszcza jak dostajemy dokument mający 400 stron. Kolana się pod nami uginają. Dostawca przygotował 200 diagramów, których znaczenia nie rozumiemy. Do tego treść: słownik pojęć, lista wymagań i potrzeb, opisy słowne procesów. Przeczytanie tego ze zrozumieniem i opatrzenie komentarzami to nie lada wyzwanie (tak samo, jak napisanie takiego dokumentu), ale bez niego prowadzenie projektu jest znacznie utrudnione. No dobrze, 400 stron to przesada. Możemy zażartować, że i 20 stron to dużo. Niemniej jednak, dokumentacja jest nieodłącznym elementem prowadzenia projektu.

Spisanie protokołu zebrania po jego zakończeniu stanowi klauzule, podsumowanie tego, co zostało ustalone i co ma zostać przygotowane. Jest streszczeniem przepływu komunikatów ze spotkania. Jest świadectwem ustaleń z rozmowy – na wszelki wypadek, gdyby komuś coś umknęło. Pozwala wykryć punkty sporne. Stanowi punkt odniesienia dla obu zespołów i niweluje prawdopodobieństwo nieporozumienia.

„Wróg numer jeden”

Czynnikiem determinującym sukces projektu jest komunikacja.

Dlaczego?

Dlatego, że komunikacja towarzyszy nam w projekcie od samego początku. Jako klient zainteresowany wdrożeniem systemu informatycznego komunikujemy swoje potrzeby, w formie uogólnionej, potencjalnemu dostawcy. Jako dostawca odpowiadamy na potrzeby klienta, komunikujemy swoją gotowość do podjęcia projektu i zadajemy pytania, aby jak najlepiej zrozumieć potrzeby. Na podstawie rozmowy klienta z dostawcą powstaje projekt systemu, który zostaje wdrożony i oddany do użytku. Jeśli komunikacja jest efektywna, projekt przebiega sprawniej i kończy się w założonym czasie.

Czynnikiem determinującym niepowodzenie projektu jest … komunikacja.

Dlaczego?

Dlatego, że nie jesteśmy maszynami. To, jaką formę komunikatu przyjmiemy, jest podyktowane naszym doświadczeniem życiowym; tym, w jakim otoczeniu się wychowywaliśmy i przebywamy; tym, jakie książki czytamy, jakie filmy oglądamy. Używamy skojarzeń, obracamy się w pewnej przestrzeni słownej i w określony sposób definiujemy słowa. Do tego dochodzi jeszcze słownictwo branżowe. Wydaje nam się, że mówimy jasno i klarownie. Nie wiemy jednak jak zrozumiał nasz komunikat odbiorca. Nie mamy pewności, czy zrozumiał go w oczekiwany sposób.

I prawdopodobnie zrozumiał go zupełnie inaczej.

Pytajmy. Odpowiadajmy. Pokazujmy. Omawiajmy z wykorzystaniem analogii. Dajmy się poznać rozmówcy. Zaufajmy sobie. I uczmy się od siebie nawzajem.

Bo nie unikniemy komunikacji. Ważne jest tylko to, aby przebiegała ona w zdrowy sposób. Bez manipulacji, bez przemocy. Unikniemy konfliktów i nieporozumień.

Poprzedni
Następny
Następny