Zastosuj plan taktyczny

Mając ustaloną strategię dla IT, działający komitet zarządzający do ustalania priorytetów projektów oraz kierowników IT potrafiących przewodzić ludziom, należało pomyśleć o świeżym spojrzeniu na zarządzanie projektami. By nadać sprawie rozpęd, AG Edwards zatrudniło w 2003 r. Pilewskiego jako niezależnego konsultanta. Trzy miesiące później został on mianowany wiceprezesem ds. jakości i produktywności IT. Pilewski wie co nieco o zarządzaniu projektami. Zanim trafił do AG Edwards, przez sześć lat był niezależnym konsultantem, zajmującym się ratowaniem dużych projektów informatycznych zagrożonych niepowodzeniem. Pracował również jako dyrektor ds. realizacji projektów w oddziale firmy Capgemini w środkowo-zachodnich stanach Ameryki. W chwili przybycia Pilewskiego firma stosowała już metodologię zarządzania projektami. Pilewski nie zrezygnował z niej. Wprowadził za to radykalną zmianę: zastosował coś, co nazywa standardowym schematem śledzenia i raportowania postępów projektu. Schemat ten to zasadniczo zbiór powtarzalnych kroków służących poprawieniu terminowości projektów i stworzeniu jasnej za nie odpowiedzialności. Pilewski korzystał już z niego wcześniej i wiedział, że będzie on dla AG Edwards korzystny.

Oto jak to działa: schemat obejmuje 25 działań, które kierownicy powinni obserwować podczas trwania projektu, takich jak projektowanie architektury, analiza wymagań czy tworzenie planu testów. Kierownicy projektów są też odpowiedzialni za pewne czynności w ramach tych obszarów działań. Przykładowo, w fazie analizy wymagań stawianych aplikacji do prowadzenia rekrutacji kierownika projektu poproszono o udokumentowanie, co dokładnie - zdaniem ludzi od biznesu - tworzona aplikacja miała robić. Inną korzyścią z takiego schematu jest to, że wskazuje on istniejące systemy, które w wyniku zastosowania nowego oprogramowania czy modernizacji infrastruktury potrzebują teraz więcej pamięci lub nowych interfejsów. Można w ten sposób zlokalizować wzajemne zależności, o których kierownicy funkcyjni i kierownicy projektów powinni wiedzieć. Schemat daje również informację o tym, które grupy w dziale IT pracują nad projektem i ile czasu miesięcznie mu poświęcają, co może wpłynąć korzystnie na komunikację i dysponowanie zasobami. Przykładowo, przedsięwzięcie mające na celu wprowadzenie nowych rozwiązań technicznych do komunikacji z klientami we wszystkich oddziałach AG Edwards zaczęło się opóźniać, bo przeciążeni kierownicy projektu nie mieli czasu na rozmowy z kierownikami funkcyjnymi. Z tego powodu zdarzało się, że "za pięć dwunasta" przybiegali do kierowników funkcyjnych, wołając, żeby rzucili wszystko i kazali swoim ludziom zająć się prowadzoną właśnie modernizacją. Korzystając ze swojego schematu, Pilewski zdołał odzyskać panowanie nad projektem. Schemat sprawił, że w dziale IT zaczęto zwracać większą uwagę na ten projekt i wskazywał wyraźnie, kiedy kierownicy powinni zabrać się do instalacji infrastruktury czy testowania sprzętu i oprogramowania. Standardowy schemat określa wysokopoziomowe działania, które należy przeprowadzić w ramach realizacji każdego projektu. By zejść niżej, do szczegółów, Pilewski oraz planiści, kierownicy i twórcy oprogramowania używają stworzonego przez firmę Primavera programu dającego im do dyspozycji wykresy i raporty postępów do śledzenia projektu. Wszystkie 126 projektów firmy jest realizowanych przy użyciu schematu Pilewskiego, przez co ich postępy mierzone są w ten sam sposób.

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

Warto zauważyć, że standardowy schemat planowania nie określa sposobu, w jaki kierownicy projektowi i funkcyjni powinni wykonać każdy z tych 25 kroków - to różni go od tradycyjnej metodologii projektowej. Dzięki temu, że schemat określa, czego należy pilnować, zamiast jak należy to robić - twierdzi Pilewski - pozwala kierownikom elastycznie podchodzić do podziału swojej pracy na etapy. Co więcej, mogą oni stosować ten schemat w połączeniu z dowolną metodologią tworzenia aplikacji. Jest to istotne, bo standardowe metodologie zarządzania projektami mogą być dla nich zbyt sztywne, za bardzo ich ograniczając.

Sztuka przekonywania

Chociaż standardowy schemat planowania jest elastyczny, w dziale informatycznym nie było łatwo go sprzedać. Żeby przeciągnąć ludzi na swoją stronę, Parker i Pilewski stosowali rozmaite metody. Po pierwsze, Parker odwołał się do poczucia profesjonalizmu swojego zespołu. Wiedział, że jego ludzie nie byli zadowoleni z tego, że projekty ciągną się przez lata. W rozmowach w cztery oczy, na spotkaniach z poszczególnymi zespołami i formalnych zebraniach przekonywał swoich pracowników, że schemat pomoże im osiągnąć cele. Następnie Pilewski wybrał spośród kierowników projektów tych, którzy dobrze przyjmowali nowe pomysły i parli do poprawienia skuteczności. Poprosił ich, żeby zaangażowali się w małe projekty pilotażowe - mały projekt związany z zakupem produktów i większa modernizacja infrastruktury aplikacyjnej - w których po raz pierwszy zastosowali standardowy schemat planowania. Kierowników tych użył potem Pilewski w roli ewangelistów mających nawrócić resztę zespołu. Pilewski i jego Biuro Zarządzania Projektami służyło też wszystkim kierownikom projektów pomocą w planowaniu, żeby nie czuli się przytłoczeni koniecznością nauczenia się nowych narzędzi związanych z nowymi wymaganiami. Konkretnie, PMO włączało indywidualne plany kierownika projektu do standardowego schematu planowania. Wszystko, co taki kierownik musiał zrobić, to określić sposób, w jaki jego praca miała być podzielona na etapy, i zdecydować, czy chce dostać swój plan w formacie MS Worda, Excela czy na tablicy. Pilewski mówi, że dostępność usług zapobiegła gromadzeniu się negatywnych emocji wokół nowo wprowadzanego schematu. Parker wreszcie nakłonił dział IT do zaakceptowania tej nowej, bardziej zdyscyplinowanej mentalności w zarządzaniu projektami, mierząc stopę sukcesu projektów i publikując wyniki w cokwartalnych raportach przedstawianych najważniejszym ludziom w AG Edwards. Doszedł do wniosku, że jeśli jego ludzie będą wiedzieć, że ich wyniki są śledzone przez szefów firmy, to będą poważniej traktować zarządzanie projektami.

Co to jest sukces?

Oprócz wprowadzenia standardowego schematu planowania, Parker zmienił też kryteria sukcesu projektów. Zamiast definiować powodzenie jako zakończenie projektu o czasie i bez przekroczenia budżetu, w AG Edwards uwzględnia się jego wartość biznesową - kryterium kluczowe dla zleceniodawców projektu. Innymi słowy, jeśli projekt nie został ukończony o czasie, ale wnosi do biznesu oczekiwaną wartość, to firma nadal uważa go za udany. Parker nie zmienił definicji udanego projektu w celu obniżenia poprzeczki; przedefiniował pojęcie sukcesu po to, żeby to wewnętrzni klienci mieli ostatnie słowo - żeby końcowy wynik bardziej odpowiadał ich potrzebom. Dla przykładu, Pilewski wspomina, że gdy dział IT został poproszony o stworzenie aplikacji do rekrutowania doradców finansowych, wyglądało to na szybkie i tanie przedsięwzięcie. Pracując razem ze zleceniodawcami nad wymaganiami funkcjonalnymi, zespół realizujący ten projekt zrozumiał, jak tworzona przez nich aplikacja może zwiększyć konkurencyjność firmy, pozwalając jej na ściągnięcie najlepszych i najzdolniejszych maklerów. Członkowie zespołu stwierdzili, że aby ich aplikacja nabrała właściwego kształtu, będą musieli jej poświęcić więcej czasu. Projekt zajął trzy razy więcej czasu i kosztował ponad dwukrotnie więcej niż początkowo szacowano, ale i tak uznano go za sukces, bo pozwolił ulepszyć proces rekrutacji. "Szefowie projektów skupiają się na kosztach i terminach - mówi Pilewski - ale kluczem do zarządzania projektami jest zapewnienie, żeby kierownicy rozumieli, że to klienci odgrywają tu główną rolę, i że to klienci oceniają, czy projekt się udał". Zmienił on też strukturę biura zarządzania projektami, tak by pobudzić u kierowników projektów i kierowników funkcyjnych w dziale informatycznym poczucie wspólnej odpowiedzialności za projekt - ich cele i priorytety zwykle się różnią. "Ludzie od infrastruktury informatycznej mają swoją codzienną pracę" - mówi Lawler z GlassHouse. "Muszą radzić sobie z przerwami w produkcji i gasić pożary, a takie sprawy często spychają projekty na dalszy plan". Pilewski mówi, że właśnie taki scenariusz rozgrywał się w AG Edwards w chwili jego przybycia. Żeby to naprawić, przesunął kierowników projektów z Biura Zarządzania Projektami do obszarów funkcyjnych. Kiedy składali raporty ze swej pracy do Biura, nie odczuwali na własnej skórze zmian w systemach IT, które były skutkiem ich projektów. Nowa organizacja zwiększyła zainteresowanie kierowników projektów prawidłowym działaniem systemów, bo teraz musieli z nimi pracować na co dzień. Nowa struktura podległości odciążyła jednocześnie kierowników funkcyjnych, którzy musieli czasem koordynować swoje działania z wieloma kierownikami projektów naraz - osobno dla każdego przedsięwzięcia, w którym brała udział ich grupa. Teraz spotykają się tylko z jednym kierownikiem projektu, tym przypisanym do ich grupy. Ponadto kierownicy funkcyjni mają teraz dostęp do raportów z Primavery, wskazujących projekty, za które odpowiadają ich grupy - dzięki temu mogą planować przydział pracy i efektywnie przydzielać swoje zespoły do projektów.

Wzrost wiarygodności

Dzisiaj akcje IT w tym biurze maklerskim rosną, dzięki nowo uzyskanej zdolności do skutecznego zarządzania projektami i pomagania części biznesowej w osiąganiu jej celów. Projekty spisywane na straty to już przeszłość. "Dostajemy więcej za te same pieniądze, bo prowadzimy projekty w bardziej efektywny sposób" - twierdzi Parker. A co z tą wartą 196 milionów migracją systemu mainframe, którą miał pokierować? Parker mówi, że pierwsza faza tego wieloletniego projektu, choć wyczerpująca, przebiegła gładko. Zespół pracujący nad projektem przekonwertował stary system w maju 2005, tak jak pierwotnie planowano. I choć budżet rozrósł się o 9,5%, Parker sądzi, że zmieściło się to "swobodnie w przyjętych ograniczeniach". Pod wrażeniem sukcesu, AG Edwards sfinansowało ostatnią fazę projektu, która powinna dobiec końca do 2008 r. "Zrobiliśmy wielki krok naprzód" - mówi Parker. "Jeśli mieliśmy osiągnąć 1000-procentową poprawę, to osiągnęliśmy już prawdopodobnie 700%. Zostało jeszcze 300".

<hr>Tłumaczenie, na podstawie amerykańskiego CIO: Adam Maciejewski