Przyczyny problemów w projektach – Niewłaściwe zdefiniowanie wymogów

Problemy w projektach

 

Zrobiliśmy nasz pierwszy kurs online! Zapraszamy do kursu: Wykres Gantta w Excelu - https://www.subscribepage.com/gantwexcelu

Temat problemów w projektach nie jest prosty. W tym poście spróbuję przedstawić kilka przyczyn, dlaczego w niektórych projektach dochodzi do niewłaściwego zdefiniowania wymogów. Każdy projekt oczywiscie ma inną specyfikę, klientów, Kierownika Projektu, członków zespołu i otoczenie w którym jest prowadzony, niemniej część przyczyn może być dość powszechnie występujących.

Dlaczego definiowanie wymogów jest w ogóle ważne?

Tak wielkie znaczenie prawidłowego zdefiniowania wymogów dla końcowego sukcesu projektu i uniknięcia wielu problemów po drodze, wynika z dwóch przyczyn:

  1. Są one odbiciem potrzeb Klienta, podstawą do stworzenia planu projektu — mapy, jak najprościej spełnić te wymagania, harmonogramu i kosztorysu.
  2. Za pomocą wymogów definiujemy zobowiązania zespołu projektowego co do końcowego efektu projektu. W wypadku projektów realizowanych na zasadach kontraktu zapisuje się je w formalnym dokumencie stanowiącym podstawę do rozliczenia wykonawcy realizującego kontrakt i wypłaty wynagrodzenia za dostarczoną pracę.

Poprawne sformułowanie wymogów jest nie lada wyzwaniem. Już na samym wstępie czekają pułapki w postaci:

  • Niewystarczająco precyzyjne zdefiniowanie wymogów.
  • Zbyt precyzyjne zdefiniowanie wymogów.
  • Niewłaściwe zdefiniowanie wymogów.
  • Nierealistyczne zdefiniowanie wymogów.

Punkt widzenia zależy od punktu siedzenia — projekty wewnętrzne i zewnętrzne

Sposób formułowania wymagań będzie zależał od tego czy realizowany jest projekt wewnętrzny, czy zewnętrzny. Gdy projekt realizowany jest dla własnej organizacji, może to pozytywnie wpływać na komunikację. Używając dobrze znanych kanałów komunikacji i łatwiej będzie dotrzeć do osób odpowiedzialnych za poszczególne piony w strukturze. Określenie wymagań może przyjść w sposób wręcz intuicyjny, bo część problemów może być przez wszystkich dobrze rozumiana.

Jednocześnie pojawia się tutaj duże ryzyko, że tworząc wymagania projektowe, będzie się ograniczonym właśnie tym dobrze znanym punktem widzenia. Wymagania będą definiowane pod rozwiązanie problemów, które wcale nie byłyby problemami przy wyborze innego podejścia lub będą rozwiązywały problemy tylko jednej grupy zainteresowanych osób. Dobra znajomość organizacji i narzędzi, z których się korzysta w tym wypadku, będzie działać ograniczająco. Trudniej będzie spojrzeć szerzej na projekt, dostrzec inne możliwości. Może to w znacznym stopniu utrudnić identyfikację potrzeb. Można tu też popaść w złudzenie tego, że wiemy wszystko o organizacji, co będzie prowadzić do niewłaściwego zdefiniowania wymogów już na samym początku.

Z drugiej strony prowadząc projekt dla organizacji zewnętrznej lub zlecając taki projekt firmie z zewnątrz, od razu mogą uderzyć różnice w postrzeganiu tych samych pojęć przez osoby z różnych organizacji. To odmienne spojrzenie na projekt może przynieść wiele świetnych pomysłów i wymagań do projektu. O ile w przypadku projektów wewnętrznych pewne “oczywiste” przemilczenia mogą nie powodować poważniejszych problemów, o tyle w przypadku projektów zewnętrznych są bardzo groźne. Największą trudnością jest tu takie zdefiniowanie potrzeb, które będzie rozumiane w ten sam sposób przez obie strony.

Sposób definiowania wymagań wobec projektu uzależniony będzie w dużej mierze także od umiejętności zamawiającego. Im więcej doświadczenia w zarządzaniu projektami posiada zlecający, tym bardziej klarowne, precyzyjne i realistyczne są najczęściej oczekiwania wobec projektu.

W projektach zewnętrznych w większym stopniu niż w wewnętrznych, w definiowaniu wymagań, znaczenie będzie miała wzajemna komunikacja między obiema stronami. Im będzie ona bardziej precyzyjna, tym lepiej. Tu nie ma głupich pytań. Nie znając od wewnątrz organizacji, nie ma innego wyjścia, jak ciągłe pytanie, czy na pewno dobrze rozumiemy tak samo wymagania. Tutaj każde założenie może okazać się błędne. A takie rozmowy to oczywiście koszt. Koszt, który Klient będzie chciał zminimalizować za wszelką cenę.

Opracowanie własne

Naciski Klienta

Koszty administracyjne projektu to zdecydowanie ta część projektu, na której Klient będzie chciał oszczędzić. A do nich zalicza się również definiowanie zakresu. Będzie chciał jak najszybciej przekazać swoje wymagania i czekać na pierwsze efekty projektu. I tu czeka jedna z większych pułapek zarządzania projektem. Dogłębne zrozumienie Uzasadnienia Biznesowego, precyzyjny Cel projektu i dobrze zdefiniowane wymogi projektu to 3 filary zdrowego projektu.

A to wymaga czasu i wielu rozmów z Klientem. Dopytywania w przypadku pojawienia się niejasności. Czasem nawet może odwagi, żeby dopytać się o niektóre szczegóły, które na pierwszy rzut oka mogą wydawać się zbyt banalne, by w ogóle zawracać nimi komuś głowę. A właśnie zdarza się, że niedomówienia w banalnych sprawach będą powodować najwięcej problemów, których rozwiązanie zajmie najwięcej czasu i pieniędzy. Im później wykryty problem i im wcześniejszego etapu projektu dotyczy, tym koszt jego naprawy będzie największy. I dlatego koszty związane ze złym zdefiniowaniem projektu są tak kosztowne.

KOszt napra

Koszt naprawy błędów w projektach informatycznych.

Pietras P., Szmit M.: Zarządzanie Projektami. Wybrane metody i techniki, Oficyna Księgarsko-Wydawnicza „Horyzont”, Łódź 2003, s.71.

Zrób tak, żeby było dobrze

Zdarza mi się czytać fora graficzne, gdzie chyba nagminnym problemem jest brak zdefiniowanych przez Klienta wymagań odnośnie dostarczonego efektu końcowego. “Nie wiem, co chcę, ale jak to zobaczę, to chcę powiedzieć wow”. I o ile w przypadku projektów bardziej namacalnych nie występuje on aż tak często, o tyle w przypadku tych bardziej twórczych bywa ciężko. I to jest zdecydowanie jeden z cięższych przypadków do przezwyciężenia, bo dopóki nie dostanie się pierwszej informacji zwrotnej, nie wiadomo czy podąża się w dobrym kierunku.

Praca z takim Klientem jest niezmiernie trudna, szczególnie jeśli nie ma on doświadczenia projektowego i nie rozumie, czego oczekuje się od niego jako Sponsora Projektu. Tu pozostaje jedynie ścisły kontakt i wyciąganie jak najwięcej szczegółów.

Miałeś podobnego Klienta? Podziel się w komentarzu, jakich problemów doświadczyłeś i jaką taktykę podjąłeś.

Niepełne Uzasadnienie Biznesowe

Jest też drugi aspekt tej historii. Brak wymagań po stronie Klienta może być związany z brakiem lub niepełnym Uzasadnieniem Biznesowym do rozpoczęcia projektu. Osoba oddelegowana do współpracy z projektem może nie znać pełnej przyczyny, dla której projekt jest realizowany lub znać uproszczoną wersję. Może nie mieć pełnego obrazu sytuacji, więc już na wstępie projekt pozbawiony jest kluczowych informacji. Pełne Uzasadnienie Biznesowe może być znane jedynie przez kierownictwo strategiczne organizacji.

Wyobraźmy sobie sytuację, że firma chce wprowadzić narzędzie usprawniające przygotowywanie analiz (raportów), które następnie są sprzedawane jej Klientom. Jawnym Uzasadnieniem Biznesowym będzie usprawnienie przygotowywania raportu XYZ, który zajmuje X godzin i jest niewydajny kosztowo i zmniejszenie nakładów czasowych o 70%. Niejawnym uzasadnieniem będzie z kolei konieczność redukcji zatrudnienia w tym zespole o 50%. Na pierwszy rzut oka chodzi o zredukowanie czasu, jaki jest niezbędny do przygotowania tego raportu. Jednak świadomość, że do jego wykonania będzie potrzeba o połowę mniej osób, może odbić się na niektórych dodatkowych funkcjonalnościach, które rozwiązanie będzie musiało dostarczyć.

Jeśli twoja organizacja lub firma, dla której dostarczasz efekty projektu, nie ma Uzasadnienia Biznesowego dla rozpoczęcia tego projektu, to już na wstępie jest on skazany na porażkę. Jak nie wiadomo, po co trzeba coś dostarczyć, to najprawdopodobniej chodzi o wykorzystanie zabudżetowanych do końca roku środków, bo inaczej przepadną. Takie projekty szerzą się gdzieś w okolicach IV kw. Z jednej strony wydaje się, że jest to projekt idealny — wystarczy cokolwiek rozpisać i dostarczyć, wykazać koszty i wszystko gra. Jednak ten typ projektu to morderca dla zaangażowania zespołu, który czuje, że to, co robi, nie ma sensu.

Spychologia

Zjawisko, które zaraz opiszę, zdarza się aż nazbyt często. I to zarówno w projektach wewnętrznych jak i zewnętrznych. I o ile kilka akapitów wyżej ponarzekałam trochę na Klientów, którzy nie zawsze wiedzą czego chcą, to tutaj docieramy do prawdziwej perełki problemów w projektach.

Wyobraźmy sobie bardzo zapracowanego Sponsora Projektu, który na spotkaniu pojawia się tylko raz, by powiedzieć, żeby w każdej sprawie kontaktować się tylko z osobą, którą oddelegował do tego projektu. I pół biedy, jeśli ta osoba jest jego asystentem, z którym widzi się codziennie w biurze. Gorzej natomiast, jeśli jest menedżerem lub specjalistą, który pracuje w zupełnie innym pionie lub nawet innym biurze i komunikacja między nimi praktycznie nie istnieje.

Od razu nasuwają się tu następujące problemy:

  1. Osoba oddelegowana do współpracy z zespołem projektowym nie jest decyzyjna, więc w przypadku konieczności podjęcia decyzji, będzie musiała kontaktować się ze Sponsorem Projektu. Sponsorem, który jak wspomniałam wyżej, jest bardzo zajęty. Więc albo będzie zrzucał problem z powrotem na tę osobę, albo będzie sam podejmował decyzje bez głębszego zastanowienia się nad problemem. Takie podejście wydłuża też znacznie ścieżkę komunikacji i powoduje, że pojawiają się dodatkowe węzły, gdzie informacja może zostać zniekształcona.
  2. Osoba oddelegowana do współpracy z zespołem może nie mieć pełnej wiedzy o Uzasadnieniu Biznesowym i wymaganiach, jakie są stawiane temu projektowi. Ścisła współpraca z Klientem jest podstawą wszystkich metod, nieważne czy pracujemy w Agile PM, PMI czy PRINCE2, a zrzucanie odpowiedzialności może podważać podstawy zdrowego zarządzania projektami.
  3. Spychając odpowiedzialność w dół drabiny w organizacji, najprawdopodobniej przekazujemy tę odpowiedzialność do osoby, która może mieć znacznie mniejsze doświadczenie w pracy projektowej. I o ile przy odpowiednim wsparciu, może to być okazja do wspaniałego rozwoju pracownika, to w modelu spychologii jest to raczej przepis na uraz do realizacji przyszłych projektów.

Brak priorytetów

Czasami może też zdarzyć się tak, że wymagań do projektu jest tak dużo, że już na wstępie widać, że nie będzie dało się ich dostarczyć w zakładanym czasie i budżecie. Mogą one być też tak różne, że nie wiadomo, które z nich są naprawdę ważne. Tutaj przypomnę, że “Klient nie potrzebuje wszystkiego”, gorzej jeśli to wszystko koniecznie chce mieć.

Zazwyczaj uświadomienie, ile dostarczenie wszystkich wymagań będzie kosztować, działa otrzeźwiająco i po głębszym zastanowieniu okazuje się, że połowa z nich wpada w kategorię “Nice to have”. Przy priorytetyzacji wymagań całkiem skutecznie spisuje się metoda MoSCoW. Ciekawą wydaje się też 100 Point Method, która może się sprawdzić w przypadku, gdy projekt ma dostarczyć rozwiązanie, które będzie stosowane przez różne grupy użytkowników i każda z nich będzie forsować ważność swoich wymagań.

Szukanie rozwiązań zbyt wcześnie

O ile wcześniej można było część winy za problemy w projekcie zrzucić na inne osoby, o tyle ten punkt dotyczy w dużej mierze zespołu projektowego, który zamiast wysłuchać i dobrze zrozumieć wymagania, od razu przechodzi do burzy mózgów i generowania pomysłów na ich rozwiązanie.

Zespół może popełnić tu kilka błędów:

  1. Brak dogłębnej analizy Uzasadnienia Biznesowego i problemów, które projekt ma rozwiązać. W efekcie zespół szuka rozwiązania dla problemu, który może wcale nie być prawdziwym prawdziwą przyczyną obecnego stanu.
  2. Szukanie rozwiązania dla wymagań, które nie odpowiadają Uzasadnieniu Biznesowemu. Zespół szuka rozwiązań dla niewłaściwych wymagań.
  3. Ograniczenie swojej perspektywy. Brak czasu na analizę i przejście od razu do generowania rozwiązań może spowodować, że generowane rozwiązania będą ograniczone tylko do wąskiego punktu widzenia, który jest znany w danym momencie.
  4. Zespół nie wykorzystuje czasu zbierania wymagań na wyjaśnienie niejasności. W kolejnych etapach może powodować to, że projekt jest niedoszacowany. Wymagań jest w rzeczywistości więcej, niż było to informowane na początku, dochodzą dodatkowe ograniczenia, a koszty rosną.

Podsumowanie

Niewłaściwe zdefiniowanie wymogów w projekcie chciałabym podsumować dwoma słowami:

  • Perspektywa — Wszyscy jesteśmy ograniczeni strukturą organizacji, w której pracujemy, swoim doświadczeniem, przyzwyczajeniami, żargonem. To wszystko ma wpływ na to jak pojmujemy niektóre wymagania i to, w jaki sposób tworzymy rozwiązania.
  • Komunikacja — Problem zazwyczaj leży po obu stronach — inicjatorze projektu, który nie dostarczył wszystkich informacji (może nie wszystkie posiadał w danym momencie) oraz zespole projektowym, który opacznie je zrozumiał. Dlatego tak ważne jest dopytywanie się i upewnianie, że wszystkie strony rozumieją ustalenia w ten sam sposób, szczególnie w początkowych etapach projektu.

Newsletter

Czytelniku, zapisz się na nasz Newsletter! Jeśli jesteś zainteresowany naszymi treściami, koniecznie się zapisz. Co miesiąc wysyłamy skrót wszystkich postów wraz z praktycznymi radami, których nigdzie indziej nie publikujemy! Nie możesz tego przegapić 😉

Zobacz podobne wpisy:

.

 

Zrobiliśmy nasz pierwszy kurs online! Zapraszamy do kursu: Wykres Gantta w Excelu - https://www.subscribepage.com/gantwexcelu

Źródła:

  • Klinowski M., Definiowanie wymagań projektu w procesie planowania, s. 279-280, https://www.wir.ue.wroc.pl/docstore/download/WUT1ad118c7f42e47c7bcfbb8aec084a2f8/Klinowski_Definiowanie_wymagan_projektu_w_procesie.pdf [dostęp 29.12.2020]

Zdjęcia:

  • Źródło obrazka głównego: https://pixabay.com/pl/illustrations/pytanie-mark-odpowied%C5%BA-roztw%C3%B3r-4105529/
  • Pietras P., Szmit M.: Zarządzanie Projektami. Wybrane metody i techniki, Oficyna Księgarsko-Wydawnicza „Horyzont”, Łódź 2003, s.71.
  • opracowanie własne
  • https://pixabay.com/pl/photos/spychacz-roz%C5%82adowa%C4%87-%C5%BCwir-1978282/

 


Leave a Reply

%d bloggers like this: