Czynnik ludzki w projektach wdrożeniowych

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

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

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

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.

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/.

 Tekst autorstwa Tymoteusza Radlaka pierwotnie napisany i opublikowany w E-mentor nr 4 (41) / 2011