Projekty IT w Polsce i na świecie mają pewien powtarzalny wzorzec: przekraczają budżety, nie dotrzymują terminów, a niektóre z nich kończą się porażką. Historia Levi Strauss doskonale to ilustruje. Menedżerowie zaplanowali migrację do nowego systemu za pięć milionów dolarów, ryzyko wydawało się minimalne. Ostatecznie firma zaksięgowała 192,5 miliona strat, a CIO David Bergen stracił posadę. Dobra wiadomość jest taka, że problem nie leży w samej technologii. Leży w powtarzalnych błędach zarządzania, które można rozpoznać wcześniej, przewidzieć i skutecznie uniknąć.
Najczęstsze Problemy w Projektach IT: Dane z Polski i Świata
Projekty IT stały się kluczowe dla biznesu. Gdy projekt zawodzi, konsekwencje są brutalne: menedżerowie tracą posady, firmy bankrutują. Problem dotyczy Polski i reszty świata.
Co robić, gdy projekt wymyka się spod kontroli? Budżet przekroczony, terminy nie do utrzymania, dostawca nie radzi sobie z problemami. W takich sytuacjach kluczowe jest skorzystanie z usługi ratowania projektów technologicznych, która polega na szczegółowym audycie stanu projektu, identyfikacji długu technicznego i wdrożeniu konkretnego planu naprawczego – zanim stracisz kolejne miliony.
Skala problemu jest większa, niż myślisz. Bent Flyvbjerg i Alexander Budzier z Uniwersytetu Oxford w badaniu opublikowanym w Harvard Business Review przeanalizowali 1,471 projektów IT. Średnie przekroczenie budżetu: 27%. Brzmi do opanowania. Problem w tym, że średnia nie pokazuje prawdziwego ryzyka.
Naukowcy odkryli niepokojący wzór. Jeden na sześć projektów to „Czarny Łabędź” – przekroczenie budżetu o 200%, opóźnienie o 70%. To nie są wyjątki. To powtarzalny schemat, który niszczy firmy.
Przyczyny Porażek Projektów IT: 3 Główne Kategorie Błędów
Projekty IT zawodzą przez powtarzalne wzorce błędów w trzech obszarach: strategicznym planowaniu, zarządzaniu ludźmi i decyzjach technologicznych.
Błędy Strategiczne w Zarządzaniu Projektami IT
Badanie Project Management Institute pokazuje, że 51% marnowanych budżetów wynika z błędów strategicznych: braku całościowej wizji, złego zarządzania wymaganiami i oderwania projektu od celów biznesowych.
Najczęstszy z tych błędów? Firmy tworzą listę funkcji zamiast architektury. Sporządzają dokument z oczekiwaniami i wysyłają go do programistów. Specyfikacja opisuje projekt w oderwaniu od ekosystemu istniejących systemów. Kiedy brakuje zmapowania architektury, pojawiają się nieprzewidziane trudności przy integracji – a te pochłaniają czas i pieniądze.
Przykład z życia: firma planuje wdrożenie kosztownej platformy B2B z rozbudowanym zakresem. Dopiero analiza na miejscu ujawnia rzeczywisty problem – pracownicy spędzają godziny na ręcznym przyjmowaniu zamówień przez telefon. Projektowana platforma tego w ogóle nie rozwiązałaby.
Badanie Flyvbjerga i Budziera dokumentuje spektakularne katastrofy wywołane tymi błędami. Historia Levi Strauss to lekcja tego, co się dzieje, gdy zabraknie kontroli nad wymaganiami projektu. W 2003 roku firma miała przestarzałą sieć IT (każdy kraj miał swój własny system, który nie współpracował z pozostałymi). Migracja do SAP miała kosztować niewiele ponad pięć milionów dolarów. Brzmiało rozsądnie. Następnie Walmart zażądał, żeby nowy system integrował się z ich łańcuchem dostaw. To rozwaliło cały plan. Zakres projektu rozrósł się lawinowo – klasyczny scope creep. Podczas wdrożenia firma straciła możliwość realizacji zamówień. Trzy magazyny stanęły na tydzień. Finał? Strata 192,5 miliona dolarów w drugim kwartale 2008 roku i dymisja szefa IT, Davida Bergena.
Kmart to przykład jeszcze bardziej dramatyczny opisany w tej samej analizie. Tu projekty IT zadały ostateczny cios już walczącej o przetrwanie firmie. Na początku XXI wieku sieć handlowa traciła pozycję wobec Walmart i Target. W 2000 roku zarząd postanowił odwrócić trend przez modernizację IT za 1,4 miliarda dolarów. Rok później odkryto, że nowy system jest tak mocno dostosowany do specyficznych potrzeb, że jego utrzymanie byłoby absurdalnie drogie. Uruchomiono więc kolejny projekt naprawczy za 600 milionów dolarów. Ten również się wykolejił. Rezultat – w 2002 roku Kmart ogłosił bankructwo, zlikwidował 600 sklepów i zwolnił 67 tysięcy pracowników.
Błędy Ludzkie i Komunikacyjne w Projektach IT
Nawet perfekcyjnie zaplanowane projekty zawodzą przez problemy ludzkie.
W Polsce pokutuje błędne przekonanie: CTO to osoba zarządzająca programistami. Prawdziwa rola wygląda inaczej. CTO rozumie język zarządu, przekłada cele biznesowe na język IT, buduje architekturę systemów i ma odwagę powiedzieć: to rozwiązanie nie ma sensu.
Kolejny przypadek z badania Flyvbjerga i Budziera – Airbus A380 – pokazuje, jak problemy komunikacyjne niszczą projekty. Niemieckie i hiszpańskie zakłady używały starszej wersji oprogramowania niż brytyjskie i francuskie. Globalne zespoły nie komunikowały problemów. W 2005 roku ogłoszono sześciomiesięczne opóźnienie, w 2006 kolejne sześć miesięcy. Rezultat: spadek akcji o 26%, dymisje, straty do 2010 roku.
Historia Hershey, również przeanalizowana przez Flyvbjerga i Budziera, pokazuje opór przed zmianą. Nowy system zamówień zawiódł przed Halloween. Firma nie mogła wysłać cukierków o wartości stu milionów dolarów. Spadek zysków o 18,6% w kwartale.
Czytaj też: Project Management – studia dla przyszłych kierowników projektów!
Pułapki Technologiczne: Dług Techniczny i Problemy Integracji
Decyzje technologiczne materializują się jako katastrofy dopiero w trakcie wdrożenia. Dług techniczny i problemy integracji to ukryte bomby zegarowe.
Badanie z Oxford dokumentuje kolejne przypadki. Auto Windscreens w 2006 roku było drugą co do wielkości firmą szyb samochodowych w UK. 1,100 pracowników, 63 miliony funtów przychodu. Migracja z Oracle do Metrix plus wdrożenie Microsoft ERP. W czwartym kwartale 2010 kombinacja spadających sprzedaży, problemów z inventory i wydatków na IT doprowadziła do bankructwa.
Wśród katastrofalnych przypadków opisanych przez badaczy z Oxford jest też Toll Collect – konsorcjum DaimlerChrysler, Deutsche Telekom i Cofiroute. Technologia pobierania opłat od ciężarówek w Niemczech. Trudności w łączeniu systemów. Koszt dla rządu: ponad dziesięć miliardów utraconych przychodów.
Jak Zapobiec Porażce Projektu IT: 6 Sprawdzonych Strategii
Sukces w projektach IT nie jest kwestią szczęścia. Istnieją sprawdzone strategie, które dramatycznie zmniejszają ryzyko.
Strategia 1: Wizja Lokalna. Analiza na miejscu przed rozpoczęciem projektu. Rozmowy z zespołami, obserwacja procesów, mapowanie architektury systemów. Wycena po wizji lokalnej będzie wyższa niż konkurencja od ręki, ale w praktyce koszt końcowy podobny. Różnica: brak nieprzewidzianych dopłat.
Strategia 2: CTO Łączący Biznes z Technologią. CTO rozumie język zarządu i przekłada cele biznesowe na decyzje techniczne. Buduje architekturę systemów, wskazuje priorytety wdrożenia, pomaga wybrać: gotowe rozwiązanie, dedykowany system czy hybrydę. Odrzuca projekty bez sensu biznesowego zanim zmarnują budżet. Daje zarządowi czytelną mapę drogową.
Strategia 3: Stress Testy. Flyvbjerg i Budzier proponują dwa kluczowe pytania. Czy firma przetrwa, jeśli największy projekt przekroczy budżet o 400%? Czy wytrzyma, jeśli 15% średnich projektów przekroczą kosztorysy o 200%? Te liczby, jak pokazało ich badanie, występują z niewygodną częstotliwością. Jeśli firma nie przechodzi testu, projekt nie powinien być rozpoczęty w obecnej formie.
Strategia 4: Plan Rozwoju i Stopniowe Wdrożenie. Najpierw najważniejsze procesy, potem dodatkowe funkcje. Testowanie w rzeczywistych warunkach pracy wyłapuje problemy, których nie widać w specyfikacji. Każdy etap działa już w firmie – prawdziwe użytkowanie weryfikuje założenia projektowe.
Strategia 5: Reference Class Forecasting. Metoda rekomendowana przez badaczy z Oxford (nagrodzona Noblem praca Kahnemana i Tversky’ego). Sprawdź, ile kosztowały i trwały podobne projekty w innych firmach – zamiast wierzyć, że u ciebie będzie szybciej i taniej. To działa: obowiązkowa w UK i Danii dla dużych projektów publicznych.
Strategia 6: Dziel i Dokumentuj Każdą Zmianę. Duże wdrożenia dziel na mniejsze etapy. Wyznacz dedykowaną osobę do zarządzania wymaganiami – każda zmiana zakresu wymaga dokumentacji, wyceny i formalnego zatwierdzenia. Bez kontroli zmian projekt rozrasta się niezauważalnie
Najlepsze Praktyki Zarządzania Projektami IT: Kluczowe Wnioski
Projekty IT nie muszą być ryzykowne. Ryzykowne jest podejście bez analizy na miejscu, bez osoby łączącej biznes z technologią, bez kontroli zmian zakresu. Różnica między firmami, które tracą miliony, a tymi, które skutecznie wdrażają projekty? Jedne powtarzają błędy Levi Strauss i Kmart. Drugie stosują sprawdzone praktyki.
Przed następnym projektem zadaj sobie trudne pytanie: czy firma przetrwa, jeśli projekt wymknie się spod kontroli? Jeśli nie – zmień strategię. Każdy Czarny Łabędź, którego unikniesz, to uratowana firma i zachowane miejsca pracy. Pytanie nie brzmi, czy będą wyzwania. Pytanie brzmi: czy będziesz przygotowany?
Źródła
- https://arxiv.org/pdf/1304.0265
- https://www.pmi.org/learning/library/poor-requirements-management-source-failed-projects-9341
Dodaj komentarz