Podsumowanie

W niniejszym rozdziale zaprezentowano trzy podstawowe zagregowane zmienne, które powinny być uwzględniane przez menedżerów projektów podczas podejmowania decyzji dotyczących doboru metody zarządzania projektem. Dobór ten będzie tylko wtedy efektywny, gdy kierownik dokona analizy dojrzałości klienta, dla którego projekt jest realizowany, analizy dojrzałości własnego zespołu, który ma realizować projekt, oraz analizy entropii projektu. Te trzy zmienne zaprezentowane w niniejszym rozdziale układają się w nowy trójkąt ograniczeń. Analogicznie do klasycznego trójkąta ograniczeń składającego się z harmonogramu, budżetu i zakresu projektu, w niniejszym rozdziale wyodrębniono trójkąt składający się z dojrzałości klienta, dojrzałości zespołu i entropii projektowej.

Oznacza to zatem, że w zależności od wartości tych zmiennych powinna być dobierana metoda zarządzania projektem lub poszczególne dobre praktyki zarządzania projektem. Jednakże określenie poziomów wartości tych zmiennych wymaga zastosowania odpowiednich instrumentów pomiarowych, dlatego zostały one również zaprezentowane w niniejszym rozdziale. Jeżeli kierownikom projektów uda się pomierzyć tak ważne parametry jak dojrzałość klienta, dojrzałość zespołu i entropia projektu, ryzyko niedopasowania metody lub dobrych praktyk będzie zminimalizowane. Największym problemem dla kierowników projektów związanym z wymienionymi zmiennymi decyzyjnymi jest ich pomiar. Nie każdy kierownik projektu będzie w stanie samodzielnie dokonywać szeregu analiz stanu swoich projektów, a tym bardziej wyciągać wnioski z tej analizy pozwalające mu na efektywny dobór metody zarządzania projektem. Stąd też uznano, że należy opracować formalne rozwiązanie, które pozwoli na analizę tych zmiennych i dobór metody lub dobrych praktyk do specyfiki danego projektu. Takim rozwiązaniem powinien być odpowiedni model zarządzania projektem informatycznym.

Wydaje się zatem, że opracowując model zarządzania projektami informatycznymi należy uwzględnić w nim wszystkie problemy związane z doborem metod i dobrych praktyk zarządzania projektem omówione w rozdziale I, jak również zagadnienia zmiennych decyzyjnych zaprezentowane w tym rozdziale. Podstawowym wnioskiem płynącym z analizy tych dwóch głównych zagadnień (czyli doboru metod i dobrych praktyk zarządzania projektami do danego projektu oraz analizy nowego trójkąta ograniczeń) jest to, że należy opracować taki model zarządzania projektem informatycznym, który będzie uwzględniał owe zagadnienia. Stąd też zrodziła się koncepcja opracowania adaptacyjnego agentowego modelu zarządzania projektem informatycznym, którego nadrzędnym zadaniem będzie dokonywanie pomiaru wartości zmiennych w nowym trójkącie ograniczeń oraz dopasowywanie dobrych praktyk zarządzania projektami w oparciu o te ograniczenia.

Założenia do budowy takiego modelu zostały przedstawione w rozdziale III.

3 Rozdział III

Założenia do budowy adaptacyjnego agentowego modelu zarządzania projektami informatycznymi

Na podstawie wniosków wyciągniętych z analiz przeprowadzonych w dwóch poprzednich rozdziałach zauważono brak sformalizowanych rozwiązań pozwalających kierownikom projektów informatycznych dobierać dobre praktyki zarządzania projektami w zależności od struktury projektowej oraz zmiennych decyzyjnych nowego trójkąta ograniczeń. W poprzednich dwóch rozdziałach zauważono również, że podejmowanie decyzji przez kierowników projektów informatycznych odnośnie tego, które dobre praktyki zarządzania projektem stosować, jest problemem bardzo złożonym. Uznano więc, że po dekompozycji metod zarządzania projektami do postaci dobrych praktyk oraz przyjęciu założenia, że kierownicy projektów powinni dobierać pojedyncze dobre praktyki w miejsce całych metod zarządzania projektami, należy opracować model, który będzie wspierał kierowników w doborze dobrych praktyk do projektów. Uznano również, że z uwagi na fakt, że stosowanie metod zarządzania projektami okazuje się nieefektywne, należy opracować taki model, który umożliwi adaptowanie dobrych praktyk w zależności od wartości zmiennych decyzyjnych nowego trójkąta ograniczeń. W związku z tym zrodziło się pytanie, jak wspomagać dobieranie tych dobrych praktyk przez kierowników projektów. Zgodnie z teorią zarządzania mówiącą, że jedną z głównych cech dobrego menedżera jest posiadanie odpowiedniej intuicji, wydawałoby się, że sama znajomość dobrych praktyk przez kierownika projektu będzie wystarczająca do ich dopasowywania do projektu. Jednak aktualny stan wiedzy o zarządzaniu projektami informatycznymi wskazuje, że podejmowanie decyzji kierowniczych w projektach informatycznych jest zagadnieniem na tyle złożonym, że nie powinno opierać się wyłącznie na intuicji. Potwierdza to także rozwój metod zarządzania projektami, ich ciągłe ewolucje, jak również pojawianie się nowych metod zarządzania projektami oraz narzędzi informatycznych wspierających kierowników w działaniu. Podejmowanie decyzji co do sposobu kierowania projektem w oparciu o dobre praktyki powinno być więc wsparte odpowiednim rozwiązaniem formalnym. Uznano zatem, że należy opracować taki model zarządzania projektem informatycznym, który będzie łączył zarówno problematykę pomiaru zmiennych decyzyjnych (nowego trójkąta ograniczeń), jak również problematykę doboru (adaptacji) dobrych praktyk zarządzania projektami informatycznymi w zależności od tych zmiennych decyzyjnych.

Celem niniejszego rozdziału jest zatem omówienie podstawowych założeń do budowy takiego modelu. W rozdziale niniejszym zaprezentowano ogólną koncepcję modelu zarządzania projektami informatycznymi, przedstawiono możliwe podejścia do budowy modelu oraz wybrano podejście najbardziej odpowiadające koncepcji wsparcia kierowników projektów informatycznych w doborze dobrych praktyk do ograniczeń projektowych. W rozdziale omówiono również metodę prowadzenia badań nakierowanych na powstanie adaptacyjnego agentowego modelu zarządzania projektami, którego opracowanie jest głównym celem niniejszej rozprawy. Badania prowadzące do powstania ostatecznej wersji modelu przedstawiono w postaci etapów rozwojowych, które kończyły się stworzeniem pośrednich instancji modelu określonych mianem submodeli.

3.1 Koncepcja budowy modelu

Zaobserwowany wcześniej problem stosowania metod zarządzania projektami i dobrych praktyk w nich zawartych skłonił do podjęcia badań nad poszukiwaniem modelu pozwalającego usprawniać zarządzanie projektami informatycznymi. Uznano, że w celu wsparcia kierowników projektów informatycznych odnośnie doboru dobrych praktyk zarządzania projektami do ograniczeń

projektowych (wynikających z uprzednio zdefiniowanego nowego trójkąta ograniczeń) należy opracować model agentowy. Podjęto decyzję o konieczności budowy właśnie modelu, a nie typowej metody zarządzania projektami z dwóch powodów. Po pierwsze model jest pojęciem bardziej ogólnym, przez co możliwe jest integrowanie większej liczby elementów, które są istotne z punktu widzenia zarządzania projektami informatycznymi. Drugim powodem skłaniającym do poszukiwania właśnie modelu, a nie metody, jest wniosek płynący z prezentacji narzędzi informatycznych wykorzystywanych w zarządzaniu projektami informatycznymi (dokonany w rozdziale I). Skoro bowiem narzędzie informatyczne jest nieodłącznie związane z pracą kierowników projektów, opracowując model można dokonać późniejszej jego implementacji właśnie w przykładowym narzędziu, dając w ten sposób kierownikom dodatkowe wsparcie przy podejmowaniu decyzji w projekcie. Zgodnie z obecnym podejściem architektur MDA (ang. Model Driven Architecture) [10,59] jeżeli model odzwierciedla cechy narzędzia i metody, jest niezależny od środowiska implementacji i może być zastosowany w dowolnym środowisku. Tworząc model, a nie metodę, tworzone jest rozwiązanie o charakterze uniwersalnym.

Droga do opracowania adaptacyjnego agentowego modelu zarządzania projektami została poprzedzona analizą dziedzinową. Analiza dziedzinowa rozumiana jest jako badanie stanu 12 projektów informatycznych, w których autor miał okazję uczestniczyć. Dodatkowo analizę tę uzupełniały spostrzeżenia innych kierowników projektów informatycznych, którzy podczas zogniskowanych wywiadów dzielili się swoimi doświadczeniami zdobytymi podczas realizacji własnych projektów informatycznych. Obserwacje płynące z uczestnictwa w wymienionych projektach oraz wiedza zdobyta na podstawie wywiadów z kierownikami projektów pozwoliły na określenie kierunku prac badawczych. Przed zaprezentowaniem ostatecznej koncepcji adaptacyjnego agentowego modelu zarządzania projektami informatycznymi postanowiono więc przedstawić także efekty (produkty) pośrednie prowadzonych badań, zwane submodelami. Każdy bowiem submodel pozwalał na zdobycie doświadczeń prowadzących do powstania ostatecznej wersji modelu. Zarówno przy pracach koncepcyjnych (prototypowanie), jak również przy opracowaniu ostatecznej wersji adaptacyjnego agentowego modelu zarządzania projektami informatycznymi (prezentowanego w rozdziale następnym), przyjęto metodę badawczą przedstawioną na rysunku 3.1.

Rys. 3.1 Metoda prowadzenia badań dla uzyskania modelu Źródło: opracowanie własne

Jak wynika z rysunku 3.1, punktem wyjścia do prowadzonych badań były wyniki obserwacji poczynionych podczas uczestniczenia w realizowanych projektach informatycznych. Na obserwacje składały się trzy podstawowe działania. Pierwsze stanowiły zogniskowane badania prowadzone z uczestnikami projektów, podczas których autor zadawał pytania istotne z punktu widzenia zarządzania projektami. Drugim źródłem pozyskiwania wiedzy były wywiady prowadzone z menedżerami projektów (głównie podczas konferencji branżowych i spotkań biznesowych). Jako, że jednostka naukowo-badawcza jaką jest Zakład Zarządzania Technologiami Informatycznymi, w której pracuje autor niniejszej rozprawy, współpracuje z wieloma korporacjami informatycznymi (jak IBM Polska, HP Polska czy Intel Polska) oraz organizacjami z innych branż, ale realizujących szereg projektów informatycznych na własne potrzeby (np. GE Money Bank), wywiady przeprowadzano głównie z kierownikami projektów informatycznych realizowanych w tych firmach. Dzięki temu

Założenia do budowy adaptacyjnego agentowego modelu zarządzania projektami informatycznymi (rozdział III)

Adaptacyjny agentowy model zarządzania projektami informatycznymi (rozdział IV)

zgromadzona została wiedza na temat specyfiki prowadzenia projektów przez tych kierowników oraz wiedza o podstawowych problemach tych firm. Dodatkowo, w celu uzupełnienia wiedzy o projektach realizowanych w mniejszych firmach, zasięgnięto opinii kierowników projektów z niedużych firm świadczących usługi informatyczne.

Trzecim źródłem pozyskiwania wiedzy były własne doświadczenia autora płynące z realizacji trzech projektów informatycznych (m.in. na potrzeby firmy sektora energetycznego oraz projektu finansowanego przez Ministerstwo Nauki i Szkolnictwa Wyższego w ramach grantu badawczego).

Ten zbiór wiedzy oparty na wywiadach i własnych doświadczeniach (zgodnie z rysunkiem rys.

3.2) stanowił punkt wyjścia do opracowywania modelu pozwalającego wspomagać menedżerów projektów informatycznych w obszarze podejmowania decyzji co do metod zarządzania projektami oraz tworzenia poprawnych struktur projektowych.

Rys. 3.2 Źródła wiedzy o projektach informatycznych wykorzystane w opracowaniu modelu a2M Źródło: opracowanie własne

Po zgromadzeniu odpowiedniej wiedzy o realizowanych projektach (w ramach obserwacji) zgodnie z przyjętą metodą badawczą (rys. 3.1) przystąpiono do opracowywania submodeli.

Submodele poddawano weryfikacji poprzez dedykowane im eksperymenty przeprowadzane w określonym, uprzednio zdefiniowanym środowisku. Po każdym z eksperymentów wyciągano wnioski oraz uogólnienia pozwalające na tworzenie kolejnego submodelu zgodnie z podejściem iteracyjnym (rys. 3.1). Poniżej omówione zostały poszczególne etapy rozwojowe począwszy od analizy dziedzinowej, poprzez kolejne etapy prowadzące do tworzenia prototypów (submodeli).

Każdy prototyp stanowił kolejne przybliżenie do opracowania adaptacyjnego agentowego modelu zarządzania projektami informatycznymi.

3.2 Analiza dziedzinowa

Podczas przeprowadzania obserwacji rzeczywistych projektów informatycznych gromadzono wiedzę o metodach zarządzania i dobrych praktykach kierowników projektów informatycznych (podobnie jak wykonano to w rozdziale I). Proces przetwarzania wiedzy (na potrzeby budowy modelu) został określony mianem analizy dziedzinowej. Analiza dziedzinowa stanowi zatem pierwszy etap rozwojowy budowy modelu wspomagającego zarządzanie projektami informatycznymi.

Pozostałe etapy omówione w dalszej części prowadziły do powstania poszczególnych modeli pośrednich, sprowadzając modele do postaci systemu agentowego realizującego zamodelowane funkcjonalności.

Analiza dziedzinowa stanowiła więc podstawowy etap badań nad problematyką projektów informatycznych, w efekcie których rozpoczęto opracowywanie submodeli prowadzących do powstania późniejszego adaptacyjnego agentowego modelu zarządzania projektami informatycznymi.

Zgromadzona uprzednio wiedza dotycząca problemów kierowników w zarządzaniu projektami informatycznymi (wykorzystywania dobrych praktyk zarządzania projektami) posłużyła w tym etapie do zdefiniowania zagregowanych zmiennych dojrzałości klienta i dostawcy oraz entropii projektu.

Zmienne te wraz z opisami zostały zaprezentowane na rysunku 3.3. Do opisu poszczególnych zmiennych posłużono się odpowiednimi przykładami zaczerpniętymi z rzeczywistych projektów informatycznych.

GRUPY PROBLEMÓW KIEROWNIKÓW W ZARZĄDZANIU PROJEKTAMI INFORMATYCZNYMI

Chaos informacyjny

Zmienność wymagań Zarządzanie

zespołem

Entropia projektu

Dojrzałość zespołu

Dojrzałość klienta

NOWY TRÓJKĄT OGRANICZEŃ

Rys. 3.3 Transformacja głównych problemów w projektach na zmienne decyzyjne Źródło: opracowanie własne

Poniżej omówiono podstawowe problemy związane ze zmiennymi decyzyjnymi wchodzącymi w skład nowego trójkąta ograniczeń.

Grupa problemów związanych z chaosem informacyjnym w projektach a entropia projektu

Jednym z podstawowych problemów wskazywanych podczas rozmów przez kierowników projektów okazał się być chaos informacyjny. Zwrócono uwagę, że największe nieuporządkowanie

informacji występuje z reguły przed rozpoczęciem projektu. Niektórzy kierownicy projektów informatycznych przyznali, że oczekuje się od nich rozpoczęcia prac projektowych przy niewystarczającej liczbie danych dotyczących projektu. Ten niewystarczający poziom informacji dotyczył zarówno celów, jakie stawiano zespołowi realizującemu projekt, jak również specyfiki produktu, jaki miał powstać w wyniku prac projektowych. Poniższe przykłady zaprezentowano w celu potwierdzenia tezy, że chaos informacyjny można uznać za jedną z głównych grup problemów, z jakimi borykają się kierownicy projektów i że chaos informacyjny przekłada się na entropię projektu informatycznego.

Przykład 3. Brak jasno wyznaczonych celów projektu a zarządzanie zespołem Projekt: Integracja technologii Rational

Klient: IBM

Zespoły: studenci ostatniego roku studiów, specjalności Zarządzanie Technologiami Informatycznymi,

Termin realizacji: kwiecień 2010–lipiec 2011

W ramach tego projektu powołano kilka niezależnych zespołów projektowych. Każdy zespół zajmował się możliwościami integracyjnymi innych narzędzi z rodziny Rational. Na początku projektu jego cel nie był jasny dla członków zespołów projektowych. Wynikało to między innymi z faktu, że pojęcie integracji nie zostało dokładnie sprecyzowane (nie było wiadomo, czy integracja ma następować na poziomie danych, czy na wyższym poziomie analizowanych narzędzi). Członkowie zespołów nie umieli tym samym określić zadań analitycznych (związanych z rozpoznawaniem technologii) i zwracali uwagę na duży dyskomfort spowodowany brakiem wizji ostatecznego celu projektu. Menedżerowie prowadzący ten projekt również nie potrafili precyzyjnie tych celów wskazać. Zarys finalnego produktu projektu integracji był co prawda przedstawiony (technologie miały być zintegrowane w cyklu wytwarzania oprogramowania), ale uczestnicy projektu nie potrafili dokładnie zrozumieć, jak ma ten finalny produkt wyglądać. Brak wystarczających danych o celach realizowanego projektu przyczynił się do dużego zniechęcenia i spadku poziomu motywacji wśród wykonawców (niektórzy członkowie zespołu chcieli się wycofać z realizacji zadań). Na podstawie tego przykładu okazuje się, że niedobór informacji rodzi szereg problemów zarówno dla osób kierujących projektami, jak również dla wykonawców, a planowanie zadań w warunkach niskiego poziomu informacji jest znacznie utrudnione.

Podsumowanie:

 projekt o niskim stopniu precyzji sformułowania wymagań,

 projekt o niskim stopniu pewności zdefiniowanego zakresu projektu,

 projekt o wysokim stopniu złożoności zadań projektowych,

 projekt o wysokim ryzyku wykonawczym.

Ocena: Projekt o wysokiej entropii.

Przykład 4. Wpływ nadmiaru informacji na realizację zadań w projekcie informatycznym

Klient: Politechnika Gdańska Dostawca: ZETO Olsztyn

Projekt: wdrożenie aplikacji webowej do zarządzania publikacjami naukowymi Termin realizacji: styczeń-kwiecień 2010

Drugim przykładem obrazującym problematykę chaosu informacyjnego jest obserwacja poczyniona podczas uczestnictwa w projekcie realizowanym na potrzeby jednej z uczelni wyższych.

Celem projektu było wytworzenie systemu wspomagającego zarządzanie publikacjami naukowymi i ich udostępnianie środowisku biznesowemu. Jednym z podstawowych problemów związanych z realizacją zadań w tym projekcie był nadmiar informacji. Prace nie były wykonywane terminowo głównie ze względu na różnorodność informacji (często sprzecznych) napływających do osób wytwarzających system. Informacje napływały z dwóch źródeł umiejscowionych na różnych szczeblach w strukturze organizacyjnej, przez co wykonawcy nie byli w stanie określić, które informacje są ważniejsze. Stąd też nadmiarowość i nieuporządkowanie informacji stanowiło również problem dla kierowników projektów oraz wykonawców zadań w projekcie. Napływ nowych informacji z różnych źródeł stanowił w omawianym projekcie poważne wyzwanie dla kierownika projektu, który zmuszony był do porządkowania zadań dla swojego zespołu wykonawców. W sytuacji, w której informacje są niepełne, nieprecyzyjne i występują w bardzo dużej ilości, wyłonienie informacji kluczowych z punktu widzenia produktu stało się poważnym problemem dla menedżerów.

Podsumowanie:

 projekt o niskim stopniu precyzji sformułowania wymagań,

 projekt o niskim stopniu pewności zdefiniowanego zakresu projektu,

 projekt o średnim stopniu złożoności zadań projektowych,

 projekt o średnim ryzyku wykonawczym.

Ocena: Projekt o średniej entropii.

Na podstawie powyższych przykładów można stwierdzić, że brak analizy poziomu entropii własnego projektu przez menedżera projektu zazwyczaj skutkuje negatywnie z punktu widzenia realizacji zadań. Łatwo zauważyć więc, że jednym z kluczowych działań, jakie musi przeprowadzić kierownik projektu, jest zmniejszenie albo przynajmniej określenie poziomu entropii projektowej poprzez np. uporządkowanie informacji niezbędnych do realizacji projektu.

Grupa problemów związanych z funkcjonowaniem zespołu a dojrzałość zespołu dostawcy

Drugim ważnym problemem związanym z realizacją projektów informatycznych jest problem budowy zespołu realizującego projekt — zespołu dostawcy. Problem ten wpisuje się w klasyczny dla nauk o zarządzaniu problem zarządzania zasobami ludzkimi. Jednakże w przypadku projektów informatycznych nabiera szczególnego znaczenia. Jak wspomniano w rozdziale I, zespoły w projektach informatycznych charakteryzują się tym, że występuje w nich wyraźne rozróżnienie ról i wąska specjalizacja zadań. Stąd też dobór członków zespołu projektowego, zbudowanie poprawnych relacji pomiędzy tymi członkami oraz zapewnienie właściwej komunikacji stanowią podstawowe wyzwanie dla menedżerów projektów informatycznych.

Przykład 5. Wpływ dojrzałości zespołu na realizację zadań w projekcie informatycznym Projekt: Integracja technologii IBM Clear Case oraz IBM Clear Quest

Klient: Avnet

Zespoły: studenci ostatniego roku studiów specjalności Zarządzanie Technologiami Informatycznymi, Termin realizacji: 2009–2010

W projekcie dotyczącym zastosowania technologii IBM Clear Case oraz IBM Clear Quest do wspomagania zarządzania incydentami w oprogramowaniu klienta projektu wystąpiła konieczność integracji tych technologii z innymi technologiami wykorzystywanymi u klienta. W trakcie obserwacji

zespołów realizujących projekt zwrócono uwagę na wyraźne problemy dotyczące komunikacji pomiędzy członkami zespołu. W projekcie powołano trzy zespoły . Zespoły te miały zorganizować swoją pracę poprzez odpowiedni podział zadań. Powołane zespoły składały się z osób o małym doświadczeniu projektowym. Efektem takiego podejścia było to, że na samym początku realizacji projektu zaobserwowano problemy z podziałem zadań pomiędzy poszczególnych członków. Liderzy zespołów nie potrafili jasno zdefiniować zadań i zlecić ich wykonania pozostałym członkom zespołu.

Kontrola przeprowadzona po kilku tygodniach od uruchomienia projektu pokazała, że prace projektowe nie są realizowane terminowo. Podczas wywiadów z członkami zespołów najczęściej zwracano uwagę na niski poziom komunikacji pomiędzy liderami a pozostałymi członkami, przez co wykonawcy zadań nie do końca wiedzieli, co powinni zrobić. Liderzy natomiast zapytani o sposób prowadzenia prac, czyli o zastosowaną metodę zarządzania projektem (wcześniej byli szkoleni z formalnych metod zarządzania projektami), wskazali na problem dopasowania takiej metody do swoich zespołów. Po spotkaniu kontrolnym z liderami włączono do projektu dwie osoby z większym doświadczeniem w zarządzaniu projektami, które pomogły liderom w doprecyzowaniu zadań dla poszczególnych członków. Od tego momentu prace były realizowane terminowo. Podobna obserwacja potwierdziła się również w kilku innych badanych zespołach projektowych, gdzie uczestnicy z niewielkim stażem projektowym mieli zazwyczaj duże problemy z właściwym definiowaniem zadań, a młodzi menedżerowie nie potrafili dobrać metody zarządzania projektami, co znacznie utrudniało realizację zadań projektowych.

Dalsze obserwacje wynikające z udziału w projektach informatycznych pokazały, że na podobne problemy, jak opisane w przykładzie piątym, zwraca uwagę większość menedżerów IT, z którymi prowadzono wywiady. Nie oznacza to oczywiście, że zespoły złożone z niedoświadczonych członków nie powinny realizować projektów informatycznych. Ważne jest jednak, aby w zależności od poziomu dojrzałości zespołu dostawcy dopasowywać dobre praktyki zarządzania oraz zapewnić odpowiednią organizację zespołu — czyli taki podział ról, który odpowiada kompetencjom i poziomowi doświadczenia poszczególnych członków. Ta obserwacja pokazała również, że poziom dojrzałości zespołu powinien być uwzględniany podczas tworzenia zespołów projektowych i w zależności od tego poziomu menedżerowie powinni dobierać dobre praktyki zarządzania projektem. Wydaje się również słuszne, aby poziom dojrzałości zespołu dostawcy poddawać stałej kontroli, a zespoły powinny dobierać sposoby realizacji prac projektowych w zależności od poziomu swojej dojrzałości.

Powyższy przykład wskazał również na dodatkowy czynnik, który wydał się być nieodzowny w zarządzaniu projektem. Mowa tutaj o obecności ekspertów dziedzinowych, osób z doświadczeniem i kompetencjami, które mogą wspomagać menedżerów w zarządzaniu projektem. Jak pokazał przykład, młody zespół (złożony z niedoświadczonych uczestników i liderów o niedużym doświadczeniu w zarządzaniu projektami) czy też początkująca firma informatyczna może na pewnych etapach realizacji projektu potrzebować konsultacji z ekspertami dziedzinowymi. Włączenie do projektu osób o dużym doświadczeniu projektowym opisane w przykładzie piątym usprawniło realizowanie zadań.

Definicja 3.1

Ekspert dziedzinowy rozumiany jest jako doradca, osoba, która służy pomocą zespołowi, wypowiadająca swoje opinie, wskazująca kierunki lub sugerująca rozwiązania. Charakteryzuje się

Ekspert dziedzinowy rozumiany jest jako doradca, osoba, która służy pomocą zespołowi, wypowiadająca swoje opinie, wskazująca kierunki lub sugerująca rozwiązania. Charakteryzuje się