Pułapka „elastyczności”. Zarządzanie zmianą w projekcie

Najpierw była firma konsultingowa. Przeanalizowała szczegółowo potrzeby klienta w zakresie systemu informatycznego, którym był zainteresowany. Raport z prac konsultantów, opasły i szczegółowy był długo analizowany przez klienta, wprowadzano kolejne poprawki, wciąż pojawiały się uzupełnienia, zanim przyjął ostateczną wersję.

A potem podpisano kontrakt. Klientem była duża firma, będąca liderem na swoim rynku, niezbyt wymagającym, jeśli idzie o rozwiązania IT, wiedząca jednak czego chce, stanowiąca, jeśli idzie o przyszłych użytkowników systemu mieszankę wysoko wyedukowanych młodych ludzi i doświadczonych pracowników będących specjalistami w swojej specyficznej branży i mających, jak to często bywa, swoje przyzwyczajenia.
Dostawca zaś to niezbyt wielka firma informatyczna z ambicjami, przodująca w pewnych segmentach rynku, której zależało na referencjach z nowego, otwierającego się rynku.

Mieliśmy więc po jednej stronie klienta z dużymi oczekiwaniami, trochę „niesterownego” i firmę wdrożeniową, której bardzo zależy. Nawet tak bardzo, że zadeklarowała bliżej niesprecyzowaną „elastyczność” w podejściu do zapisów kontraktu i do realizacji oczekiwań klienta.

Nie trzeba chyba dodawać, że dokument wspomniany na wstępie był załącznikiem do umowy. Rozpoczął się projekt. Powołano zespoły projektowe. Dostawca narzucił metodologię – Prince 2. Zostało to z szacunkiem przyjęte przez kupującego i zapisane w Dokumencie Jakości Projektu – PQD (Project Quality Document). Prace przygotowawcze minęły zgodnie z planem.

Problemy zaczęły się już przy odbiorze wyników pierwszego etapu. Okazało się, że jakość prac nie jest dostateczna, tak jakby dostawca wykonywał swoją pracę „nie do końca”. Ale po usunięciu usterek, zgłaszanych przez zamawiającego, etap został odebrany. Prawdziwe kłopoty pojawiły się zaś przy odbiorze drugiego etapu. Okazało się, że terminu nie da się dotrzymać. Dostawca sygnalizował, że według niego poszerzył się zakres oczekiwań funkcjonalnych klienta. Chciał uznania dodatkowych prac, które wykonał i dodatkowej kwoty zwiększającej jego wynagrodzenie.

Z punktu widzenia klienta te żądania były kompletnie bezzasadne. Nie stały za nimi przecież żadne ustalenia formalne, nie było mowy o żadnym rozszerzeniu zakresu. Był dokument, o którym wspominałem na wstępie, który bardzo precyzyjnie definiował jego potrzeby. Co się więc okazało: konsultanci dostawcy, chcąc jak najlepiej spełnić oczekiwania klienta, realizowali również prace zgłaszane przez „szeregowych” członków zespołu projektowego, tych odpowiedzialnych za poszczególne, wąskie obszary zagadnienia. Prace, które wykraczały nieco poza zakres uzgodniony na wstępie. Raportowali to następnie swojemu kierownikowi, ale kierownik projektu po stronie zamawiającego nie był tego świadom. Można powiedzieć, że projekt miał „drugie dno”, drugi nurt, którym płynął. Oczywiście klient nie chciał wziąć pod uwagę, ani nawet zauważyć rozszerzenia zakresu. A tym bardziej nie akceptował zwiększenia kosztów z tym związanych.

W efekcie mieliśmy niezadowolonego klienta – nie dostał tego co chciał w oczekiwanym terminie. Dostawca był również niezadowolony, czuł, że zanadto poświęca się dla klienta, ten zaś nie zauważa jego wysiłków. Widząc więc, że nie ma szans na uzyskanie wynagrodzenia za dodatkowe prace, wszystkie swoje umiejętności negocjacyjne skupił na wybronieniu się od kar umownych, które powinien zapłacić za przekroczenie terminu realizacji projektu.

Co zawiodło, gdzie leżała przyczyna tego stanu rzeczy? Założenia funkcjonalne systemu i potrzeby klienta były przecież dokładnie opisane, znane obu stronom i „umocowane” formalnie jako część kontraktu projektowego.
Odpowiedź jest krótka: W projekcie nie został wprowadzony prawidłowo proces zarządzania zmianą.

Truizmem jest stwierdzenie, że projekt jest środowiskiem, w którym „jedyne co stałe, to zmiana”. Wszystkie metodyki zarządzania projektem proponują jakiś sposób radzenia sobie z tą „przypadłością”. Proces zarządzania zmianą opisuje sposób reagowania na zmiany dotyczące jednej z linii bazowych projektu.



Do zmian należy podejść w sposób zorganizowany. Jednym z elementów jest zaproponowanie sposobu dokumentowania zmian. Przygotowuje się formularze zmian, zawierające informacje dotyczące opisu zmiany, oraz jej przyczyny. Notuje się również nazwisko osoby zgłaszającej zmianę.
Organizuje się rejestr zmian, w którym zapisuje się wszystkie informacje dotyczące statusu zgłoszenia zmiany. Mogą to być np. „zmiana zgłoszona”, „zmiana zaakceptowana”, „zmiana odrzucona”.
Istotne przy tym jest określenie sposobu eskalowania żądania zmiany.
Decyzje dotyczące niektórych mogą być podejmowane przez członków zespołu projektowego, inne przez kierownika projektu, jeszcze inne przez ciało nadzorcze – komitet sterujący lub sponsora projektu. Kryterium jest najczęściej wpływ zmiany na zwiększenie kosztów lub czasu realizacji albo istotność zmiany funkcjonalnej.
Często stosuje się przy tym tzw. zarządzanie przez wyjątki.



Podsumowując – w projekcie musi być określony sposób reagowania na zmianę, poprzez rejestrację żądania zmiany, podjęcie decyzji co do jej realizacji i włączenie w harmonogram projektu. Decyzja powinna być podejmowana przez odpowiednio uprawnione gremium. Odpowiedzialnym za zorganizowanie i funkcjonowanie procesu zarządzania zmianą jest kierownik projektu.

Przykład opisany na wstępie artykułu pokazuje również, że powołanie się na metodyką projektową i przygotowanie dobrego dokumentu wstępnego (PQD) to nie wszystko. O wiele trudniejszym zadaniem jest wcielenie dokumentu w życie, skuteczne stosowanie zapisanych w nim zasad.

Dlaczego więc dostawca tak postępował? Gdzie popełnił błąd?
Przypomnijmy – działał w imię opisanej na początku „elastyczności”. Obróciła się w efekcie przeciwko niemu i na pewno wynikło z niej więcej kłopotów niż korzyści. Okazuje się więc, że „twardy” dostawca, umiejący zadbać o swoje interesy działa z korzyścią dla siebie i dla swojego klienta.

Paweł Świdziński
Kurs Na Sukces
www.akoziar.pl

1. drukuj

« poprzedni   |   archiwum   |   następny »