Słownik zarządzania projektami: kluczowe pojęcia

Analityk biznesowy

Analityk biznesowy zajmuje się definiowaniem potrzeb biznesowych w projekcie, dzięki czemu możliwe jest znalezienie optymalnych rozwiązań w toku realizacji projektu. W zespole projektowym często pełni rolę „łącznika” między zespołem informatycznym, projektowym i informatycznym. W każdej fazie projektu jego zadania są inne, jednak dotyczą one głównie dostarczania zespołowi projektowemu i PMO informacji niezbędnych do realizacji projektu.

Analiza make-or-buy

To analiza, której celem jest podjęcie decyzji o opłacalności zakupu lub wykonania zasobów niezbędnych do realizacji projektu. W jej trakcie uwzględnianie są koszty wytworzenia zasobów (np. półproduktów, urządzeń, oprogramowania, itp.), zasobów ludzkich, itp. Na jej podstawie podejmowana jest decyzja, czy bardziej opłacalne jest stworzenie tych zasobów, czy ich zakup.

Analiza odchyleń wykorzystania zasobów

To analiza, której głównym celem jest ocena skuteczności wykorzystania zasobów w projekcie. Pozwala ona, na każdym etapie życia projektu, na ocenę efektywności wydatków czy gospodarowania zasobami. Dzięki niej możliwe jest wczesne wykrywanie odchyleń (pozytywnych i negatywnych) oraz wdrożenie działań, które mają na celu optymalizację procesu realizacji projektów.

Analiza ryzyka w projekcie

To analiza, która pozwala zidentyfikować, oszacować oraz dokonać ewaluacji ryzyka w projekcie. Pozwala ona kierownikowi projektu na skategoryzowanie konkretnych ryzyk, unikanie ich pojawienia się oraz lepsze planowanie działań na różnych etapach życia projektu. Ważnym elementem analizy jest stworzenie potencjalnych odpowiedzi na ryzyka. W analizie ryzyka kluczowe jest określenie prawdopodobieństwa pojawienia się tego ryzyka oraz wpływu, jaki może mieć ono na realizację projektu. Sama analiza ryzyka jest jednym z kluczowych elementów definiowania oraz planowania projektu.

APM (organizacja i certyfikat)

APM, czyli Stowarzyszenie Zarządzania Projektami (Association for Project Managment), to brytyjska organizacja zrzeszająca specjalistów (a w szczególności praktyków) zajmujących się realizacją projektów. Poza rozwojem i podnoszeniem kompetencji samego środowiska Project Managerów, organizacja prowadzi szkolenia oraz odpowiada za certyfikację PM-ów. Dodatkowo wydaje certyfikaty APM, potwierdzające kompetencje w zarządzaniu projektami (w oparciu o standardy IPMA, czyli Międzynarodowego Stowarzyszenia Zarządzania Projektami; International Project Managment Association).

Backlog produktu

To w praktyce lista zadań, wymagań i działań, których efektem jest zrealizowany projekt. Poza tym backlog produktu zawiera opisy testów, które powinien przejść pozytywnie wykonany produkt. Co ważne – backlog produktu zawiera najczęściej zadania na 2-4 najbliższe sprinty. To pojęcie jest bezpośrednio związane z metodyką SCRUM, a za stworzenie tego dokumentu odpowiedzialny jest Product Owner.

Backlog sprint

To zbiór zadań realizowanych w trakcie konkretnego sprintu. To pojęcie, podobnie jak backlog produktu, jest bezpośrednio związane z metodyką SCRUM. Każde zadanie realizowane w danym sprincie powinno być opisane w backlogu oraz zawierać informacje takie jak osoba odpowiedzialna za jego realizację, estymację czasu wykonania projektu, status zadania oraz jego funkcjonalny opis. Za backlog odpowiada najczęściej zespół deweloperski lub – w przypadku zarządzania projektami – Project Manager.

Beneficjent

Beneficjentów w zarządzaniu projektami jest wielu: od końcowego (czyli na przykład instytucja odpowiedzialna za zlecenie realizacji konkretnego projektu, który ma spełniać jakieś oczekiwania lub zaspokajać jakieś potrzeby), przez projektowego (pojawia się często w projektach dofinansowanych ze środków UE; jest to osoba lub organizacja, która nie posiada osobowości prawnej, ale realizująca projekty, na które otrzymuje środki z budżetu państwa lub środków zagranicznych), aż do rzeczywistego (czyli osoby lub organizacji, która rzeczywiście korzysta z wyników realizacji projektu – na przykład oprogramowania lub produktu). W zależności od tego kontekstu to pojęcie określa różne role w obszarze projektu.

Bilansowanie zasobów

To działanie, które ma na celu z jednej strony najlepsze wykorzystanie zasobów w toku realizacji projektu, a z drugiej – zwiększenie szans na terminowe ukończenie poszczególnych etapów działań. Może to oznaczać zarówno przydzielaniem środków z budżetu projektowego, jak i zarządzanie czasem pracowników zaangażowanych w realizację projektu tak, aby lepiej wykorzystywali swój czas i kompetencje.

Biuro projektu

To struktura w organizacji, której głównym zadaniem jest wspieranie zespołów projektowych w realizacji ich prac. Ta struktura odpowiada za działania związane z realizacją projektu na każdym jego etapie – od zainicjowania, przez monitorowanie i kontrolę, aż do zamknięcia. W przeciwieństwie do Biura Zarządzania Projektem (PMO – Project Managment Office), biuro projektu jest strukturą powoływaną doraźnie, na potrzeby konkretnego projektu i najczęściej rozwiązywaną po zakończeniu prac nad nim.

Biuro zarządzania projektami

Czyli project management office, to osobna struktura w przedsiębiorstwie, której głównym zadaniem jest wspieranie zespołów odpowiedzialnych za realizację projektów oraz minimalizacja szans na niepowodzenie projektu (monitorowanie ryzyka, itp.). Biuro zarządzania projektami jest stałym elementem struktury wielu przedsiębiorstw i odpowiada za realizację projektów na wszystkich ich etapach.

Budżet projektu

To w praktyce plan finansowy projektu – uwzględnia wydatki, najczęściej podzielone na poszczególne etapy realizacji projektu oraz konkretne działania. Najważniejszą rolą tego dokumentu jest śledzenie wydatków oraz – pośrednio – optymalizacja kosztów realizacji projektów. W połączeniu z analizami kosztów projektu budżet umożliwia efektywniejsze zarządzanie zasobami projektu.

Burndown

Od burndown chart, czyli „diagram wypalenia” – to sposób przedstawiania postępów prac, zwłaszcza w trakcie konkretnego sprintu. Najczęściej przedstawiana jest w formie diagramu, który pomaga określić jak wiele zadań zostało wykonanych, a jak wiele z nich zostało do wykonania. W dużym skrócie: im mniej zadań do wykonania, tym bardziej „robota pali się w rękach”, czyli jest szybciej wykonywana. Stąd też nazwa tego diagramu.

CPM

Czyli Critical Path Method (w wolnym tłumaczeniu z angielskiego: metoda ścieżki krytycznej), to jedna z technik planowania w toku realizacji projektów. Sama metoda została opracowana pod koniec lat 60. XX wieku w USA i pomaga w lepszym zrozumieniu zależności między poszczególnymi procesami i aktorami w toku realizacji projektów. Lepsze zrozumienie tych zależności pozytywnie wpływa na efektywność działań, a przez to – optymalizację realizacji projektów, w praktyce na każdym etapie cyklu życia projektu. Istotne jest tu uwzględnianie efektów wprowadzenia w życie planów oraz analiza ich skuteczności – celów, budżetu, przypisanych zasobów, itp. Dzięki takiemu planowaniu „na bieżąco” możliwe jest szybsze zidentyfikowanie możliwości i wyzwań w projekcie oraz wykorzystanie tej wiedzy.

Cykl życia projektu

To w praktyce uniwersalna matryca opisująca następujące po sobie etapy realizacji projektu – od powstania pomysłu, aż do jego podsumowania i ewaluacji. Sam cykl, w zależności od metodologii,  może mieć wiele różnie nazwanych etapów, które są mocno osadzone w samej metodologii. Niemniej zrozumienie charakterystycznych etapów cyklu życia projektu pomaga lepiej zarządzać zasobami, a przez to – optymalizować proces na każdym jego etapie. Koncepcji cyklu życia projektu jest wiele – obecnie wymienia się autorów takich jak Lewis, Kruger czy Mantel/Meredith – jednak kluczowe elementy cyklu życia projektu są do siebie zbliżone.

Daily scrum

To codzienne spotkanie zespołu pracującego nad projektem. Przyjęło się, że daily scrum to stały element pracy zespół deweloperskich, jednak takie spotkania znajdują swoje zastosowanie w niemal każdym rodzaju działań projektowych, włączając w to marketing czy księgowość. Głównym założeniem tych spotkań jest szybkie podsumowanie postępów prac w sprincie – powinno ono trwać mniej niż 15 minut i wielu zwolenników metodologii scrum podkreśla, że daily scrum powinien odbywać się na stojąco, żeby każdy z uczestników błyskawicznie raportował swoje postępy, a wizja stania dłużej niż kwadrans zachęcała do skupienia się na konkretach. Takie codzienne raporty określa się mianem daily standup.

Decyzja środowiskowa

To jedna z kluczowych decyzji dla projektów, które mogą mieć jakikolwiek wpływ na środowisko naturalne. Jej podstawą jest ocena oddziaływania na środowisko, która pozwala określić wpływ projektu tego wpływu – zarówno negatywnego, jak i pozytywnego. Kluczowym elementem decyzji środowiskowej jest raport określający tenże wpływ.

Diagnoza w projekcie

Pozwala na identyfikowanie zarówno wyzwań, przed którymi staje zespół projektowy, jak i ocenę stopnia realizacji konkretnego zadania. Najważniejszym zadaniem diagnozy w projekcie jest dostrzeżenie i zrozumienie potencjału oraz wyzwań: zarówno obecnych, jak i tych w przyszłości. Samo diagnozowanie w toku prac nad projektem pozwala na poprawę efektywności działań: zarówno finansowych, jak i czasowych.

DMAIC

To w praktyce metoda konstruktywnego rozwiązywania problemów, która pozwala przekuć nawet dużą porażkę na sukces (lub naukę) w przyszłości. Sam skrót DMAIC to pierwsze litery poszczególnych etapów tego procesu: define (zdefiniowanie), measure (zmierzenie), analyse (analiza), improve (poprawienie, udoskonalenie), control (kontrolowanie, weryfikacja). Kolejne kroki pozwalają zrozumieć etapy dojścia do konkretnego stanu oraz wysnucie z nich wniosków, które pozwalają lepiej radzić z podobnymi problemami lub wyzwaniami w przyszłości.

Dokumentowanie wymagań klienta

To bardzo ważny element każdego projektu, niezależnie od tego, czy projekt jest realizowany na zlecenie wewnętrzne czy zewnętrzne. Oznacza to, że niezależnie od tego, kim jest klient, zespół projektowy powinien stworzyć na podstawie zgłoszonych wymagań dokument, który odpowiada na kluczowe pytania dotyczące celu, działania czy korzystania z projektu. W tworzeniu takiej dokumentacji ważne jest zachowanie informacji o priorytecie wymagania, jego jednoznacznej treści czy niezbędnych komentarzy, które pomagają członkom zespołu na lepszą realizację projektu.

Dynamika grupowa

Autorem tego pojęcia jest K. Lewin, twórca szkoły dynamiki grupowej. Sama dynamika grupowa określa zasady istnienia konkretnej grupy, w tym przypadku – zespołu realizującego projekt (chociaż może być zastosowana do innych obszarów życia, zawodowego i prywatnego). Kluczowym elementem tej dynamiki jest utrzymanie odpowiedniej proporcji między solidarnością (czyli poczuciem wspólnoty i spokoju w zespole) a napięciem (motywującym do podejmowania zadań i wytwarzających poczucie kontrolowanego zagrożenia). Teoria dynamiki grupowej podsuwa pięć uniwersalnych etapów, które mogą być z łatwością przyporządkowane kolejnym etapom cyklu życia projektu i pod wieloma względami opisują relacje przychologiczno-społeczne pracy w zespole projektowym.

Epic

Kolejne pojęcie z metodyki scrum, które określa duże zadanie lub duży cel pracy, który jest elementem rozwoju większej całości. Epic jest tworzony w oparciu o wymagania klienta, których realizacja wymaga więcej czasu niż pozwala na to jeden sprint. Po uznaniu jakiegoś zadania za zbyt duże na jeden sprint, product owner może podjąć decyzję o podziale jednej historii użytkownika na kilka i przyporządkowanie ich, wraz z zadaniami, sprintom. Sam epic może być rozbity na wiele historii użytkowników, a ich realizacja – na wiele sprintów.

Eskalacja

To trudna część pracy nad projektem, bo określa ona narastanie intensywności konfliktów w zespole projektowym. Źródłem tego wzrostu napięcia w zespole może być zarówno wpływ czynników zewnętrznych (niespodziewane zmiany wymagań klienta, konflikt z klientem, problemy z terminowością zewnętrznych dostawców) jak i wewnętrznych (konflikty w zespole, złe zarządzanie przez product ownera, itp.). Eskalacja jest zawsze zagrożeniem, zarówno dla realizowanego projektu, jak i samego zespołu. Wczesna i poprawna reakcja product ownera lub PMO może zarówno zmniejszyć napięcia w zespole, jak i poprawić efektywność jego pracy w przyszłości. Z kolei zbyt późna reakcja może skutkować poważnym osłabieniem lub nawet rozpadem zespołu projektowego. W mówieniu o eskalacji konfliktu bardzo przydaje się dziewięciostopniowa skala eskalacji konfliktu, stworzona przez Friedricha Glasiego.

Estymacja czasu trwania zadań

Jest istotnym elementem w trakcie pracy nad projektami – powinna ona zakładać czas niezbędny na realizację działań i nieplanowane i planowane przerwy (niezależne od pracownika, ale też te zależne od prawa pracy – przerwy na obiad, itp.). Sama estymacja powinna uwzględniać efektywność pracy konkretnego członka zespołu oraz samą wydajność. W przypadku znanych zadań estymacja czasu ich realizacji może być prosta (podobne zadanie już było realizowane, czyli nowe będzie zrealizowane w czasie zbliżonym do poprzedniego), wymagająca więcej czasu (na przykład projekt przypomina coś, co znają członkowie zespołu lub lider, ale muszą szacować przybliżony czas) lub wręcz niemożliwa do precyzyjnego przeprowadzenia, gdy charakter zadania odbiega od dotychczasowych doświadczeń. W estymowaniu czasu trwania zadań stosuje się wiele technik. Na przykład R.K. Wysocki podaje sześć technik estymowania: wykorzystania podobieństwa do innych zadań, danych historycznych, rady ekspertów, delficką, trzech punktów i delficką uśredniającą.

Etapy projektu

Czyli kluczowe terminy określające kolejne etapy realizacji projektu – od jego zamówienia, przez realizację, aż do zamknięcia i podsumowania. Przyjmuje się, że zarządzanie projektami określa pięć kluczowych etapów: definiowanie, planowanie, realizację, kontrolę i monitorowanie oraz zamykanie projektu. Każdy z nich wymaga innych narzędzi i wskaźników skuteczności, co oznacza, że podejście do każdego z nich jest inne.

Ewaluacja projektu

To jeden z ostatnich etapów projektu i pod wieloma względami – najważniejszy z nich. W trakcie ewaluacji oceniania jest zarówno skuteczność realizacji projektu, jak i same działania prowadzące do jego finalizacji, z uwzględnieniem pracy poszczególnych zespołów czy nawet ich członków. Uniwersalnie mówi się o ewaluacji ze względów strategicznych i operacyjnych. Sama ewaluacja może być również prowadzona na wielu etapach – nie tylko na końcowym. Pozwala ona na przeanalizowanie działań i wyciągnięcie wniosków, które pozwalają zarówno ocenić efektywność, jak i wskazać obszary warte usprawnienia w pracy zespołu lub po prostu słabe punkty. Istotne jest również to, że sama ewaluacja projektu jest stałym wymogiem działań realizowanych przy wsparciu środków unijnych.

Extreme programming

Zwana też XP (od eXtreme Programming, czyli programowania ekstremalnego), to jedna z metodyk tworzenia oprogramowania, oparta o agile, czyli „techniki zwinne”. Istotą programowania ekstremalnego jest praca nad krótkimi elementami kodu, przy dużym nacisku na komunikację w zespole (które pozwala na szybkie identyfikowanie problemów i ich rozwiązywanie), prostotę rozwiązań (zasada KISS, czyli keep it simple, stupid – w wolnym tłumaczeniu: zachowajmy prostotę, głuptasie), zbieranie informacji zwrotnych od klienta na każdym etapie pracy nad projektem/oprogramowaniem (kluczowe z perspektywy wcześniejszego adresowania możliwych problemów) i odwaga (która zachęca do podejmowania samodzielnych decyzji członkom zespołu, wspiera samosterowność, jednak uczy członków zespołu odpowiedzialności za błędy, a przez to – może mieć pozytywny wpływ na atmosferę). Samo extreme programming, chociaż najczęściej odnosi się do prac programistycznych, może być z łatwością zastosowane w innych obszarach pracy nad projektem, a same wartości metodyki (komunikacja, prostota, informacja zwrotna i odwaga) mogą usprawniać prace wielu zespołów projektowych.

Facylitacja

Odnosi się do wielu obszarów biznesu, jednak w zarządzaniu projektami dotyczy wspierania członków zespołu oraz umożliwiania im rozwoju kompetencji w wyniku samodzielnej pracy. Z tej perspektywy istotne jest zarówno utrzymanie dobrej atmosfery w zespole jak i odpowiednie podejście facylitatora, czyli osoby, która zarządza pracownikami. Zdrowa relacja w zespole może przekładać się na to, ze facylitator – niezależnie od tego, czy PMO, product owner czy lider zespołu – wspiera podległych pracowników i umożliwia im rozwój kompetencji przy jednoczesnym utrzymaniu odpowiedniego dla zespołu tempa rozwoju.

Fazy projektu

To pojęcie zakorzenione w metodyce PRINCE2, które zakłada istnienie czterech kluczowych faz każdego projektu: przygotowanie, inicjowania, realizacji i zamykania. Jest to pojęcie zbliżone do etapów realizacji projektów, jednak w tej metodyce widoczny jest duży nacisk na procesy dokonujące się na każdym z ich etapów. Warto dodać, że poza fazami projektu, metodyka PRINCE2 zakłada istnienie następujących procesów w tym obszarze: przygotowanie projektu, zarządzanie strategiczne projektem, inicjowanie projektu, sterowanie etapem, zarządzanie dostarczeniem produktów, zarządzanie końcem etapu i zamykanie projektu.

Feature-Driven Development

W skrócie FDD, jest jedną z metodyk adaptacyjnego zarządzania projektami i stawia na utrzymanie kontaktu z klientem oraz szybkie dostarczanie widocznych efektów pracy. Pozwala to na lepszą realizację projektu i ewaluację działań, dzięki czemu klient może ocenić zgodność wersji projektu z jego oczekiwaniami oraz zgłaszać poprawki na każdym etapie prac. Feature-Driven Development pozwala na tworzenie projektów lepiej odpowiadających na realne potrzeby klienta i użytkowników – właśnie dzięki ciągłej komunikacji i ewaluacji funkcji na osi zespół projektowy – klient. Wśród dobrych praktyk FDD warto wymienić tworzenie modelu obiektowego systemu, co pozwala na szybką wizualizację konkretnego produktu, czy przyrostową budowę produktów, która pozwala na stopniowe budowanie samego projektu.