Skuteczne zarządzanie projektami

Autor: Alessandro Muti

Opublikowano: 19 października 2009

Nie można zaprzeczyć, że współczesne środowisko techniczne tworzy rosnące i gwałtownie zmieniające się wyzwania dla organizacji IT. Poprzez rozpowszechnienie mediów społecznościowych, „inteligentnych” telefonów, intranetów, ekstranetów i całego kręgu innych technologii zawód specjalisty IT wyewoluował od prostego zarządzania serwerami i infrastrukturą do czegoś zbliżonego do wszechstronnego projektanta oprogramowania.

Dodajmy do tego bieżące trudności ekonomiczne, które zmuszają wiele firm do cięcia kosztów i redukowania personelu, co powoduje, że nacisk na pracowników IT jest jeszcze większy niż kiedykolwiek dotąd. Co więcej, niezależnie od tych wszystkich wyzwań, nadal muszą oni dbać o serwery i infrastrukturę i realizować więcej projektów niż kiedykolwiek dotąd, mając mniejsze zasoby. W obliczu tych wyzwań techniki kierowania projektami i zarządzania oddolnego stają się niezbędnymi narzędziami, mogącymi zapewnić sukces projektu, który bez nich zakończy się niepowodzeniem.

Jednym z problemów, z którymi ciągle się spotykam w całej mojej karierze, jest fakt, że specjaliści techniczni często są w naturalny sposób nieufni wobec zarządu. Jest to zazwyczaj spowodowane tym, że menedżerowie rzadko mają podobne przygotowanie, a tym samym inne są ich wyobrażenia na temat złożoności tworzenia i realizowania projektu. To z kolei powoduje frustrację członków zespołu projektowego i sprawia, że zachowują rezerwę, albo wręcz postawę: „A nie mówiłem”, co w rezultacie sprawia, że to oni zostaną obciążeni winą za ewentualne niepowodzenie. Problemem jest w istocie niemożność skutecznej komunikacji z łańcuchem zarządzających – ludźmi, którzy mówią w rzeczywistości zupełnie innym językiem. Niestety, jest to sytuacja powszechna. Wydaje nam się, że właściwie poinformowaliśmy o ryzyku i orientujemy się, że nie zostaliśmy zrozumiani dopiero wtedy, gdy jest już zbyt późno. Niestety, postawa typu: „to nie jest nasz problem” może doprowadzić do niepowodzenia nawet takich projektów, które – technicznie rzecz biorąc – mają bardzo solidne podstawy.

Niektóre projekty, co na pewno wielu już widziało, wydają się skazane na niepowodzenie od samego początku. Nawet doświadczeni specjaliści dają się wciągnąć w pułapkę nieprzespanych nocy, próbując naprawić złe decyzje umiejętnościami technicznymi; niestety w wielu wypadkach jest to po prostu niemożliwe. Gdy coś takiego się stanie, zamiast stwierdzać, że to nie nasz kłopot, znacznie lepiej jest przerwać, ustalić, gdzie leżą prawdziwe problemy dotyczące projektu i następnie je rozwiązać, zamiast dokonywać heroicznych wysiłków w nadziei, że projekt mimo wszystko zakończy się sukcesem. Jeśli nie, to mimo wykonania najlepszej pracy zostaniemy powiązani z tym niepowodzeniem.

Najlepsze, co można zrobić, to – zgodnie z moim doświadczeniem – zachować czujność od samego początku projektu. Zazwyczaj, gdy projekt startuje, wszyscy są szczęśliwi, pełni energii i wydaje się, że istnieje zgoda i pełne zrozumienie kierunku rozwoju, kosztów, sprawdzania postępów i tak dalej. W miarę upływu czasu jednak nieuchronnie pojawiają się problemy. Może to być drobny problem techniczny, na przykład wydajność bazy danych nie jest tak dobra, jak oczekiwano, albo nie dajemy rady obsłużyć ruchu. Nagle coś, co mogłoby zostać łatwo rozwiązane i wszystkie wskaźniki ostrzegające o możliwym niepowodzeniu zostają połączone w jeden wielki mętlik, niemożliwy do rozplątania.

Czym są zatem te wskaźniki i jak możemy się upewnić, że projekt przebiega prawidłowo?

Przede wszystkim najważniejszą rzeczą jest przygotowanie wizji i zakresu projektu. Muszą one zostać uzgodnione na samym początku, wraz z określeniem, co jest wymagane w celu realizacji tej wizji. Bez tego nastąpi nieunikniona rozbieżność pomiędzy tym, co chcielibyśmy uzyskać, a tym, co w rzeczywistości będzie budował zespół projektu. Gdy tylko rzeczywistość zacznie odbiegać od wizji, trzeba natychmiast interweniować i wrócić do szeregu, by realizować to, czego oczekuje nasz menedżer, co wyobrażają sobie użytkownicy i co powinniśmy dostarczyć na koniec.

W celu zagwarantowania, że tak się stanie, odkryłem, że przydatne jest posiadanie dokumentu aktualizowanego cały czas, odwołującego się do celów biznesowych wysokiego poziomu, jawnie artykułującego potrzeby i wymagania wszystkich osób biorących udział w projekcie oraz interakcje pomiędzy nimi. Dbając o to, aby dokument ten zawsze był aktualny, udostępniając go i uzyskując zarówno consensus, jak i aprobatę wszystkich zaangażowanych możemy co najmniej zminimalizować ryzyko, że nastąpi rozdział pomiędzy żądaniami menedżera lub innych zwierzchników a oczekiwaniami naszych użytkowników. Powstrzyma to również przed rozpoczęciem projektu zespół, mający jedynie powierzchowne rozumienie jego wizji. Trzeba zwrócić uwagę, że dokument wizji nie jest dokumentem zakresu. Ten ostatni jest tworzony przez menedżera programu lub też przygotowuje go sam zespół w celu dopasowania wizji do szczegółów konkretnego rozwiązania.

Prowadzi nas to do kolejnej bardzo ważnej części udanego projektu – zrozumienia jego zakresu i zapewnienia, że wszyscy inni również go rozumieją. Powinno odbyć się kilka spotkań wszystkich zainteresowanych stron, prowadzących do consensusu odnośnie zakresu projektu. Istnieje wiele sposobów określania zakresu i nie będę się tu zagłębiał w szczegóły, ale typowym błędem jest niedocenianie wysiłków wymaganych do rozwiązania bardziej złożonych problemów technicznych. Wielu z nas jest z natury optymistami, zatem próbujmy o tym pamiętać, przewidując wysiłek niezbędny do budowy rozwiązania.

Oczywiście w tej fazie jest bardzo wiele niewiadomych i konieczne będzie poczynienie pewnych założeń. Niezwykle ważne jest udokumentowanie tych hipotez i określenie wpływu, jaki mają na cały projekt. Negocjowanie szczegółów również może również zawczasu ostrzec nas o możliwych nieporozumieniach w interpretowaniu dokumentu wizji. Jeśli na przykład dwie osoby nie zgadzają się co do potrzebnego czasu i wysiłku, bardzo możliwe, że odczytały one i zrozumiały dokument naszej wizji w zupełnie różny sposób, co jest sygnałem, że konieczne może być sprawdzenie, czy wizja jest wystarczająco jednoznaczna i czy wszyscy uczestnicy myślą o tych samych elementach w tych samych terminach.

Dokumentacja założeń jest elementem krytycznym, gdyż zapewnia podstawy do przedyskutowania wielu nietechnicznych wyzwań zarówno z wyższym kierownictwem, jak i udziałowcami, a także może pomóc wszystkim w zrozumieniu ograniczeń, w których trzeba coś zrobić, aby zapewnić sukces projektu. Ogólnie mówiąc, można wykorzystać ten dokument do zainicjowania trudnych, ale niezbędnych rozmów na temat zakresu z przedstawicielami zarządu i do przekształcenia niektórych wczesnych obaw na pytania, które pomogą określić granice zakresu. Bez tego wiele rozmów w ogóle się nie odbędzie.

Po pokonaniu tej wstępnej fazy musimy wybrać właściwą metodologię prowadzenia projektu. Istnieje mnóstwo zróżnicowanych modeli i wszystkie mają swoje zalety i wady. Nie istnieje model, który by zawsze działał, zaś wybranie niewłaściwego może stać się przekleństwem projektu. Wiele firm ma zaakceptowane metody postępowania, które (jak się oczekuje) powinny być przestrzegane, ale podejście takie często spotyka się z oporem jako zbyt restryktywne albo po prostu nie dość „doskonałe” dla konkretnego zagadnienia. Jednak model ten jest ważny, gdyż – o ile jest właściwie dopasowany – zapewni system przejść i punktów kontrolnych, umożliwiających połączenia ze wszystkimi udziałowcami. Będziemy mogli zapewnić zaangażowanie menedżera, tym samym zabezpieczając się przed okolicznością, gdy zwierzchnicy wyższych szczebli podejmują decyzje bez pełnego rozeznania w sytuacji, albowiem będą oni częścią procesu.

W istocie projekt powinien zawierać dobrze zdefiniowane periodyczne przeglądy, służące temu, aby każdy udziałowiec miał szansę porównania swoich oczekiwań dotyczących projektu z rzeczywistymi efektami. Pozwoli to na wczesne wykrycie problemów i ich rozwiązanie.

Równie istotna w tej fazie jest przejrzystość. Każdy wygenerowany artefakt powinien być udostępniony do przejrzenia, dając każdemu z menedżerów możliwość samodzielnego zapoznania się –= we własnym tempie – z postępem prac i ocenienia go z własnego punktu widzenia. Przejrzystość pozwoli zbudować zaufanie, zaś dzięki niemu nikt nie będzie próbował przejąć „ręcznego sterowania” nad projektem, gdyż nie ma dostępu do tego, co robi nasz zespół. Brak dostępu sprzyja powstawaniu podejrzeń, a że wiele osób nie lubi żyć w nieświadomości tego, co stanie się jutro, będą próbowały zdobyć te informacje na własną rękę. Jeśli informacje będą jawnie dostępne, nie będą musiały tak często zawracać nam głowę.

Warto też pamiętać, że każdy projekt w którymś momencie wymaga pewnych poprawek czy korekt kursowych. Poprawki takie powinny być dokonywane raczej wcześniej niż później, gdyż im więcej zostanie wykonane w oparciu o błędne założenia, tym więcej trzeba będzie poprawiać później i tym trudniejsze będzie wykonanie tych poprawek. Dokonując takich zmian trzeba pamiętać o postępowaniu zgodnie z tą samą procedurą, która doprowadziła nas do tego miejsca. Zacznijmy od zapytania wszystkich udziałowców, czy wizja projektu jest nadal ta sama, czy też uległa zmianie, a jeśli tak, konieczna będzie korekta utworzonych wcześniej dokumentów, poprawienie oszacowań i dostosowanie założeń, które trzeba było poczynić. Nie należy odstępować od tej procedury nawet wówczas, gdy zmiana kursu wydaje się niewielka, gdyż wiele małych zmian w ostateczności doprowadzi nas do zupełnie innego miejsca. Jeśli nie poświęcimy czasu na ich udokumentowanie i zapewnienie komunikacji pomiędzy wszystkimi zaangażowanymi osobami, możemy w efekcie uzyskać coś, co – nawet jeśli technicznie będzie doskonałe – nie będzie mogło zostać uznane za sukces.

Alessandro Muti pełni funkcję CTO w Ascentium, firmie konsultingowej w dziedzinie technologii i interaktywnych technik cyfrowych. Pracuje w branży od 20 lat. Karierę rozpoczął w firmie Microsoft w zespole Windows. Obecnie nadzoruje dział strategii technicznych Ascentium i pomaga klientom formułować ich strategię dotyczącą prezentacji cyfrowej, prywatności, media społecznościowe, mobilności, bezpieczeństwa i wielu innych elementów, które choć z daleka wyglądają jak technologia.

Do początku strony