Pięć lat temu prawie połowa projektów informatycznych w AG Edwards miała opóźnienia i przekraczała budżet. Teraz 88% projektów w tej samej firmie kończy się powodzeniem. Jak udało się to osiągnąć?

Gdy John Parker obejmował stanowisko CTO w AG Edwards, nie miał złudzeń co do stopnia trudności czekającego go zadania. Podczas rozmów o pracę jesienią 2001 zarząd przedsiębiorstwa przedstawił mu wyraźny obraz sytuacji: projekty ciągnęły się latami, o ile w ogóle udawało się je zrealizować. Niektóre szły tak dramatycznie wolno, że firma musiała spisać je na straty. Kiepskie zarządzanie miało wyraźny wpływ na wyniki finansowe. Ludzie z zarządu powiedzieli Parkerowi, że potrzebny im jest CTO, który zreformuje dział IT i zapewni, że planowana na pięć lat i warta 196 milionów migracja krytycznego dla działania firmy systemu mainframe pójdzie gładko. Nie mogli sobie pozwolić, żeby projekt takiego rozmiaru był realizowany tak, jak to zwykle robił ich dział IT, gdzie systemy tworzone w zupełnej izolacji - czasem na przestrzeni wielu lat - po ukończeniu nie spełniały stawianych im wymagań. Tym razem porażka po prostu nie mogła wchodzić w grę.

Zobacz również:

• 9 cech wielkich liderów IT
• CIO "bumerangi": liderzy IT awansują, powracając
• 6 znaków ostrzegawczych, na które CIO powinni zwrócić uwagę w 2024 roku

Z beznadziei - sukces

Sytuacja, którą Parker zastał po objęciu nowej posady, odpowiadała temu, co słyszał podczas tamtych rozmów: prawie połowa projektów była opóźniona i nie mieściła się w założonym budżecie. Większość kosztowała o 54% więcej i trwała o 54% dłużej, niż pierwotnie przewidywano. Znalazł też ślady po projektach, których w ogóle nie doprowadzono do końca. "Realizowaliśmy setki projektów w ciągu roku, z czego 1 do 2% było anulowanych i wartość tych przerwanych projektów była znacząca" - mówi Parker, obecnie CIO. Według sprawozdania złożonego w Komisji Papierów Wartościowych i Giełd (SEC) w 2002 r., biuro AG Edwards spisało na straty inwestycje w oprogramowanie warte 46 mln USD.

Przeskoczmy w czasie do 2006 r. Firmowy wskaźnik udanych projektów (określony przez udział w ogólnej liczbie tych, które zakończono o czasie i bez przekroczenia budżetu, a które przyniosły firmie oczekiwane korzyści), poszybował z 54% w 2002 r. do 88% obecnie. Usprawnienia w zarządzaniu projektami miały ogromny wpływ na wyniki finansowe: raport dla SEC wykazuje, że koszty IT i telekomunikacji spadły z 295 mln USD w 2002 r. do 241 mln USD w roku 2005, i to mimo trwających inwestycji w migracji systemu mainframe. W tym samym czasie zyski podskoczyły z 71 mln USD w 2002 r. do 186 mln USD w 2005. Parkerowi udało się osiągnąć tak wielką poprawę dzięki temu, że zmienił sposób działania IT - począwszy od zasad współpracy z resztą przedsiębiorstwa aż po strukturę biura zarządzania projektami. Doświadczenie nauczyło go, że aby skutecznie realizować projekty, potrzeba czegoś więcej niż tylko metodologii i oprogramowania do śledzenia postępów. Udane projekty opierają się na dobrym przywództwie i konstruktywnych relacjach pomiędzy kadrą zarządzającą IT a ludźmi zajmującymi się działalnością biznesową. Wiedząc o tym, Parker zaczął poprawianie wyników swojego działu. Wspólnie z szefostwem firmy zidentyfikował najistotniejsze projekty; zorganizował też wszystkim kierownikom w dziale IT szkolenia rozwijające ich umiejętności przywódcze, tak by stali się bardziej wiarygodni dla współpracowników spoza swojego działu. "Jeśli próbuje się naprawić zarządzanie projektami, nie zaczynając od samej góry, nie można liczyć na sukces" - mówi Parker. "Projekty nie będą w stanie się przebić bez przywódców zapewniających im wsparcie z góry w razie kłopotów - niezależnie od tego, jak dobre są procedury i narzędzia kierowania projektami". Parker zaangażował również eksperta od zarządzania projektami, żeby zaszczepić odrobinę dyscypliny w całym procesie. Ed Pilewski, obecnie wiceprezes ds. produktywności i jakości IT, zdecydował się zejść z tradycyjnej ścieżki i zrezygnować z wtłaczania informatyków w ramy sztywnej metodologii kierowania projektami - mogłoby to mieć przeciwny do zamierzonego skutek, wywołując silny opór wobec wprowadzanych zmian. Wprowadził za to ustandaryzowany schemat mierzenia, monitorowania i opisywania postępów projektu, sprzyjający przejrzystości i odpowiedzialności. Zastosowany schemat pozwala kierownikom projektów na pewną elastyczność w podejściu do ich pracy. Firma przebudowała też niemal zupełnie swoje Biuro Zarządzania Projektami (PMO). Dawniej szefowie projektów składali sprawozdania ze swojej pracy do jednego scentralizowanego biura, teraz podlegają różnym grupom wewnątrz działu IT, zajmującym się m.in. tworzeniem aplikacji, inżynierią sieci czy zapewnianiem jakości. Chodzi o to, by zwiększyć ich osobiste zainteresowanie sukcesem projektu i uczynić ich równorzędnymi graczami w stosunku do kierowników działów funkcjonalnych. Zadaniem Biura Usług na Rzecz Produktywności (tak teraz nazywa się dawne PMO) jest pomaganie kierownikom w planowaniu i dostarczanie im raportów potrzebnych do utrzymania projektów na właściwej ścieżce - to istotna zmiana w stosunku do starego, zbiurokratyzowanego modelu. Specjaliści twierdzą, że całościowe podejście AG Edwards do zarządzania projektami, tak różne od standardowego, jest godne naśladowania. "Inne firmy stosują pewne elementy tego, co robi AG Edwards" - mówi Sam Lawler, dyrektor zajmujący się zarządzaniem projektami w GlassHouse Technologies. "Tym, co wyróżnia AG Edwards, jest fakt, że naprawdę zaangażowali się w reformę zarządzania projektami na wszystkich poziomach". Podejście "od szczytu w dół" użyte przez AG Edwards przy usprawnianiu zarządzania projektami przysłużyło się dobrze temu przedsiębiorstwu - może również zadziałać w przypadku innych firm.

Szersza perspektywa

Skutki słabego zarządzania projektami mogą być poważne. Dochody wielu firm, tak różnych jak Nestlé i Nike, ucierpiały z powodu nieudanych prób zastosowania informatyki. Mimo że naraża je to na spore ryzyko finansowe, wiele nadal sobie nie radzi: raptem 29% projektów informatycznych prowadzonych w 2004 r. zakończono o czasie, bez przekroczeń budżetu oraz ze wszystkimi pierwotnie planowanymi funkcjami (wg raportu The Standish Group, doradców co dwa lata wydających raport nt. stopy sukcesu projektów IT). Dobre zarządzanie projektami odgrywa kluczową rolę w zapobieganiu opóźnieniom, zwłaszcza teraz, gdy gospodarka przyspiesza, a firmy podejmują więcej inicjatyw w IT. "Zarządzanie projektami jest dziś naprawdę potrzebne. Gdy sytuacja na rynku się poprawia i zaczynają się znowu pojawiać zyski, przedsiębiorstwa mają więcej pieniędzy na inwestycje, a to zwiększa zapotrzebowanie na IT" - mówi Sam Lawler z GlassHouse. Pomimo to główną barierą tamującą efektywność, na jaką narzekali dyrektorzy ds. informatyki w badaniu "State of the CIO" z 2006 r., były właśnie opóźnienia w projektach. "Zarządzanie projektami to numer jeden spośród czynników decydujących o tym, czy organizacja będzie w stanie wykonać swoje zadania" - mówi Lawler. "Zdolność firmy do realizowania własnej strategii tkwi w umiejętności zarządzania projektami". Niestety, zarządzanie projektami nie jest łatwe. Biuro zarządzania projektami czy formalna metodologia (taka jak PMI czy ITIL) nie gwarantują sukcesu, o czym mogą zaświadczyć w AG Edwards (firma miała i jedno, i drugie). "Widziałem wiele organizacji, które używały metodologii realizowania projektów, ale ich projekty nadal się nie udawały" - mówi Peter Graham, wiceprezes firmy doradczej Palladium Group. "Jeśli nie zrobi się nic więcej, to może uda się zauważyć niewielką poprawę w jakości czy zdolności do sprostania terminom, ale nie ma mowy o trwałych rezultatach". Projekty mają kłopoty z dwóch powodów. Po pierwsze, wykorzystanie formalnych metodologii wymaga włożenia sporego wysiłku w przeprowadzenie zmian, i to nie tylko od działu informatycznego, ale od całego przedsiębiorstwa. Po drugie, biura zarządzania projektami często wyradzają się w biurokratyczne twory, niezdolne do stawienia czoła problemom dręczącym projekty, takim jak brak poczucia wspólnej odpowiedzialności między kierownikami funkcjonalnymi a kierownikami projektów. Konieczność pokonania trudnych przeszkód wyjaśnia, dlaczego biuro AG Edwards nie mogło podnieść liczby udanych projektów, opierając się jedynie na nowej metodologii czy dotychczasowym PMO.

Zacznij od samej góry

Gdy Parker został przyjęty do pracy w listopadzie 2001, jego oczom ukazał się klasyczny przypadek działu IT o mentalności pracownika najemnego: przyjmującego polecenia bez szemrania, ale nigdy nie wyjaśniającego, co można, a czego nie da się zrobić. Wiedział, że by projekty częściej się udawały, musi przełamać tę mentalność i zmienić obraz pracowników działu IT postrzeganych przez resztę firmy jako pasywni. "Udany projekt to tak naprawdę małżeństwo ludzi od biznesu i od informatyki" - mówi Parker, który w latach 1999-2001 był wiceprezesem ds. usług informacyjnych w liniach lotniczych Northwest. Pierwszym posunięciem Parkera w AG Edwards było uświadomienie kierownikom IT, że powinni być kimś więcej niż tylko potakiwaczami; musiał zadbać o ich wiarygodność w oczach reszty przedsiębiorstwa. Zaczął od wprowadzenia ciągłych szkoleń z przewodzenia ludziom dla wszystkich pracowników na stanowiskach kierowniczych w dziale informatycznym. Chciał, by zobaczyli oni swoją rolę w osiąganiu przez AG Edwards strategicznych celów. Rozumował tak: jeśli kierownicy IT zyskają pozycję prawdziwych przywódców, to ich odpowiednicy w działach biznesowych będą poważniej traktować ich opinie, przez co obie grupy będą mogły lepiej ze sobą współpracować. "Przywódcy nadają ton związkowi z ludźmi od biznesu i wyznaczają poziom wydajności, dyscypliny i skuteczności, jakimi może pochwalić się dział informatyczny" - mówi. "Jeśli zamiast przewodzić, słuchają rozkazów, nie będą mogli stworzyć właściwych relacji z biznesową częścią firmy ani skutecznie wpływać na bieg projektów". Przeszkolenie było szczególnie istotne w przypadku kierowników niższego szczebla, którzy zawsze czuli się związani ze swoimi zespołami, a nie z kierownictwem działu IT. Parker był zainteresowany ich udziałem ze względu na ogromny wpływ, jaki ludzie ci mieli na personel wykonujący rzeczywistą pracę przy realizacji projektu, od pisania kodu po testowanie funkcjonalności. Przeprowadził zatem szereg odbywających się co kwartał spotkań, podczas których kierownicy uczyli się pracować z budżetami, przedstawiać swoje wizje i wyrażać opinie w dyplomatyczny sposób. Parker pracował też wspólnie z prezesem Robertem Bagbym oraz ze starszymi członkami kadry zarządzającej nad wpasowaniem informatyki w strategię biznesową firmy. Celem było stworzenie planu, jak wzmocnić i usprawnić działanie firmy oraz znalezienie technologii, która umożliwi wzrost. By to zrobić, spotykał się regularnie z komitetem zarządzającym złożonym z ośmiu najważniejszych menedżerów w firmie - ułatwiało to wypracowanie porozumienia w sprawie najważniejszych przedsięwzięć. Precyzyjne wskazanie priorytetowych projektów pozwoliło Parkerowi skoncentrować na ich wykonaniu wysiłki swoich ludzi. Twierdzi on, że gdyby nie skupił się na inicjatywach pomagających realizować strategię biznesową i generujących zyski, to jego pracownicy ugrzęźliby w końcu w projektach o małej wartości, typu zmienianie kolorów interfejsu użytkownika.

Uparte czarne owce

Zmiana sposobu, w jaki kierownicy IT postrzegali samych siebie i wykonywali swoją pracę, była diametralną zmianą dla działu i dla całej firmy. Chociaż Parker mógł liczyć na wsparcie swoich przełożonych, nadal napotykał opór ze strony czarnych owiec w części biznesowej firmy. Ludzie ci nie chcieli korzystać z właściwych kanałów do zlecania pracy ani stosować się do nowych zasad określania wymagań. Parker zdecydował się początkowo na subtelne podejście do tego problemu. Mówi: "Nie mogłem wmaszerować komuś do biura i powiedzieć: Od teraz będziesz stosował nasze nowe zasady współpracy z działem informatycznym - to by po prostu nie zadziałało". Zamiast tego zaczął grać wobec krnąbrnych kolegów rolę dobrego policjanta. Opowiadał im o kłopotach, jakie miał z niektórymi szefami działów czy menedżerami. Jedyne, czego nie mówił wprost, to: Dokładnie taki sam problem mam z tobą. Musisz przestać kwestionować decyzje, które podjęliśmy i przestać mówić swoim podwładnym, żeby nie dawali nam szczegółowych informacji o wymaganiach.

Stawiał też za wzór innym tych szefów działów i menedżerów, którzy współpracowali z informatykami, i zachęcał ich, by sami agitowali za zmianami. Kiedy musiał już pomówić wprost z tymi szefami działów, którzy zabraniali swoim pracownikom podawania dokładnych wymagań, pokazywał im wykresy obrazujące, jak takie zachowanie zwiększa ryzyko niepowodzenia projektu. Parker często wykorzystywał konsultantów do odgrywania roli "złego gliny". Kazał im na przykład bez ogródek mówić ludziom, że muszą przykładać się bardziej do tworzenia odpowiednio dokładnych list wymagań. Zresztą, sam Parker potrafił być twardy, gdy trzeba było przywołać do porządku toksycznych wrogów IT, celowo utrudniających pracę działu informatycznego. Jeśli jego własny autorytet jako CIO nie był w stanie skłonić tych ludzi do zaprzestania destruktywnych zachowań, prosił o pomoc ich szefów (a nawet szefów ich szefów).