Wprowadzenie

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.¹ projektów wdrożeniowych systemów ERP kończy się niepowodzeniem². 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

Ź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 ASA380³ opisujących wyniki analizy, możemy przeczytać: Badania wskazują, że 62 proc.⁴ 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ą⁵. 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 projektami⁶ 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, PRINCE2⁷ oraz ASAP (Accelerated SAP), pomijają aspekt psychologiczny, skupiając się na kompetencjach twardych, dostępności i kosztach. John Nicholas i Gezinus Hidding⁸ 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 roku⁹). Warto wspomnieć, iż jest to metodyka dedykowana dla projektów wdrożeniowych, bardzo mocno powiązana z rozwiązaniami technicznymi firmy SAP¹⁰. 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 PRINCE2¹¹. W oficjalnym wprowadzeniu PRINCE2¹² 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ści¹³ 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 Knowledge¹⁴, opracowany przez Project Management Institute, definiuje następujące czynniki, które kierownik projektu powinien wziąć pod uwagę przy doborze personelu¹⁵:

• 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 projektowych¹⁶.

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łu¹⁷ 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 pracy¹⁸.

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 projektowego¹⁹.

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

Ź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 engineering²⁰, 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 maleje²¹.

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 opiekun²². 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ę²³.

Rysunek 1. Destruktywne role projektowe

Ź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 - NCB²⁴ lub Project Manager Competency Development Framework - PMCD²⁵. 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 produktu²⁶ 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

• E. Kimberling, Lessons from ERP Implementation Failures, http://www.focus.com/briefs/lessons-erp-implementation-failures/.
• Panorama consulting solutions, ERP Vendor Analysis, http://panorama-consulting.com/resource-center/2010-erp-vendor-analysis/.