Jak zmusić klienta, aby odebrał dokumentację analityczną

Jak zmusić klienta, aby odebrał dokumentację analityczną Image courtesy of pakorn/ FreeDigitalPhotos.net

Jak sprawić, żeby zatwierdzenie dokumentacji analitycznej nie przeciągało się w nieskończoność

Dokumentacja analityczno-projektowa (szczególnie w projektach informatycznych) zwykle podlega akceptacji i odbiorowi przez klienta. Po jej oficjalnej dostawie zamawiający ma oczywiście prawo zgłaszać do niej uwagi. Są one zwykle bardzo cenne, ponieważ spory dokument nawet po wewnętrznej kontroli jakości wykonawcy nie będzie wolny od usterek. Jak jednak sprawić, żeby zatwierdzenie dokumentacji analitycznej nie przeciągało się w nieskończoność?

Procedura odbioru...

Przede wszystkim ważne jest odpowiednie określenie procedury odbioru dokumentacji projektowej. Wiadomo, że musi ona pozwalać klientowi na zgłaszanie uwag, zaś wykonawcy na uwzględnienie tych uwag i dostarczenie kolejnej wersji dokumentacji. W procedurze odbioru bezwzględnie należy określić czas, jaki ma zamawiający na zgłoszenie uwag, zaś wykonawca na ich uwzględnienie (zwykle jest to od 3 do 5 dni roboczych). Warto także pamiętać o jednym z pozoru drobnym, ale niezwykle istotnym zapisie: po otrzymaniu kolejnej (tj. innej niż pierwsza) wersji dokumentu, zamawiający może zgłosić uwagi jedynie do treści, które uległy zmianie od wersji poprzedniej, lub które z taką zmianą są powiązane. Zapis taki uniemożliwia klientowi zgłoszenie uwag do wersji 1.5 dokumentu, dotyczących zapisów, które nie zmieniły się od wersji 1.1. Dzięki temu liczba uwag zmniejsza się z każdą kolejną wersją dokumentu.

Idealnie byłoby wprowadzić taki zapis w samej umowie na wykonanie prac. Procedura odbioru dokumentacji projektowej może być załącznikiem do umowy. Jednak nawet jeśli umowa nie precyzuje procedury odbioru, lub procedura załączona do umowy  nie zawiera wspomnianego zapisu, warto zadbać o jego wprowadzenie już w trakcie trwania projektu. Można taką zasadę zapisać w planie projektu, o ile jego dostarczenie jest przewidziane w umowie. Można ją także zaproponować na początku prac projektowych, np. podczas pierwszego spotkania projektowego, koniecznie sporządzając notatkę ze spotkania. Klient nie powinien sprzeciwiać sie przyjęciu takiej zasady, ponieważ jest ona zdroworozsądkowa i tak na prawdę korzystna także dla niego. Zmusza go bowiem do uważnej analizy przekazanej dokumentacji i przyczynia się do szybszego jej odbioru, na czym przecież zależy obu stronom. W prowadzonych przeze mnie projektach nie zdarzyło mi sie jeszcze, żeby po zaproponowaniu powyższej zasady i przedstawieniu korzyści z niej wynikających, klient odmówił jej przyjęcia.

... i jej praktyczne stosowanie

Co jednak zrobić, gdy wspomniana zasada została przyjęta, a mimo to zamawiający zgłasza uwagi do zapisów, które nie zmieniły się od poprzedniej wersji? Jeśli zamawiający wykrywa w ten sposób istotne błędy popełnione przez wykonawcę, które nie zostały wcześniej wychwycone, to warto mimo wszystko takie uwagi przyjąć, zaś błędy poprawić. Będzie to korzystne - zarówno dla jakości dokumentacji, jak i dla relacji z klientem. Gorzej, jeśli zgłaszane w ten sposób uwagi nie dotyczą ewidentnych błędów wykonawcy, lecz np. nieścisłości merytorycznych, których wykonawca nie jest świadomy, nie posiadając dogłębnej wiedzy biznesowej. W pojedynczych, uzasadnionych przypadkach można takie uwagi przyjąć (chociaż może to zmotywować klienta do dalszego zgłąszania uwag w tym trybie, zgodnie z powiedzeniem "daj palec, a weźmie całą rękę"). Co jednak zrobić, gdy nagle dostajemy takich uwag kilkanaście lub kilkadziesiąt?

Ciekawą strategię radzenia sobie w takiej sytuacji zastosowałem w projekcie doradczym dla dużej centralnej instytucji publicznej. Projekt polegał na stworzeniu modelu  procesów biznesowych organizacji oraz opracowaniu opisu przedmiotu zamówienia, będącego załącznikiem do specyfikacji istotnych warunków zamówienia (SIWZ) na system informatyczny, jaki wspomniana instytucja zamierzała zamówić. Ze strony zamawiającego w projekcie uczestniczyło kilkunastoosobowy zespół specjalistów biznesowych. Liczba zgłaszanych przez nie uwag była spora. Poszczególne dokumenty przeszły już kilka iteracji, a ich numery wersji dochodziły do 1.5. Wielkimi krokami zbliżał się termin odbioru prac. Po otrzymaniu kolejnej już wersji dokumentacji, zamawiający niespodziewanie nadesłał uwagi do zapisów, które nie uległy zmianie bodaj od wersji 1.1.

Postąpiłem wówczas następująco: odrzuciłem wszystkie takie uwagi, uzasadniając, że zostały one zgłoszone po terminie. Następnie poprosiłem koordynatora projektu ze strony zamawiającego o spotkanie z zespołem. Na spotkaniu zaproponowałem, że uwzględnimy wszystkie zgłoszone po terminie uwagi, ale musimy to zrobić wspólnie w trakcie tego spotkania. Powiedziałem, że wyjdziemy ze spotkania dopiero z zatwierdzoną dokumentacją. Zespół klienta, mając świadomość, że nie dotrzymał terminu zgłoszenia uwag, przystał na takie rozwiązanie. Podczas całodniowego spotkania wszystkie otwarte uwagi (także te zgłoszone zgodnie z procedurą i w terminie) zostały przedyskutowane, a odpowiednie zmiany naniosłem do dokumentacji od razu na spotkaniu, na oczach zespołu klienta. Dzięki temu nie była już potrzebna kolejna czasochłonna iteracja: przekazanie nowej wersji dokumentów, zgłoszenie uwag, uwzględnienie uwag przez wykonawcę. Termin dostarczenia dokumentacji został dotrzymany. Taki interaktywny tryb pracy okazał się w końcowej fazie znacznie bardziej efektywny od sformalizowanej wymiany pisemnych uwag i odpowiedzi na nie.

Podobne artykuły:

Szymon Zioło RedPill - szkolenia IT konsulting