„Jaki jest wpływ portfela moich projektów?”

Data: 2014-05-18
Autor: Sebastian Konkol
„Jaki jest wpływ portfela moich projektów?”

Niemalże wszystkie firmy, których model biznesowy zakłada wykorzystanie technologii IT, realizują często poważną liczbę projektów zmian w swoich systemach. Liczba tych projektów jest zwykle na tyle duża, że zarządczy nadzór nad nimi realizowany jest za pomocą metod portfela projektów. Metody te skupiają się na projektach i zależnościach między nimi ujętych w (co najwyżej) typowych dla projektów ramach – produktów prac i harmonogramu. Nie odnoszą się one do zależności technicznych przedmiotu projektów (systemów IT), w praktyce kompletnie od tych zależności abstrahując, pomijając je. Konsekwencje tych zależności nie są więc dostrzegane przez grona decyzyjne, przez co ich decyzje nie obejmują ryzyka wynikającego z istnienia tych zależności – stają się one widoczne dopiero wtedy, kiedy „uderzą”. Zważywszy, że biznes technologiczny zależy od technologii, brak perspektywy wpływu zależności między zmianami technologicznymi w obszarze zarządzania portfelowego to aktywne proszenie się o kłopoty, więc jak temu zapobiec?

Dla osiągnięcia tak postawionego celu wykorzystuję zwykle koncepcję Enterprise Continuum. W zamierzeniach odnosi się ona do wszystkich cech, zdolności firmy – zarówno osiąganych organizacyjnie jak i narzędziami IT – obejmujących procesy biznesowe i systemy informatyczne umożliwiające realizację tych zdolności. Enterprise Continuum jest fundamentem dla prowadzenia biznesu firmy i może być wzbogacane i modyfikowane. Każde przedsięwzięcie, np. projekt z portfela projektów, rozpoczyna się z pewnego stanu Enterprise Continuum (zbiór, konstelacja zdolności określanych jako architektura AS-IS), wymaga jakiegoś czasu na realizację swojego zakresu, a swoje wyniki dostarcza do przyszłego stanu Enterprise Continuum, zwykle odmiennego od wyjściowego. Dostarczając i „integrując” swe wyniki przedsięwzięcie zmienia stan Enterprise Continuum na nowe (zbiór, konstelacja zdolności określanych jako architektura TO-BE).

W sytuacji, kiedy takich przedsięwzięć modyfikujących Enterprise Continuum jest więcej, daje się wskazać potencjał kolizji tychże przedsięwzięć, dwóch podstawowych rodzajów. Pierwszy powód wynika z momentu startu przedsięwzięcia, z którym związany jest stan wiedzy o oczekiwanej wersji Enterprise Continuum, do której mają się zintegrować wyniki startowanego właśnie przedsięwzięcia. Tu ujawniają się zależności merytoryczne o statycznym charakterze, związane z realizacją innych przedsięwzięć, które – do czasu zaplanowanego zakończenia realizacji startowanego przedsięwzięcia – wprowadzą już do Enterprise Continuum swoje zmiany. Drugi powód wynika z zaburzeń wprowadzanych przez zakłócenia w czasach realizacji przedsięwzięć. Tu ujawniają się dynamiczne zależności merytoryczne, które zmieniać mogą wersję Enterprise Continuum na inną, niż domniemana na moment dostarczenia startowanego przedsięwzięcia.

Aby takie zależności identyfikować i dołączyć do zarządzania portfelowego zdolność zarządzania tymi zależnościami, opisuję architekturę korporacyjną jako ewolucję, przeprowadzającą Enterprise Continuum przez sekwencję wersji. Choć sama metoda postępowania jest bardziej złożona, w dużym uproszczeniu można ją przedstawić na przykładzie sfery IT. Na poszczególne wersje – w sferze IT – składają się systemy i ich komponenty, a każda zmiana wprowadzana w ramach przedsięwzięcia zmienia określone komponenty. Wersjonując komponenty i ustalając zależności merytoryczne przez pryzmat zmian zachodzących w komponentach o określonych wersjach udaje się śledzić zależności – zarówno statyczne jak i dynamiczne – dla całego portfela projektów modyfikujących w różny sposób różne elementy Enterprise Continuum.

Obserwując plan ewolucji Enterprise Continuum w czasie udaje się zwykle zarządzać ryzykiem w zakresie wykraczającym poza informację wydobytą wprost ze zidentyfikowanych zależności. Sytuacje dostaw kilku przedsięwzięć w krótkim odcinku czasu generują ryzyko zaburzeń ich wzajemnej sekwencji dostaw, czym można zarządzić. Ustalanie merytorycznego zakresu prac jakiegoś projektu na podstawie świeżej dostawy innego przedsięwzięcia oznacza uzależnienie od niestabilnego rozwiązania. Złożoność dostaw dużych projektów wpływa na wiele mniejszych, a w sytuacji istotnych ograniczeń czasowych pojawiają się podstawy do rozsądnego podziału dużych projektów na mniejsze, reprezentujące mniejsze ryzyko merytoryczne dla całości portfela.

Takie podejście, włączające perspektywę merytoryczną do zarządzania portfelem projektów, sprawdza się bez względu na sposób, w jaki zmiany są wdrażane. Udaje się go spójnie stosować zarówno w ramach „wodospadowego” podejścia opartego o Release Management, jak i „agile’owego” Continuous Integration. W obu przypadkach efekt stosowania metody sprowadza się do redukcji ryzyka technicznego, jakie nie jest bezpośrednio zarządzane przez projekty. W tym względzie architektura korporacyjna stanowi najlepsze tło dla identyfikacji takich czynników ryzyka i zarządzania nimi.

Pozostaw komentarz