Jak unikać porażek czyli – Analiza Porażki Projektu z bloga: wojciszko.com

Jakbym miał wskazać, co jest największym czynnikiem sukcesu, to chyba byłaby to: porażka.

Porażki i błędy to w mojej ocenie są największe motywatory do działania, do rozwoju, do reorganizacji. Jest tylko jedna sprawa, czy porażek unikamy:

• poprzez analizę ich przyczyn i wyciąganie wniosków,
• poprzez udawanie, że nie miały miejsca.

Przypadkiem trafiłem na artykuł i zaciekawiło mnie jaki się wyciąga wnioski z porażek:

https://wedlugplanu.pl/case-study-analiza-porazki-projektu/

Case Study – Analiza Porażki Projektu

Na blogu wojciszko.com we wspomnianym artykule jest opisana case z porażką, sytuacja jakich wiele ale na swój sposób ciekawa. Autor przedstawia przyczynę porażki i wyciąga wnioski. I tu zaczyna być ciekawie, bo nie wyciąga wniosków, wskazał jedną z przyczyn, choć w sumie nie wskazał żadnej z przyczyn, opisał parę skutków. Ale to też dużo, bo jakiś problem chociaż został zauważony.

Przyczyna wg autora

W opisanej sytuacji, której nie ma co przytaczać, główną przyczyną porażki w projekcie, było:

• Brak priorytetów i kierunku
• Marnowanie czasu
• Presja i utrata motywacji

Piszę o tym, bo jest to częsty sposób myślenia, upraszczając odbieram to tak:

• Nie wiedzieliśmy co mamy robić,
• Robiliśmy co mogliśmy ale jakoś nie szło.

Przyczyna porażki wg mnie

W mojej ocenie jest to przykład sytuacji gdy:

• Nie ma lidera
• Niewłaściwa organizacja projektu

Lider

W artykule pojawiają się zwroty, że Biznes coś chciał, Biznes potem zmienił zdanie, Biznes coś tam… Czyli jednym słowem mieliśmy #chaos. Chaos pojawia się właśnie wówczas gdy nie ma lidera. Lidera w rozumieniu kogoś kto jest najbardziej zainteresowany aby to poszło, albo najbardziej dostanie po dupie jak to nie pójdzie. Lider może zarządzać osobiście lub komuś to zlecić. Liderem może być właściciel biznesowy, dyrektor programu, dyrektor działu, departamentu, specjalista. Ktoś kto wie czego chce.

Bez Lidera PM robi co chce, Biznes zmienia zdania kiedy chce, Developerzy robią co im się wydaje, Analitycy robią diagramy, których nie rozumie ani Biznes ani Developerzy. Jednym słowem statek bez kapitana, orkiestra bez dyrygenta.

Organizacja

W opisanym przypadku organizacja pracy sprzyjała powstawania charakterystycznych punktów które znacząco zwiększają ryzyko porażki a są to:

• Biznes w projekcie – potencjalny użytkownik dyrygujący projektem. Zmienia zdanie, nie ma czasu za nic nie odpowiada ale na końcu wyrazi swoje słuszne niezadowolenie.
• Presja – pewien poziom presji jest zawsze i musi być ale jak zaczyna niebezpiecznie rosnąć, to zaczynają się chaotyczne i bezradne działania. Bezradność i presja to duet, który zawsze robi swoje.
• Programowanie bez analizy – to ta jakby Janusz ze szwagrem postanowili zrobić sobie porsche. Mają gdzieś w stodole jakieś koła, śruby, we wsi jest gość co potrafi spawać, co mamy nie dać rady.

Podsumowanie

To w mega skrócie, czego tu nie ma a być powinno:

• Plan działania
• Analiza
• Budowa rozwiązania (nie mylić z tzw. „kodowaniem” – bo development to już tylko wykonanie)