7 czynników gwarantujących niepowodzenie

Nie doceniaj pracowników, nie doceniaj złożoności lub polegaj na mitach. Jeśli te i inne czynniki zostaną wzięte pod uwagę, Twój projekt z pewnością się nie powiedzie.

Wiesz to? Przez tygodnie i miesiące kierownik projektu składa raporty ze swojego projektu. Oczywiście nie powinno zabraknąć klasycznych lampek statusu. I to cały czas na zielonym: wszystko ok. Ale pewnego dnia sygnalizacja świetlna nagle zmienia się na czerwoną! W rezultacie dla osób odpowiedzialnych rozpoczyna się bardzo nieprzyjemny proces przetwarzania. W większości przypadków pierwsze pytanie dotyczy winowajcy, drugie przyczyn, a następnie jedno dotyczy tylko możliwych rozwiązań.

Poniżej znajduje się 7 typowych czynników, które prawie gwarantują porażkę.

Czynnik 1: zignoruj ​​czynnik ludzki

Przez wiele lat jako programista, kierownik projektów, coach i manager kryzysowy przekonałem się, że największą przeszkodą w realizacji projektów IT są napięcia międzyludzkie. I odwrotnie, chemia między pracownikami jest prawidłowa, panuje otwarty, tolerancyjny klimat, można znaleźć rozwiązania dla wszystkich trudności – nawet w sytuacjach krytycznych.

W naturze człowieka leży unikanie konfliktów. Jest więc rzeczą naturalną, że ludzie (np. kierownik projektu) całkowicie ignorują lub zbyt długo odwracają wzrok. Ale konflikty zwykle nie rozwiązują się same. Badania są wymagane, jako moderacja i przynajmniej perspektywa zmiany lub rozwiązania.

Czasami to małe rzeczy mają duży wpływ, takie jak nowa praca dla pracownika. Jednak często konieczne są większe wydatki, takie jak reorganizacja zespołów, aby przywrócić spokój w projekcie. Jednak najgorszą alternatywą jest lekceważenie czynnika ludzkiego.

Czynnik 2: myśl za dużo lub rób za mało

Niektóre firmy przejmują projekt. Nie doceniają złożoności, ryzyka oraz ogromnego nakładu personelu i materiałów. Czy – niezależnie od kosztów – moja organizacja jest w stanie w ogóle zarządzać projektem zatrudniającym 100 pracowników? Czy mamy wystarczającą liczbę miejsc pracy, sal konferencyjnych, przepustowości sieci, serwera deweloperskiego itp.?

Czy firma jest w stanie sprostać wymaganiom dużego zwinnego zespołu programistycznego na ścieżkę rozwoju i testów, w tym Continuous Integration/Delivery? Przewidując takie pytania, uzasadnienie biznesowe powinno było zostać realistycznie obliczone. Kilka razy widziałem, że dopiero na krótko przed rozpoczęciem gigantycznego projektu stało się jasne, że powstały system nie jest właściwie potrzebny, ponieważ nie pasuje do modelu biznesowego firmy. Niestety nikt wcześniej tego nie zauważył.

Inny rozpoznawalny wzorzec: Bohater bezwzględnie chce zrealizować SW, np. ze względów prestiżowych lub wykorzystać pracowników, a koszty kalkuluje jako znikome. Jeśli późniejszy kierownik projektu nie jest wystarczająco silny, aby przedstawić rozbieżność w kontekście organów decyzyjnych, stwarza to duży potencjał kryzysowy.

Czynnik 3: polegaj na szacunkach i planowaniu w 100%

Powszechnym mitem jest wiarygodność szacunków i planowania. Koncept projektu określa jego wyjątkowość. Być może były już podobne projekty, ale w zasadzie z każdym projektem firma wkracza na nowe terytorium. Oznacza to, że szacunki mogą być tylko tak dobre, jak doświadczenia twórców i ich umiejętności adaptacyjne dotyczące bieżącego projektu.

Jednak plany nigdy nie mogą uwzględniać spontanicznych zdarzeń, zmian w zakresie wymagań, technologii czy wejścia nieoczekiwanych ryzyk. Ostatecznie szacunki i oparte na nich plany to nic innego jak zakłady na przyszłość! Zaakceptowanie tego faktu to pierwszy krok do przodu. Dyscyplina, odwaga i system pomagają zapobiegać ewentualnym kryzysom lub łagodzić je.

Czynnik 4: Konsekwentnie lekceważony magiczny trójkąt PM

Studiował informatykę, pierwszy semestr, pierwszy wykład zarządzanie projektami: „Magiczny trójkąt PM” . Osoba zainteresowana zadaniami kierowniczymi jest bardzo wcześnie zapoznawana z prawami tego trójkąta. Mówią one, że zmiana jednego z trzech parametrów nieuchronnie prowadzi do konsekwencji co najmniej jednego z pozostałych parametrów.

Jednak prawa te są zbyt chętnie ignorowane w praktyce. Jak już wspomniano w kontekście szacowania i planowania, projekt jest w pewnym sensie wyjątkowy, a prawdopodobieństwo nieplanowanych wpływów jest wyjątkowo wysokie. Dlatego prędzej czy później w prawie każdym projekcie konieczne jest, aby osoby odpowiedzialne zareagowały na te wpływy. Jeśli jednak wszystkie parametry są ustalone, tj. klient nadal wymaga przestrzegania czasu, budżetu i treści, awaria jest tylko kwestią czasu.

Czynnik 5: Dokumentacja wszystkiego

Free za Franzem Beckenbauerem: „Nazywamy to klasykiem!” Choć coraz więcej firm opiera się na zwinnych procedurach (głównie scrum), to wciąż odnajduje się organizacje i projekty, dla których obszerna dokumentacja ma większe znaczenie niż tworzone oprogramowanie. Jest to duże ryzyko, szczególnie w przypadku dużych projektów. Często polowanie konsultantów i ekspertów działów na tysiące stron często pracowało miesiącami, a nawet latami, co później zostanie przetłumaczone przez inny zespół w SW.

Im obszerniejsza dokumentacja, tym dłuższy czas realizacji i mniejsze prawdopodobieństwo, że SW odpowiada rzeczywistym wymaganiom użytkowników. Reakcje na zmiany na rynku nie są możliwe lub możliwe tylko przy dużym wysiłku i ustępstwach czasowych. Dokument stanowi podstawę, na podstawie której produkt może zostać usunięty. Niestety, to, co jest napisane, niekoniecznie jest jasne, a wynik jest inny niż pierwotnie sądzono. Ile razy słyszałem zdanie pracowników działu i użytkowników końcowych: „Och, zupełnie inaczej to sobie wyobrażałem!” .

Czynnik 6: Po prostu brak zrównoważonej organizacji projektu

Zespół 20 programistów i 1 osoba kontaktowa ds. technicznych? Nie potrzeba wiedzy eksperckiej, aby stwierdzić, że ta konstrukcja prędzej czy później zawiedzie. Na początku projektu, czy to kaskadowego, czy zwinnego, może on nadal działać, ponieważ programiści są zajęci tworzeniem frameworków lub konfigurowaniem środowisk. Ale już wkrótce pracownicy zaczną zadawać pytania – potrzebują intensywnego profesjonalnego wsparcia.

Pojedynczy ekspert merytoryczny nigdy nie wytrzyma tej presji czasowej i emocjonalnej i wymaga wsparcia, zarówno w zakresie personelu, jak i procesu wdrażania. Jednak bardzo złym pomysłem jest przeciwdziałanie zatorowi kadrowemu poprzez ograniczenie komunikacji.

Również popularny pomysł i pierwszy krok w skali typowych błędów zarządzania: pracownik zbiera pytania programistów, omawia je z techniczną osobą kontaktową i zwraca odpowiedzi. W ten sposób tworzysz par excellence wąskie gardło, uruchamiasz niezwykle wysoki poziom błędów i znacznie opóźniasz rozwój.

Czynnik 7: Podgrzej żabę powoli

Czy znasz tę historię? Jeśli włożysz żabę do rondla z wodą i ciągle ją podgrzewasz do gotowania, żaba nie będzie próbowała uciec. Jeśli wrzucisz go bezpośrednio do gorącej wody, natychmiast wyskoczy.

Jedną z moich najważniejszych informacji o mnie w ostatnich latach jest to, że pracownicy projektów IT wygasają wraz z wydłużającym się czasem trwania postępującej ślepoty. Raz ustalone procesy są być może kwestionowane w retrospekcjach, ale rzadko są tak naprawdę drastyczne. Zdolność ludzi do reagowania na zmiany zanika proporcjonalnie do czasu trwania projektu.

Dlatego sporadyczne oświetlenie (Health Checks) jest zalecane przy (dużych) projektach przez zewnętrznego, wcześniej niezaangażowanego konsultanta w celu wykrycia wycieków, potencjalnie nieukierunkowanych ścieżek. Najpóźniej po rozpoznaniu pełnego kryzysu jest prawie niemożliwe dokonanie zmiany przy pomocy samego istniejącego personelu.

Więc to może być możliwe

Opisane typowe błędy zarządzania to tylko mały wybór z mojej osobistej listy wzorców zachowań, które uniemożliwiają lub nawet uniemożliwiają pomyślne ukończenie projektów rozwojowych SW. Z daleka można odnieść wrażenie, że łatwo jest rozpoznać problemy i skorygować je na wczesnych etapach projektów. Ale rzekomo niewzruszone warunki ramowe i wspomniana ślepota często utrudniają podejmowanie właściwych decyzji. Podane na wstępie statystyki Standish Group pokazują to rok po roku.

Jeśli projekt ma kłopoty, zdecydowanie zaleca się, aby zewnętrzny menedżer kryzysowy mógł analizować i działać obiektywnie, bez wrażliwości i bez balastu historii projektu. Sam udział w projekcie eksperta, który słucha ludzi, może już przynieść pozytywne efekty. Dobór odpowiednich środków również skutkuje transformacją i wreszcie odwróceniem.