Siedem mitów

Twój ostatni projekt systemu informatycznego (IS) okazał się klapą - przekroczyłeś budżet, spóźniasz się i tracisz kontrolę. Zbytnio uwierzyłeś w magię oprogramowania wspomagającego zarządzanie projektem.

Twój ostatni projekt systemu informatycznego (IS) okazał się klapą - przekroczyłeś budżet, spóźniasz się i tracisz kontrolę. Zbytnio uwierzyłeś w magię oprogramowania wspomagającego zarządzanie projektem.

Nic nie rozumiesz. Wszystko wykonywałeś jak należy. Gdy zostałeś szefem ważnego projektu IS, zabrałeś się rzetelnie do pracy. Czytałeś książki i najnowsze opracowania, uczestniczyłeś w seminariach i konferencjach, wsiąkłeś po uszy w studia nad najnowszym oprogramowaniem wspomagającym tego typu projektowanie. I co? I kończysz ze spóźnieniem, o 80% przekroczonymi kosztami i zadaniem wypełnionym w 70%. Co się stało? To proste. Zderzyłeś się z politycznymi i organizacyjnymi realiami - z żywym biznesem.

Sercem każdego udanego projektu jest poprawne określenie jego zakresu. Według definicji ze słownika Webstera, zakres - to "pole działania, aktywności bądź wpływu; zasięg operacji". Według Instytutu Zarządzania, właściwe zdefiniowanie zakresu sprawia, że projekt spełnia wszystkie założenia - i tylko założenia (zarówno niespełnienie, jak i przekroczenie przyjętych założeń świadczy w tym kontekście o źle zdefiniowanym zakresie). Eksperci twierdzą, że wszystkiego można się nauczyć z książek, ale należy czytać między wierszami...

"Istnieje wiele technicznych aspektów mających wpływ na projekty - tu można z dobrym wynikiem stosować książkowe modele i metody komputerowe. Jednak inne czynniki okazują się równie istotne. Dotyczą one przede wszystkim aspektów natury politycznej i organizacyjnej", mówi Joan Knutson - prezydent i założycielka Project Management Mentors Inc. - przedsiębiorstwa konsultingowego z San Francisco. "Cokolwiek zrobisz, niezależnie od technicznej poprawności twoich rozwiązań, zawsze masz duże szanse na popełnienie błędów, które potem mogą zadecydować o twojej porażce", dodaje.

Tą opinię potwierdziło ostatnie badanie wykonane na populacji 150 menedżerów IS. Okazało się, że połowa projektów nie spełniła założeń, przekroczyła budżet bądź była spóźniona. Z jednej czwartej projektów trzeba było całkowicie zrezygnować (niestety, po półtorarocznym bądź dwuletnim okresie niezwykle kosztownych prac). Często też następował "poślizg zakresu". Terminu tego użyto w badaniu do określenia sytuacji, w której trzeba było zmienić założenia projektu już w trakcie jego realizacji (wielu menedżerów używa błędnie tego terminu w odniesieniu do zmian narzucanych przez zleceniodawców). W rzeczy samej, przyczyny niepowodzeń bywają bardzo skomplikowane i nieprzewidywalne.

A teraz serio: istnieją metody na zminimalizowanie niebezpieczeństw powodujących poślizg zakresu. Ale nie można ich znaleźć w prostych opracowaniach czy pakietach wspomagających, instalowanych w komputerach osobistych.

"Zastosowanie właściwych technik zarządzania projektem i dobór odpowiednich narzędzi to tylko 10% gwarancji sukcesu", mówi Arik Paran - wiceprezydent w Cadence Design Systems Inc. w San Jose. Zgadza się z tą opinią także pani J. Knutson. Jednocześnie przestrzega ona przed fascynacją pięknymi rysunkami otrzymywanymi za pomocą skądinąd bardzo użytecznych narzędzi, takich jak PERT (Program Evaluation and Review Technique). "Rysunki i sieci działań są bardzo użyteczne, ale niekoniecznie prowadzą do sukcesu", mówi.

Istnieje siedem mitów związanych z ustalaniem zakresu projektu IS. Im wcześniej manager projektu zda sobie sprawę, że są to jedynie mity - tym lepiej.

Mit pierwszy

Dopóki w projekcie biorą udział przyszli użytkownicy - możesz być pewny, że będzie on odpowiadał ich potrzebom i brał pod uwagę realia przedsiębiorstwa.

Rzeczywistość

Udział udziałowi nierówny.

Zbyt często "udział użytkownika" przybiera formę niejasno sformułowanych koncepcji kierownictwa przedsiębiorstwa. Przejście od takiej niejasnej koncepcji do konkretnej realizacji związane jest z wieloma niebezpieczeństwami (zwłaszcza, gdy autor koncepcji jest zbyt zajęty, by przedyskutować szczegóły).

"Właśnie w tym momencie zaczyna się praca nad rzeczywistym projektem", mówi Jeff Koroknay z Honeywell Inc.. "Należy natychmiast wymusić na użytkowniku konkrety. W przeciwnym razie straci się zbyt dużo czasu na odgadywanie jego intencji".

"Jeszcze większym niebezpieczeństwem jest użytkownik, który wydaje się być genialny i który zgadza się na wszystko", ostrzega Gopal Kapur - prezydent Center for Project Management. "Z takim na pewno w końcu będą największe kłopoty, mogę się założyć, że przy odbiorze projektu powie: ale ja wcale nie to miałem na myśli", dodaje.

Jeśli nawet kierownictwo przedsiębiorstwa przestanie wyrażać mało konkretne opinie i przekaże swoje pełnomocnictwa rzeczywistym, przyszłym użytkownikom systemu, to i tak wszelkie wątpliwości i ostrzeżenia ze strony twórców systemu będą traktowane z podejrzliwością. Po prostu nie ma gwarancji, że przyszli użytkownicy będą mogli zrozumieć twórcze koncepcje tkwiące w projekcie. Wtedy lepiej jednak zapewnić sobie udział w zespole kierownika wysokiego szczebla. "Współpraca z użytkownikami - to współpraca z właściwymi użytkownikami", mówi Diana L. Garret - IS manager z Intela. "Nie podchodzę do projektu, dopóki nie zapewnię sobie współpracy kierownika mogącego samodzielnie podejmować decyzje finansowe. I zapomnijcie o pełnomocnictwach, tu stawki są zbyt wysokie", dodaje. Udział osoby z wysokiego szczebla rozwiązuje jeszcze jedną trudność - nadmiar demokracji. "Jałowe dyskusje są zmorą spotkań roboczych", twierdzi pani D. Garret.

Mit drugi

Zasadniczym celem określenia zakresu projektu jest jasne sformułowanie założeń jakie projekt ma spełnić.

Rzeczywistość

Określenie zakresu projektu pokazuje raczej czego projekt na pewno nie spełni.

"Określenie czego nie można spodziewać się po projekcie jest istotnym elementem gry, pomaga rozpisać role i ustalić odpowiedzialność", mówi John Tuman - prezydent Management Technologies Group Inc. "Jest to zwłaszcza istotne w przypadku projektowania systemów informatycznych. Powszechne jest wzajemne niezrozumienie przyszłych użytkowników i twórców projektów. Posługiwanie się żargonem nie ułatwia sprawy. Określenie na początku dyskusji - czego projekt nie dotyczy, pozwoliłoby uniknąć wielu nieporozumień", dodaje J. Tuman.

"Ustalając zakres projektu buduje się mur otaczający zasoby potrzebne do jego realizacji. Trzeba jednak pamiętać, że mur może być wykorzystywany zarówno jako przeszkoda przy ucieczce, jak i zapora przeciwko dostaniu się do środka", mówi pani J. Knutson.

Mit trzeci

Gdy już określiłeś zakres projektu, to się go trzymaj. Za każde odstępstwo zapłacisz utratą kontroli.

Rzeczywistość

Bez wątpienia będziesz musiał zmieniać zakres projektu. Zaplanuj to.

W rzeczywistości, jednym z największych źródeł kłopotów dla kierownika projektu IS jest zbyt wczesne (zanim znane są wszystkie detale przyszłej pracy) ustalenie harmonogramu i preliminarza prac. Dobry kierownik planuje drogę kolejnych przybliżeń, w sposób płynny i elastyczny. Uściśla swe wyliczenia w miarę jak dysponuje coraz dokładniejszą informacją, nie wahając się (gdy zajdzie potrzeba) żądać zmiany przyjętego budżetu bądź harmonogramu.

"Określenie zakresu projektu jest z definicji czymś bardzo twórczym. W miarę zaawansowania prac dobry menedżer szybko dostrzega te aspekty, które nie były brane pod uwagę we wstępnej fazie", mówi J. Tuman. Andy Cables z Shell Oil Co. idzie w swej opinii jeszcze dalej: "Nie znam projektu, który nie wymagałby zmian zakresu, dotyczy to nawet tych najlepiej udokumentowanych i rozpoznanych."

W zasadzie dobre ustalenie zakresu projektu polega na odpowiednim kierowaniu jego zmianami. Jasno ustala się założenia, a następnie w sposób elastyczny, systematycznie dokonuje się potrzebnych korekt. Oczywiście w jakimś momencie powstaje ostateczny harmonogram, preliminarz i opis oczekiwań w stosunku do projektu. Tym niemniej zawsze powinno być możliwe wprowadzenie koniecznych korekt. Mechanizmem ułatwiającym dokonywanie zmian jest powołanie komisji składającej się z dwóch przedstawicieli wysokiego szczebla: jednego reprezentującego użytkownika i jednego - projektanta systemu. Konieczne zmiany zakresu projektu muszą być zatwierdzone przez taką komisję, zanim nabiorą mocy.

"Niebezpieczne jest zbyt wczesne ustalenie ostatecznego kształtu projektu", ostrzega raz jeszcze G. Kapur. W jego firmie obowiązuje 24-stopniowy cykl zarządzania projektem. W fazie pierwszej ustala się "pożądany zakres projektu", zaś dopiero w fazie dwunastej - "zakres możliwy do realizacji". Konkretyzuje się go w fazie następnej. Dopiero w fazie dwudziestej ustala się ostateczny budżet projektu. "Oczywiście cały czas mamy do czynienia z różnorodnymi zmianami, z których ostatnie wprowadza się w fazie 22 (a więc prawie na ukończeniu projektu)", mówi G. Kapur.

Mit czwarty

Główną pracą komisji zajmującej się zmianami zakresu projektu, jest arbitraż związany z żądaniami użytkownika dotyczącymi rozszerzenia projektu.

Rzeczywistość

Problemy związane z zakresem projektu wychodzą znacznie poza dodatkowe wymagania jego przyszłego użytkownika.

"Jeśli masz spóźnienie - to jest to zmiana zakresu. Jeśli przekraczasz budżet - również zmieniasz zakres", mówi Ray Ju, kierujący projektami w Wells Fargo Bank w San Francisco. R. Ju lubi przyrównywać pracę nad projektem do poruszania się po trójkącie. Jeden bok trójkąta reprezentuje merytoryczne cele projektu (cechy i funkcje), drugi jest osią czasu, zaś trzeci bok oznacza potrzebne zasoby (takie jak środki finansowe, pracę specjalistów oraz wyposażenie). Gdy użytkownik zmienia swe wymagania (pierwszy bok trójkąta) - to powoduje to konieczność zmiany terminarza (bok drugi), bądź zwiększenia kosztów (trzeci).

Często umyka uwadze, że zmiana terminu lub poświęcenie dodatkowych środków finansowych na realizację są wzajemnie wymiennymi rozwiązaniami. "Jeśli wykonanie opóźnia się, to albo można zmienić harmonogram, albo powołać więcej ludzi do pracy - co oczywiście podniesie koszty", dodaje R. Ju.

Mówiąc w skrócie, każda zmiana oryginalnego planu (niezależnie czy dotyczy celów projektu, harmonogramu bądź kosztów) wymaga, aby decyzja była podjęta przez upełnomocnioną komisję. Należy przy tym zadbać, aby projekt nie szedł w złym kierunku, w czasie gdy komisja debatuje nad koniecznymi jego zmianami.

Jim Willbern - prezydent firmy konsultingowej z Little Rock w stanie Arkansas - wspomina pracę nad kanadyjskim projektem. W projekcie tym komisja ustanowiona przez klienta długo debatowała nad konieczną zmianą zakresu. Wszystko byłoby w porządku, gdyby nie fakt, że w tym samym czasie prace nad projektem idą pełną parą w dotychczasowym kierunku. Gdy już porozumiano się co do ostatecznego kształtu projektu to okazało się, że wprowadzenie zmian będzie dodatkowo kosztowało 25 mln USD - prace bowiem zaawansowano już znacznie w niewłaściwym kierunku. "A więc jest istotne określenie, w jakim kierunku prowadzone są prace podczas debat nad koniecznymi zmianami", konkluduje J.Willbern.

Mit piąty

Organizując regularnie i często spotkania informacyjne dla kierownictwa utrzymujesz je w świadomości postępu prac i zapewniasz sobie dobrą współpracę.

Rzeczywistość

Trudno jest być pewnym, że ktoś rzeczywiście słucha twoich wywodów.

D. Garret podkreśla, że choćbyś włożył nie wiem jak dużo wysiłku w utrzymywanie kontaktu z kierownictwem, to i tak twoje wysiłki będą zignorowane aż do momentu, gdy już będzie zbyt późno, aby cokolwiek poprawić. "Kierownicy - to klasa ludzi wciąż zajętych. Trudno skupić ich uwagę na szczegółach. Niby przychodzą na spotkania, ale myślami są gdzie indziej", twierdzi.

"Aby naprawdę zwrócić uwagę decydentów, należy jasno określić ich udział w projekcie", mówi J. Tuman. Następnie podkreśla rolę wyeliminowania z raportów żargonu i nieczytelnych dla użytkowników odniesień technicznych. Nie można przecież wymagać od księgowego firmy, aby czytał informacje o technologiach zorientowanych obiektowo. Natomiast wytłumaczenie w jaki sposób dodatkowa pozycja menu ułatwi wydajność księgowania - z pewnością go zainteresuje.

G. Kapur ostrzega również przed niebezpieczeństwem przypadkowych spotkań z członkami kierownictwa. Często nie zachowują oni należytej uwagi podczas zebrań, ale gdy spotkają ciebie przypadkiem na korytarzu, wpadają na "znakomite" pomysły. Nie zdają sobie sprawy, jak dużą presję wywierają w ten sposób na twórców projektu. "Trzeba nauczyć się dawać odpór takim praktykom. Nigdy nie wsiadaj z klientem do windy. Jeśli Ci się to już przytrafi, to spróbuj powiedzieć, że postawiony problem wymaga formalnego przedyskutowania w odpowiednim gronie", mówi.

"W zasadzie nie jest tak źle - jak na to wygląda. Jeśli dobrze kierujesz projektem, to zawsze masz w zanadrzu coś, co pozwala uniknąć kłopotów tego typu. Jest to trochę tak jak w polityce - zawsze trzeba mieć coś na czarną godzinę", komentuje pani J. Knutson.

Mit szósty

Jeśli odrobinę się spóźniasz albo trochę przekroczyłeś preliminarz, to zawsze masz szanse nadrobić stracony czas lub zrobić oszczędności. Nie ma co robić zbędnego alarmu.

Rzeczywistość

Złe wiadomości nigdy nie są mile widziane, ale lepiej powiedzieć je od razu.

"Poślizg zawsze będzie poślizgiem", mówi pani D. Garret. "Nie licz nigdy na nadrobienie strat, to się prawie nigdy nie udaje", dodaje.

R. Ju podziela ten pogląd: "Nie ma dymu bez ognia. Projekty nie upadają w ciągu jednej nocy". Szefowie projektu powinni zachować czujność i gdy widzą pierwsze oznaki kryzysu, powinni poinformować szefów o możliwych implikacjach. "Są odpowiedzialni za informowanie klienta o faktach tak, aby ten mógł przedsięwziąć jakieś kroki. Aha, i nie wahaj się organizować nawet codziennych spotkań - unikniesz potem zaskoczenia klienta nieprzyjemną wiadomością", dodaje R. Ju.

Problem nie jest jednak tak prosty, twierdzi Willbern: "Możesz należeć do organizacji, gdzie podanie złej wiadomości równa się samobójstwu..." Strach przed skutkami szerzenia złych wiadomości może sparaliżować pracę zespołu. Twoi podopieczni mogą w tych warunkach zaprzestać informowania także ciebie - jeśli tylko wiadomości są złe. "W tym przypadku masz problem o którym teorie nie mówią", konkluduje.

Mit siódmy

Im większy projekt - tym więcej trudności możesz napotkać. Jeśli tylko masz wątpliwości, podziel swój projekt na kilka mniejszych.

Rzeczywistość

Często można dokonać istotnych oszczędności zwiększając zakres projektu.

"Problemy napotykane przy realizacji dużych projektów są dobrze udokumentowane", mówi Chris Kemerer profesor z MIT - Mekki amerykańskich uczonych. Natomiast mniej oczywiste jest, że zwiększenie skali projektu pozwala często zwiększyć wydajność pracy, a także zastosować technologie redukujące koszty.

Dość powszechna praktyka utrzymywania programów polega na odkładaniu kilku zmian do momentu, gdy ich liczba uzasadni poważniejszą zmianę i wypuszczenie nowej wersji aplikacji. "Przyczyna jest prosta - bezsensowne jest dokonywanie małej zmiany, testowanie jej i oddawanie użytkownikom. Łatwiej jest zebrać kilka zmian i wykonać tę operację jednorazowo, gdyż lepiej rozkładają się koszty", tłumaczy Kemerer. "Jest to niezgodne z powszechną opinią, ale czasami większe jest lepsze", dodaje.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200