Projekt zakończony niepowodzeniem: kiedy to nazwać?

Kilka miesięcy temu moja firma znalazła się w opałach związanych z gorącym projektem, a cały sześcioosobowy zespół poświęcił w zasadzie pięciotygodniowy „kryzysowy tydzień”. W ciągu 48 godzin przed startem przepracowałem 41 z nich, dwóch z powrotem przez całą noc. Pośrodku tego zamieściłem pytanie, które do tej pory było moim najbardziej udanym .

Przez cały ten czas nigdy nie było mowy o „porażce”. Zawsze było to „załatwić sprawę, niezależnie od bólu”.

Teraz, gdy sprawa się skończyła, a my jako organizacja mieliśmy trochę czasu, aby usiąść i podsumować to, czego się nauczyliśmy, przyszło mi do głowy jedno pytanie. Nie mogę powiedzieć, że kiedykolwiek brałem udział w projekcie, który powiedziałbym, że „nie powiódł się”. Wiele, które spóźniły się lub przekroczyły budżet, niektóre katastrofalnie, ale zawsze kończyło się na dostarczeniu COŚ.

Jednak ciągle słyszę o „nieudanych projektach IT”. Zastanawiam się nad ludzkim doświadczeniem z tym. Jakie parametry zdefiniowały „awarię”? Jaki był kontekst? W naszym przypadku jesteśmy sklepem z oprogramowaniem dla klientów zewnętrznych. Czy projekt wewnętrzny dużej korporacji ma więcej miejsca na „porażkę”? Kiedy dzwonisz? Co się stanie, kiedy to zrobisz?

Wcale nie jestem przekonany, że robienie tego, co zrobiliśmy, jest mądrym posunięciem biznesowym. To nie było moje wezwanie (jestem tylko małpą kodową), ale zastanawiam się, czy lepiej byłoby zmniejszyć nasze straty, powiedzieć, że nie dostarczamy i przejść dalej. Nie mówię tylko, że z powodu długich godzin - firma królewska straciła koszulę przy projekcie, a koszty niematerialne dla firmy w zakresie morale pracowników i lojalności były duże . Fakt, że wbrew PR hitowi, że nie udało się zrealizować tak głośnego projektu, jak ten, był ... i nie wiem, jaka jest prawidłowa odpowiedź.

Pojęcie niepowodzenia jest tak naprawdę połączeniem biznesowym. Jeśli projekt komercyjny kosztuje więcej niż pieniądze, które przynosi, projekt ten zostanie uznany za porażkę. Jeśli projekt open source nie może zbudować społeczności wokół kodu, aby pomóc w jego utrzymaniu i opiece, ten projekt open source nie powiódł się.

Brałem udział w projektach, w których dostarczaliśmy wszystko na czas i w ramach budżetu, ale zespół rozwoju biznesu nie mógł śledzić pracy. Z perspektywy biznesowej projekt się nie powiódł, chociaż to, co dostarczyliśmy, zostało dobrze przyjęte i lubione.

W sytuacjach takich jak Twoja firma musi podjąć trudne decyzje. Jeśli chcą, aby projekt się powiódł, muszą nauczyć się kilku lekcji:

• Niewłaściwe planowanie spowoduje nadmierny stres w zespole i ostatecznie doprowadzi do niepowodzenia projektu
• Zestresowany zespół wykona odwet przy wysokich obrotach - i ostatecznie nie będziesz w stanie pozyskać dobrych ludzi do przyłączenia się do firmy.
• Zdarzają się sytuacje awaryjne, ale dowiedz się, co spowodowało awarię i zmień swoje praktyki, aby uniknąć tej sytuacji w przyszłości.

Każda firma, która nie uczy się na błędach, będzie często powtarzać historię. Uznałbym to za znak, że czas znaleźć inną firmę.

Niepowodzenie to wszystko, co może opisać cel, który nie został osiągnięty.

Krótko mówiąc, kiedy definiujesz swój cel, określasz także, co jest porażką w tym kontekście.

W literaturze, o której wspominasz, porażka to projekt, który przekroczył budżet i / lub nie dotrzymał terminu .

Nie oznacza to, że produkt nie będzie używany. Oznacza to, że programista ma znacznie więcej bólu, pieniędzy i czasu niż oczekiwano.

When you should cancel a project? Gdy masz pewność, że każda nowa sekunda wyda na nią mniejszą wartość niż jej koszt.

Nazywa się to dylematem kosztów utopionych .

Jeśli interesuje Cię ten temat, polecam Ci Marsz Śmierci od Edwarda Yourdona . Naprawdę świetna książka.

Istnieje wiele różnych sposobów „niepowodzenia” projektu. I sporo pracowałem nad awariami:

1. Oprogramowanie do obkurczania musiało zostać przepisane w celu spełnienia nowych przepisów ustawowych / wykonawczych. Osoby źle zarządzające postanowiły unikać zatrudniania nowych osób do pomocy przy obciążeniu pracą, a zwłaszcza przy umiejętnościach, których wszystkim nam brakowało. Produkt nie posiadał nowych wymaganych funkcji (musiał mieć elektroniczną archiwizację w określony sposób) i musiał zostać wycofany z rynku. Podczas gdy produkt ten generował około 5% przychodów naszego biura, nadchodziła podobna zmiana regulacyjna, która wpłynęła na produkt, który wygenerował 60% naszych przychodów. Deweloperzy podjęli się, aby nauczyć się potrzebnych umiejętności, ale przełożeni postanowili poczekać, aż będzie prawie za późno, aby rozpocząć wdrażanie wymaganych zmian. Mieliśmy 3 lata ostrzeżenia, że ​​nadchodzą te zmiany, gdy próbowaliśmy licytować tę zmianę regulacyjną po stronie serwera - i firma słusznie zabroniła nam złożenia oferty. Nasi niewłaściwi menadżerowie postanowili, że będziemy czekać do 8 miesięcy przed zmianą, zanim będziemy mogli nad tym popracować.

2. Projekt był już przekroczony i spóźniony, kiedy zostałem zaangażowany w pomoc w jego zakończeniu. Menedżerowie o kilka poziomów wyżej zdecydowali, że koszty utopione były już zbyt wysokie, aby uzyskać wymagany zwrot z inwestycji dla projektu, więc projekt został anulowany i wszyscy zaangażowani zwolnieni. Praca tam przez tydzień, zanim cała grupa została zwolniona (łącznie ze mną), była najkrótszym czasem, w jakim kiedykolwiek pracowałem w tym miejscu.

3. Wewnętrzny projekt trwał tak długo, że sponsor projektu zakupił gotowe oprogramowanie (w tym przypadku Microsoft Office) i napisał własny VBA, aby wykonać swoją pracę. Lider zespołu programistów wciąż obiecywał księżycowi i odmówił wysłuchania podczas spotkań menedżerskich, że projekt został już odwołany. Przez około rok pracowało 6 osób, tworząc system, który nigdy nie był używany.

Jedynym projektem, w który byłem zaangażowany jako programista lub część zespołu PM, był Ricochet, który upadł wraz z bankructwem Metricoma . W całym kraju pracowały nad tym dosłownie tysiące wykonawców. Kiedy ich dyrektor finansowy zrezygnował, projekt dosłownie się zatrzymał. Meble zaczęły być usuwane z biur, gdy ludzie z likwidacji schodzili.

Dla wielu z nas stosowanym terminem było „bezrobocie”, ale Kulawa Kaczka byłaby odpowiednim opisem. Często kluczowe osoby będą musiały pozostać do czasu zakończenia sekcji zwłok / likwidacji, podobnie jak niektórzy politycy, którzy pełnią swoje funkcje przez kilka miesięcy, aby zakończyć kadencję przed przybyciem następcy.

Jak wskazał Otávio Décio , nie widziałem, aby projekt zakończył się niepowodzeniem od czasu boomu kropkowego.

Jest to powszechny problem, wspomniany również w niektórych książkach na temat zarządzania projektami. Żaden projekt nigdy „nie kończy się niepowodzeniem”, nawet jeśli wszystko, co zapewnia, to doświadczenie „tego, czego należy unikać następnym razem”.

IMO, projekt jest porażką, jeśli nie jego realizacja byłaby tańsza. Na przykład, jeśli oczekiwany okres użytkowania produktu wynosi 5 lat, a firma zaoszczędzi 100 tys. Pa, to niepowodzenie, jeśli wykonanie go zajmie więcej niż 500 tys. (Oszukuję tutaj stóp procentowych, aby uprościć). Niektórzy twierdzą, że każdy projekt z przekroczeniem kosztów i / lub czasu jest porażką, ale IMO ta definicja nie ma sensu, ponieważ zbytnio koncentruje się na prawidłowych szacunkach i planowaniu.

Nigdy też nie uczestniczyłem w żadnych „nieudanych” projektach - ale w wielu projektach z przekroczonymi kosztami i czasem. Uważam, że problem polega na tym, że żadna ze stron - klient ani kontrahent - nie chce, aby każdy projekt był uważany za porażkę z wszystkich powodów dzieci, w tym odpowiedzialności.

Myślę więc, że kiedy słyszysz „nieudane projekty IT”, w rzeczywistości są to „projekty, które przekroczyły swoje granice, zarówno w czasie, jak i w budżecie”.

W końcu - ilu ludzi lub firm, które znasz, wyszliby na czysto i powiedzieliby „zawiedliśmy”?

Jednak ciągle słyszę o „nieudanych projektach IT”.

Jakie parametry zdefiniowały „awarię”?

Jest to pejoratywny termin, często używany przy zmianie projektu. Wiele osób lubi nazywać zmiany „porażką”. Nie wiem dlaczego, ale czyni je w jakiś sposób mocniejszymi lub ważniejszymi w wykrywaniu awarii.

Niektóre projekty naprawdę tracą pieniądze i nie powstaje nic wartościowego. Ale te są rzadkie.

Nawet projekt, który nigdy nie dostarczył działającego oprogramowania, jest nauką w tym, czego nie robić. To stworzyło wartość. Stworzyło to nieprzewidzianą wartość, dzięki czemu można ją oznaczyć w dowolny sposób. „Awaria” jest tak samo dobra jak „Nauczyłem się, czego nie robić” w niektórych kręgach.

Prawdziwe pytanie brzmi: „czy wartość była współmierna do kosztu”? I nawet wtedy wartość może być tak trudna do zmierzenia, że ​​odpowiedź jest całkowicie polityczna lub subiektywna.

Czy projekt wewnętrzny dużej korporacji ma więcej miejsca na „porażkę”?

Być może. „porażka” jest terminem politycznym. Każda zmiana harmonogramu, budżetu lub zakresu może być oznaczona jako „zmiana” lub „awaria”. Można je również oznaczyć jako „dowiedziałem się czegoś ważnego o niezdolności naszego zespołu do napisania serwera WWW”. Lub jeszcze bardziej pozytywnie: „nauczyliśmy się, jakich umiejętności potrzebujemy, zanim spróbujemy ponownie”.

Projekty zewnętrzne często mają większy nadzór od sprzedawców i dostawców, księgowych i zarządzania projektami. Projekty wewnętrzne często mają mniejszy nadzór.

Kiedy dzwonisz? Co się stanie, kiedy to zrobisz?

Kiedy celowe jest zmuszenie kogoś do wyrzucenia go z organizacji, ponieważ nie zgadzasz się z nim. Opisujesz ich projekt jako „niepowodzenie” i przypisujesz je do innych osób.

Jedynym sposobem, w jaki projekt może być totalną porażką, jest oszustwo kryminalne - tam, gdzie nie wyciągnięto żadnych wniosków, nic nie można poprawić, a przestępcy zostali zwolnieni i uwięzieni, pozostawiając organizację nieświadomą, co się stało.

W przeciwnym razie zawsze znajdzie się jakaś wartość.

Prawdziwe pytanie brzmi: „czy wartość była współmierna do kosztu?”

Więc twoja firma, która rozliczała się z tym, wypracowała, przepracowała ciebie i 5 innych osób na śmierć przez 5 tygodni. Nadal czerpią zyski z ciężkiej pracy. Mam nadzieję, że coś masz, ponieważ bezpieczeństwo pracy jest obecnie niczym i jest mnóstwo pracy. (Bezwstydna wtyczka skontaktuj się ze mną, jeśli potrzebujesz pracy i jesteś kompetentnym programistą, znam kilka miejsc, które desperacko potrzebują pomocy).

To powiedziawszy, jeśli twoja firma musiała zapłacić ci za całą tę pracę i 41 godzin przed uruchomieniem, wtedy mieliby ZGUBIONE pieniądze.

Kierownictwo potrzebuje usiąść i wyjaśnienia, że ​​jeśli to się powtórzy, otrzymasz zapłatę. Muszą lepiej ocenić, kiedy wyciągnąć wtyczkę.

Ja także, podobnie jak wielu innych respondentów, uczestniczyłem w kilku dużych projektach, które przebiegały w czasie i budżecie - o ponad pół dekady. Najgorszy scenariusz (pół dekady) wiązał się z nieuzasadnionym szaleństwem w Mitycznym Miesiącu Człowieka, a także z epickim dreszczem zasięgu. To powiedziawszy, nigdy nie zostało porzucone i teraz zaczynają przyjmować niektórych klientów. Ale początkowe oczekiwania (czysty, dobrze zaprojektowany zamiennik starego, przestarzałego systemu) oraz stosunkowo skromny budżet i harmonogram - już dawno zostały zniszczone.

Ponadto, w przeciwieństwie do większości ludzi tutaj, widziałem też projekt całkowicie zawodzący - do punktu porzucenia . Ostatni gwóźdź do trumny przyszedł na początku 2010 roku. Oto scenariusz:

Mała firma (około 30 osób) robi niestandardowe rozwiązania ERP dla średnich firm. Mieli kilka stosunkowo lukratywnych instalacji logistycznych z australijskimi firmami wydobywczymi i kilka zestawów transportowych w USA. Platforma była niestandardową platformą wewnętrzną zbudowaną na J2EE. W rzeczywistości stosunkowo łatwe do dostosowania i dobrze wykonane - proste nowe instalacje można było zbudować dość szybko, ale nie skalowało się to zbyt dobrze, gdy wymagany poziom dostosowania był bardzo złożony (jak miało to miejsce w przypadku niektórych ich największych klientów).

Krótko mówiąc: niektóre z ich największych, najwyżej profilowanych instalacji działały z biegiem czasu i budżetu, i wydaje się, że rynek tego nie docenił, więc nie mogli zdobyć więcej klientów. Firma była w zasadzie kucykiem jednego trika, robiąc niewiele więcej niż ten system ERP, więc kiedy przepłynęły z niej przepływy pieniężne, wycofali się z działalności i system został porzucony (GFC mogła również odegrać w tym rolę) .

(Pracowałem tam tylko przez 9 miesięcy - w roku 2004/2005. Zasadniczo zatrudnili i zwolnili się, ponieważ nakład pracy pojawił się i poszedł z nowymi instalacjami - zamiast zatrudniać kontrahentów - co jest dość podejrzane. Z perspektywy czasu prawdopodobnie było więcej do zrobienia z niestabilnym modelem biznesowym niż z technologią).

Gdyby projekt został wdrożony w taki sposób, że pierwotne żądanie zostało spełnione, nazwałbym go projektem udanym. Dla mnie niepowodzeniem byłoby wdrożenie aplikacji, która została następnie powszechnie odrzucona przez użytkowników końcowych, ponieważ nie spełniała ich potrzeb. Albo, co gorsza, projekt zostaje zakończony, zanim produkt zostanie faktycznie wdrożony u użytkowników, a ich potrzeby zostaną zaspokojone.

Zasadniczo, jeśli firma pracuje dla klienta zewnętrznego, nie jest to ich decyzja o wycofaniu się z projektu, ponieważ mogą wystąpić problemy z kontraktem (tj. Naruszenie płatności umowy) lub poważny hit PR, jak zauważyłeś. W niektórych przypadkach, w przypadku naruszenia kary umownej, koszt jej zakończenia jest kilkakrotnie niższy niż w przypadku naruszenia umowy i preferowaną opcją jest utrata symbolicznej kwoty.

Na dłuższą metę firma może pracować nad poprawą moralności pracowników, aby nadrobić kryzys w trakcie projektu lub zastąpić pracowników, którzy odeszli, ponieważ zostali zmuszeni do ciężkiej pracy, ale czasami może być niemożliwe, aby wyzdrowieli z poważnych awarii projektu ( tj. spójrz na firmy, które nie dostarczyły produktów na czas i zbankrutowały).

Gdy sprawa biznesowa już się nie utrzymuje.

Taką miarę stosuje Prince2 (metodologia zarządzania projektami) i ma to dla mnie sens.

Zasadniczo mówi się na końcu każdego etapu projektu lub jeśli projekt wykracza poza pewne tolerancje w niektórych obszarach (harmonogram, koszt, jakość), należy dokonać przeglądu uzasadnienia biznesowego. W tym momencie przekraczasz przewidywane całkowite koszty i możliwe do osiągnięcia korzyści w oparciu o to, co teraz wiesz, a jeśli projekt nie kumuluje się, to zostaje zabity.

Problemem związanym z wieloma projektami, które widziałem, jest to, że nie przedstawiają one szczegółowo tego, co starają się osiągnąć, co bardzo utrudnia ocenę (a) czy jest to nadal realistyczne, lub (b ), czy koszty, które zamierzasz ponieść, aby się tam dostać, są tego warte. W takich sytuacjach najlepszą rzeczą, jaką możesz zrobić, jest przedstawienie uzasadnienia biznesowego w punkcie, w którym stajesz się podejrzany, abyś mógł zrozumieć, czy twoje podejrzenia są prawidłowe.

Zebranie uzasadnienia biznesowego nie musi być dużym przedsięwzięciem, wystarczy kilka stron A4. Koszty są stosunkowo łatwe (jako przybliżony pomiar programista kosztuje: (roczna pensja * 2) / 250 dziennie w Europie, prawdopodobnie nieco mniej w USA, ponieważ świadczenia są niższe, a średnia liczba dni roboczych wyższa, które są tutaj wkładami ).

Korzyści są trudniejsze, ale jeśli oszacujesz pesymistycznie tak dokładnie, jak to możliwe, to jeśli uzasadnienie biznesowe się nie ułoży (zwykle mierzone, ponieważ musi uzyskać zwrot x% kosztów w ciągu 3 lat, gdzie X prawdopodobnie wyniesie 50% lub więc) możesz spojrzeć na to bardziej szczegółowo. Nie zapomnij o kosztach licencji i sprzętu (nawet jeśli używasz istniejącego sprzętu, ponieważ oznacza to, że nie można go użyć do niczego innego po jego nabyciu) i stałej pomocy.

Ale wiele z tych rzeczy nie jest programistami, są to rzeczy, które szef i firma powinni robić przy wkładzie całego zespołu projektowego.