Od początku do końca, czy na odwrót?

Jakiś czas temu opisywałem na prostym przykładzie zakupów jakie zależności w projekcie występują między czasem, zakresem oraz budżetem. Zwiększając listę zakupów nastąpi prawodpodobnie wzrost pozostałych wartości (czasu realizacji oraz potrzebnego budżetu). Ograniczenie z kolei czasu lub budżetu może się wiązać z ograniczeniem możliwych do wykonia zakupów. Takie podejście jest specyficzne dla waterfallowego zarządzania projektami.

Załóżmy jednak teraz, że mamy listę zakupów i wiemy ile z jej pozycji możemy zrealizować w określonej jednostce czasu. Dzieląc wielkość listy zakupów przez ilość pozycji (prędkość) otrzymujemy wielkrotność jednostek czasu (liczbę iteracji), którą potrzebujemy do zrealizowania pełnych zakupów. Jest to tzw. planowanie z ustalonym zakresem – diagram A.

Postawmy się jednak teraz w sytuacji, gdy narzucono mam termin, do którego mamy wykonać zakupy. W takiej sytuacji, znając prędkość zakupów, jesteśmy w stanie określić jaki zakres listy jesteśmy w stanie zrealizować w narzuconym czasie. Dzieląc dostępny czas przez jednostki czasu, otrzymujemy wielkrotność prędkości realizacji (liczbę iteracji). W takiej sytuacji istotne jest określenie kryteriów szacowania wartości/użyteczności poszczególnych pozycji listy. W szczególności, gdy z wyliczeń okaże się, że realizacja pełnej listy nie jest możliwa w zaplanowanym czasie. Jest to tzw. planowanie z ustaloną datą – diagram B.

Takie sposoby planowania stosuje się w projektach opartych o metodyki zwinne (m.in. Agile). W przypadku tych metodyk, odpowiednikiem prędkości zakupów jest prędkość realizacji/zespołu liczona dla jednostki czasu, jaką jest długość tzw. sprint. Sama prędkość realizacji/zespołu jest liczona w tzw. story point-ach, w których wycenia się (w ramach wyceny zakresu) także poszczególne wymagania, będące odpowiednikami pozycji zakupów.

Opisane metody można zaprezentować jak na powyższym diagramie. Pierwsze co się rzuca w oczy to fakt, że ten sam element – lista zakupów/zakres realizacji – jest w pierszym (diagram A) przypadku wejściem dla procesu, a dla drugiego (diagram B) – wyjściem. W przypadku ustalonej (planowanej) daty zakończenia – sytuacja jest wręcz odwrotna, w pierwszym przypadku (diagram A) jest wyjściem, a w drugim (diagram B) wejściem. Procesy opierają się na tych samych podstawach – m.in. prędkości realizacji/zespołu oraz zakresie realizacji (oczekiwanym/pełnym).

Reklama

Proces a projekt

Ostatnio w jednym z wywiadów przedstawionych na stronie Ebizq.net pojawiło się pytanie: „How do project management and business process management relate to each other?”. To pytanie, dotyczące relacji zarządzania projektami i zarządzania procesami biznesowymi, przyciągnęło moją uwagę, na moje zainteresowanie obydwoma dziedzinami. Spotykałem się z różnym zestawieniem relacji, ale najczęściej opierało się na różnicy między projektem a procesem z punktu widzenia organizacji, powtarzalności, granic czasowych i sposobu oceny.

We wspomnianym wywiadzie dziedziny te zostały umieszczone na dwóch biegunach – diagram poniżej. Z jednej strony efektem zarządzania projektami może być zmiana procesu biznesowego, a sama jego realizacja może pozwolić na ocenę realizacji celów projektów, w zakresie np. zaplanowanej zmiany w pracochłonności, zmianie efektywności procesu czy likwidacji wąskich gardeł. Równocześnie uczestnicy procesu mogą wskazać zmiany, które należy wykonać, bądź to w postaci bieżących ulepszeń, bądź poprzez realizację inicjatywy projektowej. Z kolei samo zarządzanie projektem też może się odbywać w ramach określonego procesu działań.

W odpowiedzi na powyższe pytanie pojawia się również dodatkowa kwestia. Zarządzanie procesami biznesowymi jest szersze niż zarządzanie projektem. Myśle, że ta kwestia jest dość oczywista. W ramach wszystkich procesów przedsiębiorstwa niektóre z procesów mogą dotyczyć właśnie zarządzania projektami – proces zgłaszania zmian, proces zarządzania zmianą, proces monitoringu projektów, proces oceny korzyści projektów itd. Dla pewnych jednostek organizacyjnych mogą to być procesy główne, a dla niektórych procesy pomocnicze.

Weźmy na przykład osobę, która wykonuje czynności operacyjne, będące częścią procesu głównego. Równocześnie może zostać zaproszona jako ekspert dziedzinowy do pracy w projekcie w celu przedstawienia obecnego przebiegu procesu lub danego jego kroku