Czynnik ludzki w projektach wdrożeniowych

Tymoteusz Radlak

Opracowanie porusza tematykę doboru członków zespołów projektowych, przedstawioną zgodnie z wytycznymi najbardziej popularnych metodyk, takich jak PMI, ASAP oraz PRINCE2. W dalszej części autor analizuje wybrane aspekty praktyczne tego zagadnienia w konfrontacji z aktualnymi badaniami największych ryzyk projektowych oraz przedstawia wynikające z tego konkluzje.

Według różnych źródeł od 55 do 75 proc.1 projektów wdrożeniowych systemów ERP kończy się niepowodzeniem2. Biorąc pod uwagę globalną wartość rynku systemów ERP, która w roku 2010 wynosiła około 40 miliardów dolarów, pytanie o przyczyny tego stanu nabiera bardzo materialnego wymiaru i kształtuje segment usług audytorsko-konsultingowych. Najbardziej obszerne i zarazem aktualne badania przyczyn niepowodzeń projektów wdrożeniowych, do jakich udało dotrzeć się autorowi, przeprowadzone zostały przez firmę SAP AG w 2010 roku wśród 62 firm, w których wdrożono system klasy ERP.

Wykres 1. Główne przeszkody w realizacji projektów wdrożeniowych
zobacz podgląd

Źródło: opracowanie własne na podstawie: ASA380 ASAP 7.1 Implementation methodology in details, SAP AG, Waldorf 2011, s. 90

W materiałach szkoleniowych ASA3803 opisujących wyniki analizy, możemy przeczytać: Badania wskazują, że 62 proc.4 największych trudności w projektach wdrożeniowych systemów ERP związanych jest z ludźmi, gdzie najważniejsze miejsce zajmuje kwestia zarządzania zmianą5. Podobnie kwestia czynnika ludzkiego zajmuje bardzo istotne miejsce w sporządzanych przez wiele firm raportach ryzyk związanych z wdrożeniem. Jako przykład może posłużyć tu opublikowany we wrześniu 2009 roku przez firmę K2 Consulting raport Największe ryzyka wdrożeń systemów ERP. W raporcie tym na dwanaście omówionych czynników ryzyka aż pięć powiązanych jest bezpośrednio z czynnikiem ludzkim.

Paradoksalnie zatem przyczyny niepowodzeń projektów wdrożeniowych wydają się powszechnie znane, a rozwiązania zostały opisane w metodykach projektowych, z drugiej jednak strony odsetek projektów niespełniających oczekiwań wskazywać może na powszechny dysonans między teorią a praktyką. Podążając tym tropem, autor niniejszego opracowania w dalszej jego części skupi się na różnych aspektach wyboru członków zespołów projektowych, który to wybór stanowi jeden z kluczowych elementów wpływających na efektywność czynnika ludzkiego. Celem niniejszej analizy jest uzyskanie konstruktywnych wniosków płynących z konfrontacji teoretycznego oraz praktycznego podejścia do wyboru członków zespołów projektowych.

Dobór członków zespołów w świetle metodyk projektowych

Pomimo iż w literaturze poświeconej zarządzaniu projektami6 kwestia zarządzania zasobami ludzkimi zajmuje istotne miejsce, to jednak analizując szczegółowo kolejne pozycje bibliograficzne, trudno oprzeć się wrażeniu, że praca zespołów projektowych postrzegana przez pryzmat metodyk wymyka się analizie i kontroli. Kontroli jakości poddawane są efekty prac, a nie przebieg samego procesu twórczego, co może znacząco utrudniać wprowadzenie działań zapobiegawczych na czas. Kierownik projektu organizuje starannie odmierzone zasoby (środki trwałe, zasoby ludzkie i kapitałowe), następnie tworzy harmonogram, by po przewidzianym czasie otrzymać produkty kolejnych faz projektu. Celowo użyto tu zwrotu „odmierzone zasoby”, ponieważ w kwestii wyboru członków zespołów projektowych najczęściej używane do zarządzania projektami wdrożeniowymi metodyki, tj. PMI, PRINCE27 oraz ASAP (Accelerated SAP), pomijają aspekt psychologiczny, skupiając się na kompetencjach twardych, dostępności i kosztach. John Nicholas i Gezinus Hidding8 określają to podejście mianem klasycznego paradygmatu w zarządzaniu projektami.

ASAP jest metodyką stworzoną oraz rozwijaną przez firmę SAP, będącą światowym liderem na rynku oprogramowania dla dużych przedsiębiorstw (31 proc. udziału w rynku w 2010 roku9). Warto wspomnieć, iż jest to metodyka dedykowana dla projektów wdrożeniowych, bardzo mocno powiązana z rozwiązaniami technicznymi firmy SAP10. Jej najnowsza wersja oznaczona symbolem 7.1, opisana w ASAP Methodology for Implementation 7.1, wydana została oficjalnie w 2010 roku. Pomimo iż podkreślono w niej znaczenie ludzi oraz relacji międzyludzkich tworzących się w trakcie trwania projektu, ASAP nie dostarcza narzędzi lub wskazówek ułatwiających dobór członków zespołów czy też ocenę ich późniejszej pracy inaczej niż poprzez jej produkty.

Podobny obraz sytuacji kształtuje się również po zapoznaniu się z literaturą specjalistyczną z zakresu metodyki PRINCE211. W oficjalnym wprowadzeniu PRINCE212 możemy przeczytać: W projekcie potrzebne są odpowiednie osoby na odpowiednich miejscach, posiadające autorytet i wiedzę, by wziąć na siebie odpowiedzialność podejmowania decyzji na czas. Znajdziemy tam również opisy przykładowego rozbicia struktury projektu na role wraz z przypisaniem odpowiedzialności. W znakomitej większości13 opracowań poświęconych metodyce PRINCE2 pomija się jednak aspekty miękkie doboru i analizy pracy zespołu projektowego.

Tylko trochę korzystniej w tym aspekcie przedstawia się metodyka PMI. Sztandarowy podręcznik: A Guide to the Project Management Body of Knowledge14, opracowany przez Project Management Institute, definiuje następujące czynniki, które kierownik projektu powinien wziąć pod uwagę przy doborze personelu15:

  • doświadczenie - czy członkowie zespołów wykonywali w przeszłości takie same lub podobne zadania, czy im wtedy sprostali;
  • preferencje - czy członkowie zespołu chcą pracować nad danym projektem;
  • cechy osobowościowe - czy członkowie zespołów będą dobrze ze sobą współpracować;
  • dostępność - czy członkowie zespołów będą dla projektu dostępni w wymiarze godzin pozwalającym na realizację przypisanych im zadań;
  • kompetencje i umiejętności - jakie kompetencje będą potrzebne członkom zespołów projektowych oraz na jakim poziomie?
Niestety również w tym przypadku, oprócz odnotowania istnienia czynników miękkich, takich jak cechy osobowościowe czy preferencje, oficjalny podręcznik PMI nie dostarcza narzędzi pozwalających na ich analizę wśród członków zespołów projektowych16.

Miękki aspekt zarządzania związany z czynnikiem ludzkim w metodykach wdrożeniowych najczęściej postrzegany jest przez pryzmat działań związanych z zarządzaniem zmianą. Nacisk kładzie się tu głównie na budowanie zespołu17 oraz planowanie komunikacji, jednakże sam aspekt doboru członków zespołów jest w metodykach projektowych praktycznie pomijany.

Zagrożenia i konsekwencje

W firmach lub działach utworzonych z myślą o działalności projektowej kwestia doboru członków zespołów projektowych częściowo rozwiązywana jest przez dział HR, który rekrutując pracowników, uwzględnia wymagane od kandydatów specyficzne cechy charakteru oraz gotowość do pracy pod presją, w stale zmieniającym się środowisku. Sytuacja ta wygląda jednak zupełnie inaczej w przedsiębiorstwach, w których projekty należą do rzadkości. W ASAP Methodology for Implementation 7.1 problem ten opisany jest w następujący sposób: W projektach wdrożeniowych rozwiązań mysap.com personel wewnętrzny odrywany jest od swojej dotychczasowej roli w firmie, często wręcz prowadzi to do zmiany zajmowanego stanowiska. W innych przypadkach pracodawca może wymagać skrupulatnego wykonywania swoich dotychczasowych obowiązków oraz jednoczesnego udziału w pracach projektowych […] Wraz z postępem projektu początkowy zapał wygasa. Dzieje się tak między innymi z powodu znacząco zwiększonego nakładu pracy potrzebnego do wykonania zadań w przewidzianych w harmonogramie terminach. Dla personelu wewnętrznego firmy, nieprzywykłego do prac projektowych, może oznaczać to istotną zmianę w kulturze organizacyjnej i sposobie pracy18.

Postrzeganie projektu przez pryzmat dodatkowej odpowiedzialności związanej z nowymi zadaniami, przy jednoczesnym braku wsparcia kierownictwa wysokiego szczebla oraz dostatecznej motywacji, może prowadzić do tego, że personel wewnętrzny nie będzie chciał brać udziału we wdrożeniu. Sytuacja taka znacząco zwiększa opór przed zmianą i utrudnia wprowadzanie nowych rozwiązań.

W obliczu konieczności skompletowania zespołów, a zarazem braku odpowiednich kandydatów, zwiększa się ryzyko rekrutacji „z łapanki”, czyli odwrócenia pytania „dlaczego ta właśnie osoba?” do postaci „dlaczego nie on czy ona?” i doboru osób o niewystarczającej wiedzy, kompetencjach lub mocy decyzyjnej. Dodatkowym czynnikiem utrudniającym identyfikację błędów w doborze członków zespołów projektowych jest fakt, iż konsekwencje tej decyzji widoczne są dopiero po realnym rozpoczęciu prac, czyli z dużym opóźnieniem.

Jak bardzo poważne skutki dla projektu niesie za sobą błędny dobór członków zespołów projektowych, pokazują cytowane uprzednio badania przeprowadzone przez firmę SAP. Wynika z nich, że aż 62 proc. trudności w projektach wdrożeniowych systemów ERP związanych jest z ludźmi, z czego 42 proc. wynika z błędów w zarządzaniu zmianą, przygotowaniu i przeszkoleniu personelu wewnętrznego oraz pracy członków zespołu projektowego19.

Wykres 2. Trudności projektowe związane z czynnikiem ludzkim
zobacz podgląd

Źródło: opracowanie własne na podstawie: ASA380 ASAP 7.1 Implementation methodology in details, dz.cyt., s. 90

Tymczasem błędny wybór personelu może okazać się niezwykle trudny do skorygowania, głównie z powodu ogromnej ilości wiedzy, którą członkowie zespołów nabywają w trakcie całego procesu. Co więcej, zwiększenie liczby zaangażowanych w projekt zasobów w trakcie jego trwania, jak dowodzi Frederick P. Brooks w swojej klasycznej już pozycji The mythical man-month: essays on software engineering20, nie musi oznaczać przyspieszenia tempa prac. Nie każdy wierzy, że dokładanie zasobów do projektów w istocie mu pomaga. Brooks stworzył swoje tezy na postawie doświadczeń z pracy nad systemem operacyjnym dla IBM serii 360. Wspomina, że dokładanie zasobów do projektu w późnym stadium zaawansowania jedynie go opóźnia. Brooks, formułując swą tezę, miał na myśli jedynie opóźnienia w projektach informatycznych, dziś jednak stosuje się ją w odniesieniu do wszystkich typów projektów. Teza opiera się na zasadzie mówiącej, że gdy do projektu przybywają nowi członkowie, osoby w niego zaangażowane poświęcają czas na uczenie ich oraz wprowadzanie w standardy działania. Powoduje to, iż w efekcie efektywność pracy zespołu maleje21.

Konflikt i współpraca

Bardziej szczegółowe wskazówki odnośnie doboru członków zespołów projektowych, a tym samym ciekawą typologię rodzajów osobowości wspierających oraz hamujących prace projektowe, przedstawił Harold Kerzner w książce zatytułowanej: Project Management - A Systems Approach to Planning, Scheduling, and Controlling. Podzielił on typy osobowościowe pod względem ich miejsca w zespołach projektowych na role pozytywne i destruktywne. Wśród ról pozytywnych znalazły się: inicjator, poszukiwacz informacji, informator, motywator, osoba wyjaśniająca, koordynator, poszukiwacz konsensusu oraz opiekun22. Role destruktywne według Kerznera to agresor, dominator, adwokat diabła, osoba zmieniająca tematy, poszukiwacz uznania, osoba wycofująca się, osoba wstrzymująca się23.

Rysunek 1. Destruktywne role projektowe
zobacz podgląd

Źródło: opracowanie własne na podstawie: H. Kerzner, Project Management - A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, Londyn 2001, s. 262

Powyższy podział z pozoru wydaje się klarowny i intuicyjny. Jednostki o typach osobowości wspierających prace projektowe powinny znaleźć się w zespołach, zaś jednostki je blokujące powinny być od prac odsuwane. Przyjmujemy tu jednak założenie, że obie strony rozumieją konieczność współdziałania i współpracy wszystkich grup interesów w imię wspólnego dobra. Tymczasem głęboko zakorzeniony w projektach, w tym w szczególności w projektach wdrożeniowych, konflikt zarówno na poziomie wykonawca - klient, jak i na poziomie działów wewnątrz firmy, sprawić może że dominująca stanie się nie perspektywa współpracy, lecz perspektywa roszczeniowa, w wyniku czego nawet destruktywne dla projektu typy osobowości znajdują racjonalne uzasadnienie swojego w nim udziału.

W tabeli 1 przedstawiono zestawienie interpretacji wybranych typów osobowości z obu perspektyw.

Tabela 1. Wybrane typy osobowości w perspektywach współpracy i roszczeniowej
Typ osobowości Cechy Perspektywa współpracy Perspektywa roszczeniowa
Agresor Łatwo inicjuje i eskaluje sytuacje konfliktowe. Otwarcie krytykuje wszystkich członków projektu o odmiennym niż on zdaniu. Negatywnie wpływa na atmosferę pracy. Jego obecność prowadzi do utraty zaufania między członkami zespołów. Nie pozwala pominąć wymagań. Dobrze dba o interesy firmy, działu. Nie da się zastraszyć.
Osoba zmieniająca tematy Wstrzymuje finalizację działań. Otwiera i prowadzi wiele tematów jednocześnie. Zmienia temat dyskusji, blokując ustalenie rozwiązań. Negatywnie wpływa na tempo pracy. Paraliżuje łańcuch decyzyjny. Dba o realizację wszystkich wymagań. Uzyskuje dodatkowy czas na przemyślenie lub wprowadzenie zmian przed zatwierdzeniem prac.
Osoba wstrzymująca się Lubi krytykować i narzekać. Z definicji odrzuca lub wstrzymuje realizację rozwiązań. Negatywnie wpływa na tempo oraz atmosferę pracy. Będzie bronił status quo. Nie pozwoli na wdrożenie czegoś, co nie jest naprawdę dobre.

Źródło: opracowanie własne

Warto tu nadmienić, iż przyjęcie przez jednostkę perspektywy współpracy lub perspektywy roszczeniowej może zmieniać się w czasie w zależności od skuteczności działań związanych z zarządzaniem zmianą.

Konkluzje

Dzięki badaniom opartym na analizie powdrożeniowej oraz identyfikacji ryzyk dysponujemy dziś informacjami, które pozwalają precyzyjnie określić przyczyny niepowodzeń projektów wdrożeniowych. Jako jeden z kluczowych czynników ryzyka wymieniane są tu problemy związane z zarządzaniem czynnikiem ludzkim, w tym w szczególności z zarządzaniem zmianą.

Kwestie te poruszane są co prawda w najpopularniejszych metodykach projektowych, takich jak ASAP, PMI czy PRINCE2, jednakże brak w nich wskazówek pozwalających w łatwy sposób przełożyć teorię na działanie. Winą za taki stan rzeczy trudno jednak obarczać same metodyki, w literaturze specjalistycznej istnieją bowiem modele oceny kompetencji miękkich. Przykładem tego mogą być: National Competence Baseline - NCB24 lub Project Manager Competency Development Framework - PMCD25. Kwestia ich niewielkiej popularności, a zarazem marginalizacja tematu czynnika ludzkiego w projektach wydaje się raczej konsekwencją dominacji paradygmatu […] który definiuje projekt jedynie poprzez spełnienie celów związanych z harmonogramem, budżetem i dostarczeniem produktu26 niż niedostępnością wiedzy lub brakiem badań naukowych w tym temacie.

Bibliografia

  • A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition, Project Management Institute Inc., Newtown Square 2004.
  • E.S. Andersen, K. Grude, T. Haug, Goal directed project management: effective techniques and strategies, Kogan Page Limited, Londyn 2009.
  • ASA380 ASAP 7.1 Implementation methodology in details, SAP AG, Waldorf 2011.
  • ASAP Methodology for Implementation 7.1 - Roadmap WBS 1.2.4 Project Team Building, Team management Guide, SAP AG, Waldorf 2010.
  • F.P. Brooks, The mythical man-month: essays on software engineering, Addison-Wesley, Reading 1995.
  • J. Charvat, Project management nation. Toools, Techniques, Goals for the New and practicing IT Project manager, John Wiley & Sons, Londyn 2002.
  • K. Harold, Project Management - A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, Londyn 2001.
  • K. Heldman, PMP Project Management Professional Study Guide, Sybex, San Francisco 2002.
  • Managing successful projects with PRINCE2, CCTA (Central Computers & Telecommunications Agency), Londyn 1999.
  • PRINCE2, OCG (Office of Government Commerce), Londyn 2002.
  • C. Pritchard, The Project Management Communications Toolkit, Artech House, Londyn 2004.
  • L.F. Terry, C.S. Guynes, V.R. Prybutok, J. Windsor, Maintaining quality in information systems, „The Journal of Computer Information Systems” 1999, nr 5.
  • P. Wachowiak, G. Sylwester, B. Grucza, K. Ogonek, Kierowanie zespołem projektowym, Warszawa, Difin 2004.

Netografia

Informacje o autorze

zobacz podgląd
TYMOTEUSZ RADLAK

Autor jest absolwentem Uniwersytetu Warszawskiego na kierunku Etnologia i antropologia kulturowa oraz Szkoły Głównej Handlowej w specjalizacji Metody Ilościowe i systemy informacyjne. W swej pracy naukowej zajmuje się miękkimi aspektami zarządzania dużymi przedsięwzięciami informatycznymi, w tym między innymi: zarządzaniem zmianą, komunikacją, optymalizacją procesów biznesowych, zarządzaniem wartością.

Komentarze

Nie ma jeszcze komentarzy do tego artykułu.

dodaj komentarz dodaj komentarz

Przypisy

1 J. Nicholas, G. Hidding, Management Principles Associated With IT Project Success, „International Journal of Management and Information Systems” 2010, nr 14, s. 147-156.

2 Niepowodzenie projektu rozumiane jest w tekście jako niespełnienie przez projekt stawianych mu oczekiwań, czy to względem harmonogramu, budżetu, czy jakości rozwiązania.

3 ASA380 ASAP 7.1 Implementation methodology in details, SAP AG, Waldorf 2011.

4 Wśród wymienionych w raporcie czynników znajdują się również: proces - 16 proc., technologia - 9 proc., zasoby wiedzy - 3 procent.

5 ASA380 ASAP 7.1 Implementation methodology in details, dz.cyt., s. 90.

6 J. Charvat, Project management nation. Tools, Techniques, Goals for the New and practicing IT Project manager, John Wiley & Sons, London 2002, s. 37; K. Heldman, PMP Project Management Professional Study Guide, Sybex, San Francisco 2002, s. 249; C. Pritchard, The Project Management Communications Toolkit, Londyn, Artech House 2004, s. 89; P. Wachowiak, G. Sylwester, B. Grucza, K. Ogonek, Kierowanie zespołem projektowym, Warszawa, Difin 2004.

7 Nazwa metodyki pochodzi od angielskiego zwrotu Projects In a Controlled Environment.

8 J. Nicholas, G. Hidding, dz.cyt.

9 Panorama consulting solutions, 2010 ERP Vendor Analysis, panorama-consulting.... [20.09.2010].

10 W tym w szczególności aplikacja Solution Manager, jako platforma służącą do kompleksowej obsługi projektu wdrożeniowego.

11 PRINCE2, OCG (Office of Government Commerce), Londyn 2002; Managing successful projects with PRINCE2, CCTA (Central Computers & Telecommunications Agency), Londyn 1999.

12 PRINCE2, OCG, Londyn 2002, s. 31.

13 Kwestia zarządzania czynnikiem ludzkim przedstawiona została bliżej w pozycji Office of Government Commerce: People issues and PRINCE2, OCG, Londyn 2002.

14 A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition, Project Management Institute Inc., Newtown Square 2004.

15 Tamże, s. 113.

16 O ocenie kompetencji oraz cech osobowości kierowników projektów szerzej traktuje Project Manager Competency Development Framework (PMCD). Por. Project Manager Competency Development Framework, Project Management Institute Inc., Newtown Square 2002.

17 Termin team building używany jest na określenie działań związanych z budowaniem relacji między członkami zespołu i nie odnosi się do samego procesu kompletowania zespołu, jak mogłoby sugerować polskie tłumaczenie.

18 SAP AG, ASAP Methodology for Implementation 7.1 - Roadmap WBS 1.2.4 Project Team Building, Team management Guide, SAP AG, Waldorf 2010, s. 1-2.

19 ASA380 ASAP 7.1 Implementation methodology in details, dz.cyt., s. 90.

20 F. P. Brooks, The mythical man-month: essays on software engineering, Addison-Wesley Professional, Boston 1995.

21 E.S. Andersen, K. Grude, T. Haug, Goal directed project management: effective techniques and strategies, Kogan Page Limited, Londyn 2009, s. 125.

22 Initiator, information seeker, information giver, encourager, clarifier, harmonizer, consensus taker, gate keeper.

23 Aggressor, dominator, devil's advocate, topic jumper, recognition seeker, withdrawer, blocker.

24 Stowarzyszenie Project Management Polska, Polskie Wytyczne Kompetencji IPMA, www.spmp.org.pl/cer.... [20.09.2010].

25 Project Manager Competency Development Framework, dz.cyt.

26 J. Nicholas, G. Hidding, dz.cyt., s. 147-156.