Z obawy przed porażką, czyli jak wyłożyć projekt IT.

Obawa przed porażką

Dzisiaj będzie raczej krótko, ponieważ temat tego artykułu jest wynikiem, krótkiej rozmowy z drugą osobą o pewnym projekcie i pojawił się w mojej głowie całkiem przez przypadek jako odpowiedź na pytanie „Jak Ci idzie z projektem wdrożenia magazynu?”

Swoje przemyślenia miałem już wcześniej, ponieważ starałem się znaleźć rozwiązanie mojego problemu, tj. znaczącego przesunięcia terminu wdrożenia projektu. A dzisiaj poprzednie wnioski udało się ująć w bardzo krótkim stwierdzeniu „obawa przed porażką”. Tutaj można dodać jeszcze jeden wniosek będący konsekwencją obawy przed porażką, czyli doszukiwanie się wytłumaczeń swoich działań w „sprzyjającym” środowisku utrzymywania innych systemów poza pracą nad projektem.

A więc jakie były argumenty, które udało się „znaleźć” w trakcie prób podjęcia i wykonania projektu będące wytłumaczeniem samego siebie?

  • brak zasobów ludzkich z innych działów, zaangażowanych w inne działania,
  • okres wzmożonej sprzedaży, a w konsekwencji w danym okresie inne priorytety biznesu,
  • zaangażowanie PM w prace utrzymaniowe wcześniej dostarczonych systemów,
  • angażowanie się PM w rozwiązywanie problemów personalnych wybranych osób,
  • zmiany kadrowe na jednym ze stanowisk niezbędnych w projekcie i brak osoby możliwej do obarczenia odpowiedzialnością za część projektu,
  • zgłoszenie się PM do nowego, równoległego projektu,

a tak na koniec:

  • zmiana wymagań biznesowych i rozbudowa założeń niezbędnych do wdrożenia w ramach tego projektu.

Z perspektywy czasu myślę sobie, że mógłbym znaleźć znacznie więcej takich argumentów. Ale czy one przybliżają mnie do finalizacji projektu? Jeżeli przejdziemy do punktów wymienionych powyżej, możemy zdać sobie sprawę, że każdy z punktów jest niejako też dobrym wytłumaczeniem przed bezpośrednimi przełożonymi, jak również przed zarządem danej firmy, ponieważ tak naprawdę realia tak wyglądały. (Tutaj mała * pamiętajmy, zdarzają się sytuacje podbramkowe, których nie jesteśmy w stanie uniknąć, ponieważ życie codziennie przynosi różne scenariusze, ale chce tylko dość mocno uwidocznić obawę przed porażką jako początek lawiny kolejnych, potencjalnych niepowodzeń).

No ale jak to? Jak to w końcu było? Z jednej strony mówisz „brak zasobów ludzkich z innych działów” lub „zaangażowanie PM w prace utrzymaniowe wcześniej dostarczonych systemów”, z drugiej strony jednak „tak naprawdę realia tak wyglądały”.

Sprawa ma się następująco. Rzeczywiście, sytuacja wyglądała tak, że innej pracy było bardzo dużo i ogólnie warunki nie były sprzyjające, czyli mocno sprzedażowy grudzień, zmiany kadrowe, inne narzędzia do utrzymania. Tutaj się wszystko zgadza. Myślę, że każdy w firmie by się ze mną zgodził. Przecież finalnie nie było tak, że siedziałem i nic nie robiłem, a nawet czasami dochodziło do tego, że nie wiedziałem w co ręce włożyć.

Jednak jest też druga strona tego medalu. A co by było gdyby wykorzystać trzy proste narzędzia?

  • podział pracy na możliwie najdrobniejsze elementy w celu minimalizacji zagrożeń,
  • priorytetyzacja zadań/projektów,
  • wykorzystywanie słowa „nie”, oczywiście w odpowiedniej formie.

Patrząc na powyższe możemy dołożyć jeszcze jedno, a mianowicie spotkanie z drugą osobą nie mającą obciążenia mentalnego jakie my nabyliśmy w trakcie planowania prac.

A teraz spróbujmy wykorzystać te narzędzia.

  1. Dzięki wykorzystaniu słowa „nie” moglibyśmy rozwiązać problem między innymi angażacji w rozwiązywanie problemów personalnych innych osób, jak również uczestnictwa w dodatkowym, nowym projekcie. Przecież zawsze moglibyśmy powiedzieć „bardzo chciałbym pomóc, ale obawiam się że przy obecnym zaangażowaniu w projekt X nie znajdę odpowiedniej ilości czasu, abym mógł efektywnie pomóc w nowym projekcie lub Twoim problemie”. Czy nie wydaje się Wam, że pokazując ewentualne konsekwencje moglibyście ustalić na czym się skupić w danym momencie?
  2. Podział pracy na możliwie najdrobniejsze elementy jest jednym z narzędzi, które możemy nazwać WBS, ale też możemy taką pracę wykonać z innymi osobami z zespołu co pozwoliło by dostrzec ewentualne zagrożenia oraz wyjaśnić na tyle dużo wątpliwości, że bez obaw moglibyśmy rozpocząć wdrożenie projektu.
  3. Priorytetyzacja zadań – tutaj chyba nie trzeba wiele wyjaśniać? Po prostu każdy jest świadomy gdzie się obecnie znajdujemy, co musimy wykonać, a następnie do czego przejdziemy jako kolejny krok.

Jeżeli do powyższego dołożymy prawidłowe zarządzanie ryzykiem, zaczynamy dostrzegać dużo więcej szans na sukces niż było pierwotnie, mimo że projekt nadal może mieć wady, możemy znacząco się zbliżyć do wyeliminowania ich.

A Wy jakie macie zdanie? Można zrobić coś więcej w takich sytuacjach? Jak wyglądają Wasze doświadczenia jeżeli chodzi o nieudane projekty? Czy Wy również napotykaliście na dość proste z perspektywy czasu problemy, które można było rozwiązać wcześniej, zanim jeszcze doszło do ostatecznego?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *