Identyfikacja wystąpienia czynników ryzyka w projektach informatycznych

Pełen tekst

(1)Zeszyty Naukowe nr. 865. Uniwersytetu Ekonomicznego w Krakowie. 2011. Dariusz Dymek Katedra Systemów Obliczeniowych. Identyfikacja wystąpienia czynników ryzyka w projektach informatycznych Streszczenie. Identyfikacja wystąpienia w projekcie lub jego otoczeniu zdarzeń mogących wpływać negatywnie na jego realizację zgodnie z założeniami jest ważnym elementem zarządzania ryzykiem. Ich wczesne wykrycie pozwala rozpocząć działania zapobiegawcze lub kompensujące, zanim jeszcze skutki tych zdarzeń wpłyną w istotny sposób na projekt. Wykorzystywane w tym zakresie metody eksperckie mogą zawodzić w wypadku zjawisk zachodzących bardzo powoli lub będących wypadkową kilku pozornie ze sobą niezwiązanych zdarzeń. Potrzebne jest narzędzie wspierające prace ekspertów, które pozwoli wykrywać takie zjawiska zanim skutki ich wystąpienia osiągną punkt krytyczny. Przedstawiona koncepcja metody konstrukcji zestawu miar (wskaźników) pozwalających wykrywać takie zjawiska na podstawie pomiaru parametrów projektu i wybranych czynników ryzyka. Zaproponowane rozwiązanie daje zobiektywizowany obraz projektu na potrzeby oceny ryzyka projektowego. Słowa kluczowe: zarządzanie ryzykiem, identyfikacja czynników ryzyka.. 1. Wprowadzenie Każdemu działaniu podejmowanemu przez człowieka towarzyszy niepewność, co do jego rezultatów. Gdy rezultaty te są przewidywalne oraz można im przypisać prawdopodobieństwo wystąpienia, mamy do czynienia z ryzykiem1. Problematyka ryzyka i próby opisania jego roli w działaniach człowieka związane są z rozwojem rachunku prawdopodobieństwa i sięgają XVII w. [Bernstein 1997]. W przeciwnym przypadku, tzn. gdy nie są znane możliwe rezultaty działania, a tym samym nie można im przypisać prawdopodobieństwa wystąpienia mówimy o niepewności sensu stricto. 1.

(2) Dariusz Dymek. 22. Jednak wyodrębnienie ryzyka jako dziedziny badań i próby jego formalnej definicji miało miejsce w Stanach Zjednoczonych na początku XX w. Ryzyko jako zjawisko złożone, zależne od dziedziny, wymyka się próbom ujęcia w jednolity, powszechnie przyjęty model. Stąd wiele badań w dziedzinie ryzyka koncentruje się na konkretnych zastosowaniach, przyjmując definicje adekwatne do tych zastosowań. W konsekwencji wyróżnić można ryzyko kredytowe, ubezpieczeniowe, organizacyjne, polityczne i wiele innych. Prezentację różnych koncepcji ryzyka i jego rodzajów przedstawili T.T. Kaczmarek [2008] oraz A. Zachorowska [2006]. W podejściu do definiowania ryzyka wspólny jest jego negatywny charakter wpływu na rezultaty działań, choć sposób ich określenia jest już różny u różnych autorów. Na przykład D. Cooper i C. Chapman np. definiują ryzyko jako „potencjalne źródło istotnego błędu, kosztu lub odchylenia od oczekiwań – niepożądaną konsekwencję niepewności, nieokreśloności”, P.G.Neumann określa ryzyko jako „potencjalny problem z określonymi przyczynami i skutkami oznaczającymi straty”, a z kolei u Sage’a ryzyko oznacza „prawdopodobieństwo powstania szkód, zniszczeń lub strat w pewnym specyficznym otoczeniu, warunkach i określonym czasie” [Kuraś i Zając 1999]. Ryzyko jest skutkiem wielu składowych, wśród których do podstawowych można zaliczyć: – złożoność otoczenia podejmowanych działań oraz jego dynamiczny charakter wynikający m.in. z działań innych ludzi, – nieokreśloność i nieciągłość zjawisk społeczno-ekonomicznych, – wiedzę (a raczej brak pełnej wiedzy) na temat tego otoczenia oraz procesów w nim zachodzących. W kontekście ryzyka w projektach informatycznych najodpowiedniejsza jest definicja Coopera i Chapmana głównie dlatego, że wprost wskazuje oczekiwania jako punkt odniesienia do ryzyka. Aby dokładniej przybliżyć pojęcie ryzyka w projekcie, jako punkt wyjścia do dalszych rozważań przyjęto definicję projektu. „Projekt to sekwencja niepowtarzalnych, złożonych i powiązanych ze sobą działań mających wspólny pojedynczy cel, przeznaczonych do wykonania w określonym terminie bez przekraczania ustalonego budżetu, zgodnie z założonymi wymaganiami” [Wysocki i McGary 2005]. Niepożądane konsekwencje, o których mowa w definicji ryzyka odnoszą się do jednego z trzech elementów definicji projektu: czasu, budżetu lub specyfikacji wymagań, nazywanych dalej parametrami projektu. W niniejszej pracy czynnikami ryzyka nazwane zostały zdarzenia i sytuacje mogące wystąpić w trakcie realizacji projektu i wpływające w potencjalnie negatywny sposób na parametry projektu. W kontekście zarządzania ryzykiem, czynniki ryzyka mają charakter niedeterministyczny, tzn. mogą, ale nie muszą wystąpić oraz że ich skutki również nie są w pełni zdeterminowane2. Ten niedeterministyczny charakter znajduje odbicie w podejściu do estymacji ryzyka bazującego na rachunku prawdopodobieństwa [Stabryła 2006; Pawlak 2006]. 2.

(3) Identyfikacja wystąpienia czynników…. 23. Analizując definicję projektu, warto zwrócić uwagę na „wspólny pojedynczy cel”. Zgodnie z nim wszystkie działania podejmowane w projekcie w ramach przyjętych parametrów (czas, budżet, specyfikacja) mają służyć osiągnięciu wcześniej zdefiniowanego celu. Tym samym wskazuje on na relację między parametrami projektu a celami organizacji realizującej projekt. Relacja ta pozwala traktować projekt jako część większego przedsięwzięcia podporządkowanego celom strategicznym organizacji, którego zadaniem jest zbudowanie narzędzi służących do realizacji tego celu. W węższym podejściu projekt można traktować jako zamkniętą całość, w ramach której w założonym czasie i budżecie należy osiągnąć określony rezultat (opisany specyfikacją wymagań). W takim podejściu projekt stanowi jedynie jedną z faz realizacji przedsięwzięcia – fazę wykonania3. Dalsze rozważania koncentrują się głównie na czynnikach wpływających bezpośrednio na projekt traktowany jako faza wykonania przedsięwzięcia. Pozwala to na skoncentrowanie się na tych czynnikach ryzyka, które są charakterystyczne dla typów projektów związanych ze specyfiką wykorzystywanych technologii, w tym wypadku projektów opartych na technologii informatycznej (TI), zwanych w skrócie projektami informatycznymi. Aby efektywnie zarządzać ryzykiem, należy określić czynniki ryzyka występujące dla danego typu projektu. W zależności od poziomu szczegółowości w projektach informatycznych wyróżnia się od kilkunastu do kilkudziesięciu czynników ryzyka [Kuraś i Zając 1999; Szyjewski 2001; Kerzner 2005]. Lista czynników ryzyka jest otwarta, stale uzupełniana o nowe czynniki, wynikające zarówno ze specyfiki projektów informatycznych, jak i dziedziny w jakiej są one prowadzone. Sam fakt określenia potencjalnych źródeł ryzyka nie jest wystarczający do wdrożenia skutecznego systemu zarządzania ryzykiem. Stanowi tylko element przygotowawczy, wskazując na ryzyko, ale nie determinując faktu jego wystąpienia. Stąd kluczowym elementem jest mechanizm pozwalający na wykrywanie zdarzeń, zachodzących w projekcie lub jego otoczeniu, będących potencjalnym lub rzeczywistym źródłem zagrożenia dla konkretnego projektu. Poziom ryzyka musi być stale monitorowany, a działania podejmowane w zakresie zapobiegania czy minimalizacji skutków wystąpienia ryzyka muszą być dostosowywane do konkretnego poziomu i rodzaju ryzyka.. 3 Całość przedsięwzięcia można podzielić na trzy podstawowe fazy: fazę przygotowania, gdzie od celów strategicznych poprzez analizę potencjalnych rozwiązań dochodzimy do zdefiniowania parametrów projektu; fazę wykonania, czyli projekt, którego celem jest przygotowanie odpowiednich narzędzi oraz fazę eksploatacji, w której stworzone narzędzia są używane do realizacji celów strategicznych [Stabryła 2006; Dymek 2008a]. Szerszy opis zależności pomiędzy celami w różnych fazach przedsięwzięcia oraz rodzajami występującego w tych fazach ryzyka można znaleźć w: [Dymek 2008a; Dymek 2008b]..

(4) Dariusz Dymek. 24. W pierwszej części artykułu przedstawiono czynniki ryzyka w podziale na kategorie na podstawie źródła ich pochodzenia, w drugiej – wykorzystywane metody identyfikacji wystąpienia czynników ryzyka, wskazując równocześnie na ich słabe strony. Przedstawiono również propozycję wzbogacenia tych metod o zobiektywizowane sposoby pomiaru pozwalające na lepsze śledzenie poziomu ryzyka, a tym samym dokładniejszą i szybszą identyfikację zagrożeń w projekcie. W podsumowaniu przedstawiono zalety tego podejścia oraz jego przewagę nad podejściem prezentowanym wcześniej. 2. Czynniki ryzyka w projektach informatycznych Aby wskazać czynniki ryzyka w projektach informatycznych, należy uwzględnić zarówno otoczenie, w jakim projekt jest realizowany, jak i specyficzne cechy projektów informatycznych. Rys. 1 przedstawia środowisko funkcjonowania projektu. Projekt funkcjonuje na styku klienta i wykonawcy4 w określonym środowisku społeczno-ekonomicznym. W tym środowisku można wyróżnić dwa obszary: otoczenie bezpośrednie i otoczenie zewnętrzne. Do otocznia bezpośredniego projektu należą elementy środowiska, które wpływają bezpośrednio i w sposób nieunikniony na jego realizację. Są to przykładowo regulacje prawne oraz normy i standardy branżowe. Z kolei do otoczenia zewnętrznego należą elementy, których wpływ na projekt jest pośredni, tzn. może być w jakimś stopniu kontrolowany przez organizację klienta lub wykonawcę. W wypadku projektów informatycznych są to np. zmiany technologii informatycznych (nowe trendy, narzędzia). Warto zwrócić uwagę, że do środowiska zewnętrznego należą również np. trendy występujące w branży klienta. Otoczenie zewnętrzne oddziałuje przede wszystkim na organizację klienta i wykonawcy, a dopiero w konsekwencji na sam projekt. Projekty informatyczne posiadają kilka specyficznych cech, które uzasadniają wyodrębnienie tego typu projektów jako podmiotu odrębnej analizy, a mianowicie: – wysoką złożoność końcowego produktu (oprogramowania komputerowego), połączoną z jego niematerialnym i abstrakcyjnym charakterem, – znaczny stopień twórczego charakteru prac związanych z tworzeniem oprogramowania, co skutkuje bardzo silną zależnością od tzw. czynnika ludzkiego i niemożliwością automatyzacji wielu działań, Projekty informatyczne w większości przypadków są realizowane przez zewnętrzną (w stosunku do organizacji klienta) firmę informatyczną specjalizującą się w danej dziedzinie wykorzystania technologii informatycznych (wykonawca). Dlatego w przyjętym modelu występuje organizacja wykonawcy. W tych nielicznych przypadkach, gdy projekt jest realizowany przez wewnętrzny zespół Klienta, przedstawiony model ulega uproszczeniu poprzez usunięcie z niego Wykonawcy. Jego zadania w takiej sytuacji przejmuje Klient. 4.

(5) Identyfikacja wystąpienia czynników…. 25. – interdyscyplinarny charakter prac: program5 komputerowy jest egzemplifikacją modeli i procesów w dziedzinie będącej przedmiotem działalności (potrzeb) klienta, stąd potrzeba posiadania przez zespół projektowy (wykonawcę) rozległej wiedzy z tej dziedziny.. OB OZ. PR KL. PR – projekt KL – klient OB – otoczenie bezpośrednie. WY. WY– wykonawca OZ – otoczenie zewnętrzne. Rys. 1. Środowisko projektu Źródło: opracowanie własne.. Cechy te sprawiają, że projekty informatyczne należą do jednych z najbardziej zagrożonych niepowodzeniem. Dane statystyczne wskazują, że około 50% projektów informatycznych nie daje satysfakcjonujących klienta rezultatów, a około 20% z nich kończy się całkowitą porażką6. Tak słabe rezultaty projektów informatycznych w połączeniu z rosnącą (w wielu wypadkach krytyczną) rolą oprogramowania komputerowego w codziennym funkcjonowaniu społeczeństwa, uzasadniają potrzebę odrębnego traktowania projektów informatycznych. Znajduje to swoje odbicie w licznych opracowaniach związanych z zarządzaniem projektami informatycznymi. Przy takich założeniach, wśród czynników ryzyka oddziałującego bezpośrednio na projekt, można wyróżnić ze względu na źródło ich pochodzenia cztery kategorie: – pochodzące z organizacji klienta, – pochodzące z organizacji wykonawcy, Wyjątkiem są programy komputerowe z grupy tzw. narzędzi programistycznych, czyli programów służących do tworzenia innych programów. Są one jednak przedmiotem projektów wewnętrznych realizowanych przez wyspecjalizowane firmy informatyczne, a ich liczba jest znikoma. 5. Dane na podstawie raportów The Standish Group – firmy specjalizującej się w gromadzeniu i analizie danych na temat efektywności projektów informatycznych (http://standishgroup.com/). 6.

(6) Dariusz Dymek. 26. – pochodzące z otoczenia bezpośredniego, – pochodzące z (wnętrza) projektu. Nie wyróżniono tu czynników pochodzących z otoczenia zewnętrznego. Możliwość ich kontrolowania przez organizacje klienta i wykonawcy pozwala zaliczyć je do innych kategorii. Dodano jednak kategorię czynników pochodzących z projektu. Podkreśla to instytucjonalny charakter projektu (który można traktować czasami jako odrębną organizację) oraz wskazuje, że zjawiska i działania podejmowane wewnątrz projektu też mogą być źródłem ryzyka. W tabeli 1 przedstawiono przykładową listę czynników ryzyka dla projektów informatycznych. Tabela 1. Czynniki ryzyka w projektach informatycznych według źródła ich pochodzenia Lp.. Źródło. Czynniki. nieokreślone cele, styl zarządzania, brak zaangażowania wyższego szczebla kierowniczego, brak umiejętności wykorzystania TI, brak doświadczenia w realizacji projektów informatycznych, niestabilność wymagań projektowych (specyfikacja), doświadczenie we współpracy z wykonawcami zewnętrznymi, nietypowość organizacji. 1. Klient. 2. brak znajomości i doświadczenia w zakresie stosowanych narzędzi TI, brak doświadczenia w realizacji podobnych projektów (wielkość systemu Wykonawca i dziedzina zastosowań), niska stabilność zespołu projektowego, niska elastyczność w podejściu do tworzenia rozwiązań, styl zarządzania. 3. Otoczenie. 4. Projekt. niespójny/nietrwały system prawno-gospodarczy, niedorozwój infrastruktury telekomunikacyjnej, brak standardów. zakres i złożoność systemu, brak metody zarządzania projektem lub jej niekonsekwentne (nieumiejętne) stosowanie, innowacyjność, nietypowość zastosowania narzędzi TI, brak (lub niestosowanie) harmonogramów prac projektowych, rozmijanie się z rzeczywistymi potrzebami klienta. Źródła: opracowanie własne.. Przedstawiona lista nie wyczerpuje wszystkich czynników ryzyka w projektach informatycznych7. Wskazanie czynników ryzyka, jakie mogą potencjalnie wystąpić w konkretnym projekcie, jest jednym z pierwszych etapów budowy systemu zarządzania ryzykiem w danym projekcie. Pozwala to na ocenę zagrożenia, które może pojawić się z różnych źródeł oraz na wypracowanie działań o charakterze zapobiegawczym (próba uniknięcia ryzyka) lub kompensacyjnym (minimalizacja skutków).. 7 Listy czynników ryzyka w projektach informatycznych można znaleźć w wielu pracach [Kerzner 2005; Kuraś i Zając 1999; Szyjewski 2001]. Przedstawiona lista opiera się zarówno na tych pracach, jak i własnych doświadczeniach autora w prowadzeniu projektów informatycznych..

(7) Identyfikacja wystąpienia czynników…. 27. Duża liczba czynników ryzyka oraz różne źródła ich pochodzenia oznacza, że przy realizacji projektu należy liczyć się z bardzo dużą liczbą sygnałów, które potencjalnie mogą być związane możliwością wystąpienia zdarzeń wpływających na projekt, a w szczególności na poziom ryzyka. Aby system zarządzania ryzykiem mógł skutecznie wpływać na poziom ryzyka i przeciwdziałać jego skutkom, oprócz wiedzy o możliwości wystąpienia danego czynnika, trzeba zdiagnozować wzrost prawdopodobieństwo lub fakt jego wystąpienia. Dopiero wtedy można rozpocząć przygotowane wcześniej działania zapobiegawcze lub kompensujące, ewentualnie wypracować nowe, adekwatne do zaistniałej sytuacji. 3. Identyfikacja wystąpienia czynników ryzyka Podstawową metodą identyfikacji wystąpienia czynników ryzyka jest określenie poziomu ryzyka związanego z każdym czynnikiem [Wysocki i McGary 2005; Pawlak 2006]. W praktyce wykorzystuje się w tym celu szacowania dokonywane przez zespół ekspertów, powoływany najczęściej spośród członków zespołu projektowego lub osób w inny sposób związanych z projektem. Na bazie wcześniej przygotowanych formularzy każdy z ekspertów określa prawdopodobieństwo wystąpienia i przewidywane konsekwencje dla każdego z czynników. W tych szacowaniach wykorzystywane są najczęściej skale trójstopniowe (słaby, średni, duży) lub czterostopniowe (znikomy, słaby, średni, duży). Po zebraniu danych od wszystkich członków zespołu są one poddawane obróbce statystycznej (najczęściej jest to średnia i średnia ważona), a rezultaty stanowią podstawę do prowadzenia dalszych działań8. W tym miejscu należy postawić dwa pytania: – czy tak prowadzona identyfikacja wystąpienia czynników ryzyka jest w stanie wykryć wszystkie interesujące nas zdarzenia? – czy zdarzenia te zostaną zidentyfikowane przed zaistnieniem ich negatywnych skutków? Odpowiedź na tak postawione pytania wydaje się jednoznacznie negatywna. Złożoność środowiska, w jakim jest realizowany projekt, powoduje, że nie można śledzić wszystkich zdarzeń zachodzących w tym środowisku, a w konsekwencji istnieje duża liczba zdarzeń, które umykają percepcji człowieka. Przykładem mogą być zjawiska zachodzące w otoczeniu zewnętrznym projektu. W drugiej połowie 8 Wartości otrzymane w wyniku szacowania poziomu ryzyka rozpoczynają dalsze działania w obszarze zarządzania ryzykiem. W pierwszej kolejności, stanowią one podstawę do szczegółowej analizy prowadzonej w gronie ekspertów (najczęściej tych samych, którzy brali udział w szacowaniu). Dane te są traktowane jako wskazówka, w jakich obszarach należy szukać zjawisk lub zdarzeń, które wykreowały oszacowany poziom ryzyka. W dalszej kolejności są wypracowywane i wdrażane w życie działania zapobiegawcze lub kompensujące. Kolejne okresowe szacowanie poziomu ryzyka weryfikuje te działania i cały cykl zaczyna się od początku..

(8) Dariusz Dymek. 28. lat 90. ubiegłego wieku znany światowy koncern branży informatycznej Motorola podjął decyzję o lokalizacji w Krakowie jednego ze swoich oddziałów, zajmujących się tworzeniem oprogramowania. Jednym ze skutków, jakie można było zaobserwować, był odpływ dużej liczby doświadczonych pracowników z wielu krakowskich firm informatycznych, zachęconych do zmiany pracy, prestiżem i warunkami pracy. W kilku wypadkach spowodowało to problemy z realizacją projektów przez firmy, z których pracownicy odeszli. Analiza przyczyn wysokiej rotacji wśród doświadczonych pracowników wraz z innymi informacjami (ich nowe miejsce zatrudnienia) pozwalają określić to zdarzenie jako czynnik ryzyka i podjąć działania zapobiegawcze, niemniej jednak dzieje się to przeważnie już po wystąpieniu zdarzenia. Inną przyczyną negatywnej odpowiedzi na postawione powyżej pytania jest fakt, że negatywne skutki mogą być wypadkową wielu pojedynczych zdarzeń, z których każdy z osobna może nie nieść ze sobą dużego zagrożenia dla danego projektu. Tabela 2. Wybrane czynniki ryzyka i ich skutki Lp.. Czynnik ryzyka. Skutki. 1. – rosnąca liczba błędów i czasochłonność ich usuwania Niewłaściwy dobór narzędzi TI – opóźnienia w realizacji harmonogramów. 2. Niestabilność wymagań projektowych (specyfikacji). 3. Niska stabilność zespołu projektowego. 4. Niespójny/nietrwały system prawno-gospodarczy. – zmiany zakresu prac („wyrzucanie gotowych elementów” i pojawianie się nieplanowanych zadań) – zmiany i opóźnienia w realizacji harmonogramów. – opóźnienia w realizacji harmonogramów – rosnąca liczba błędów i czasochłonność ich usuwania. – zmiany zakresu prac („wyrzucanie gotowych elementów” i pojawianie się nieplanowanych zadań) – zmiany i opóźnienia w realizacji harmonogramów. Źródła: opracowanie własne.. Przyczyną słabości prezentowanego podejścia, opartego na bezpośredniej identyfikacji czynników ryzyka, jest bazowanie jedynie na percepcji ekspertów. Jest to szczególnie niebezpieczne, gdy trudno zidentyfikować pojedyncze zdarzenie odpowiedzialne za zaistniałą sytuację oraz gdy negatywne zmiany w projekcie przebiegają stosunkowo powoli. W takiej sytuacji potrzebne jest narzędzie pozwalające śledzić stan projektu w zakresie ryzyka w sposób ciągły i w maksymalnym stopniu zobiektywizowany. Takim narzędziem może być metoda oceny ryzyka w projekcie informatycznym. Metoda ta jest rozszerzeniem koncepcji mierzenia właściwości oprogramowania wykorzystywanym na potrzeby oceny jakości oprogramowania i procesu jego tworzenia (software measurement framework) [Dymek 2007; Kan 2003]..

(9) Identyfikacja wystąpienia czynników…. 29. Punktem wyjścia proponowanej metody jest identyfikacja, w jaki sposób różne czynniki ryzyka manifestują swoje wystąpienie na poziomie projektu. Tabela 2 przedstawia zestawienie kilku wybranych czynników ryzyka oraz ich skutków widocznych na poziomie projektu. Analizując skutki wystąpienia czynników ryzyka, można zauważyć, że dla poszczególnych czynników występują różne, choć niejednoznaczne, objawy na poziomie projektu. Oznacza to, że na podstawie obserwacji skutków można próbować zidentyfikować ich przyczynę, czyli czynnik ryzyka. Ponadto skutki na poziomie projektu znacznie łatwiej poddają się próbie zobiektywizowanego pomiaru. Tabela 3 przedstawia przykładowe miary dla skutków zidentyfikowanych dla czynników ryzyka podanych w tabeli 2. Tabela 3. Przykładowe miary skutków czynników ryzyka Lp.. Kategoria pomiaru (skutek). 1. Liczba błędów. 2. Czas usuwania błędów. 3. Opóźnienia w realizacji harmonogramów. 4. 5. Zmiany harmonogramu. zmiany zakresu prac. Propozycje miar. – liczba błędów zgłaszanych okresowo / średnia liczba błędów zgłaszanych okresowo – liczba błędów nieusuniętych – średni czas od zgłoszenia do usunięcia błędu – maksymalny czas od zgłoszenia do usunięcia błędu. – liczba zrealizowanych zadań/liczba zaplanowanych zadań – sumaryczne opóźnienie w realizacji zadań (w stosunku do harmonogramu). – liczba zmian dokonanych w harmonogramie (wersji) – wielkość zmiany terminów w stosunku do pierwotnego harmonogramu (np. w dniach) – wielkość zmiany terminów w stosunku do poprzedniego harmonogramu. – liczba zmian specyfikacji (ile razy specyfikacja była zmieniana) – liczba zmian w specyfikacji (ile pozycji w specyfikacji uległo zmianie w stosunku do pierwotnej lub poprzedniej specyfikacji) – liczba zmian w specyfikacji wymagająca zmian w już wykonanych pracach. Źródła: opracowanie własne na podstawie: [Software Measurement Guide 1995; Practical Software Measurement… 1996; CMMI for Development 2006].. Jednym z kluczowych elementów jest fakt, że przedstawione miary wykorzystują obiektywne dane, które można uzyskać, opierając się na analizie dokumentacji projektowej. W konsekwencji uzyskiwane są obiektywne miary zjawisk zachodzących w projekcie. Ta cecha pozwala uniezależnić się od chwilowej interpretacji zachodzących zjawisk, a w szczególności wykrywać zjawiska zachodzące.

(10) 30. Dariusz Dymek. w dłuższym okresie („pełzające zmiany”). W ogólnym przypadku konstruując takie miary, należy zapewnić, aby: – dane wykorzystywane w procesie pomiaru pochodziły z niezależnych źródeł (np. dokumentacji projektowej) i miały charakter danych pierwotnych, tzn. niepoddawanych wcześniej przetwarzaniu i interpretacji, – źródła danych były odporne na potencjalną (niekoniecznie świadomą) manipulację wynikiem przez osoby zaangażowane w proces oceny ryzyka. W wyniku przeprowadzonej analizy powstaje lista zjawisk zachodzących w projekcie w rezultacie wystąpienia czynników ryzyka wraz ze zbiorem miar pozwalających na określenie ich poziomu. Jak wskazano, niektóre skutki mogą być wspólne dla kilku czynników ryzyka. Oznacza to, że nie są one wystarczające do jednoznacznej identyfikacji czynnika ryzyka, stanowią natomiast wskazanie do podejmowania dalszych analiz w tym zakresie. Jedną z możliwości udoskonalenia uzyskanego zestawu miar jest rozbudowanie go o miary związane bezpośrednio z czynnikami ryzyka. Chociaż w ogólnym wypadku czynniki ryzyka w projektach informatycznych są trudno mierzalne, to dla części z nich możliwe jest skonstruowanie miary przynajmniej częściowo spełniającej warunek nieopierania się na danych pochodzących z szacowań lub niemożności manipulacji danymi w procesie pomiaru. Przykładowo dla czynnika „stabilność zespołu projektowego” taką miarą może być liczba nieplanowanych zmian w składzie zespołu projektowego liczona okresowo. Aby skutecznie móc wykorzystać tak przygotowany zestaw miar w procesie identyfikacji wystąpienia czynników ryzyka, należy przestrzegać następujących zasad: – wyboru miar dokonujemy przed rozpoczęciem projektu. Zestaw miar nie powinien ulegać zmianie w trakcie projektu (poza ewentualną rozbudową), aby zapewnić porównywalność pomiarów przez cały czas trwania projektu; – każda miara musi być precyzyjnie zdefiniowana. W skład definicji wchodzi: opis miary, lista danych potrzebnych do obliczenia wartości, precyzyjny opis zasad obliczeń (np. kolejność działań), zasady prezentowania i interpretacji wartości; – pomiar odbywa się w cyklicznie, w stałych okresach (najlepiej liczonych np. w dniach roboczych, aby uniknąć wpływu dni wolnych od pracy na uzyskiwane rezultaty). Jeżeli z jakiś przyczyn jest to nie możliwe, wynik powinien być odpowiednio skorygowany, ale takie sytuacje powinny mieć charakter wyjątkowy; – proces gromadzenia danych powinien być wbudowany w procesy projektowe. O ile to możliwe dane nie powinny pochodzić z szacowań, a gdy nie można tego uniknąć, szacowanie nie powinno odbywać się bezpośrednio na potrzeby oceny ryzyka. Uzyskane dane pierwotne powinny być przechowywane jako część dokumentacji projektowej. Przedstawione wymagania gwarantują, że uzyskiwane rezultaty będą w znikomym stopniu podatne na (również niezamierzoną) manipulację. Jednocześnie.

(11) Identyfikacja wystąpienia czynników…. 31. wykorzystując tak przygotowany zestaw miar w wielu projektach, można uzyskać wspólną bazę danych umożliwiającą zarówno porównywanie projektów, jak i analizę korelacji między poszczególnymi miarami i czynnikami ryzyka. Wśród tych wymagań warto zwrócić uwagę na wymóg określenia zasad prezentacji i interpretacji danych. W wielu wypadkach znacznie istotniejszy od samej wartości miary jest jej trend analizowany z wykorzystaniem kilku pomiarów. Wartość traktowana nawet jako negatywna, jeżeli ulega systematycznej poprawie, może być interpretowana jako wartość pozytywna, gdyż wskazuje na stały spadek ryzyka w danym obszarze oraz podobnie, jeżeli wartość pozytywna jest elementem trendu spadkowego, może być sygnałem o pojawieniu się nowego czynnika ryzyka. Zaproponowany mechanizm pomiaru czynników ryzyka stanowi narzędzie do oceny aktualnego stanu projektu w kontekście oceny ryzyka projektowego. Ponieważ opiera się on na analizie stanu projektu, nie należy go traktować jako „systemu wczesnego ostrzegania”, chociaż głównie dzięki możliwości analizy trendów może on służyć do wykrywania negatywnych zjawisk, zanim osiągną one poziom krytyczny. Z tego powodu nie zastępuje on istniejących metod eksperckich, lecz stanowi ich uzupełnienie. Zestaw miar jest narzędziem wspierającym prace ekspertów, wskazując obszary, które wymagają bardziej szczegółowej analizy lub zwrócenia baczniejszej uwagi na nie w przyszłości. 4. Podsumowanie Zarządzanie ryzykiem w projektach informatycznych jest zadaniem trudnym i złożonym. Wysoki poziom złożoności produktu końcowego, jakim jest oprogramowanie komputerowe, jego niematerialny charakter, długi czas tworzenia i znacząca rola użytkowników w całym procesie jego powstawania, sprawiają, że konieczne jest zastosowanie metod systematycznych, opartych na maksymalnie zobiektywizowanych kryteriach. Współcześnie najczęściej wykorzystywanym podejściem jest metoda oparta na pracy ekspertów, którzy na podstawie wiedzy i doświadczenia przewidują, jakie czynniki ryzyka mogą wystąpić w projekcie (identyfikacja czynników), a w razie ich wystąpienia (identyfikacja wystąpienia czynnika ryzyka) wypracowują i wdrażają działania o charakterze kompensującym lub naprawczym. W pracy przedstawiono koncepcję metody opartej na pomiarze stanu projektu i poziomu wybranych czynników ryzyka, która ma na celu wsparcie ekspertów w procesie identyfikacji wystąpienia czynników ryzyka. Metoda ta nie ma na celu zastąpienia istniejących metod opartych na bezpośredniej ocenie ryzyka przez ekspertów, a jedynie wsparcie słabych stron tych metod (wyrażonych w pytaniach), w szczególności w wykrywaniu zjawisk o powolnym długofalowym charakterze..

(12) 32. Dariusz Dymek. Przedstawiona metoda jest rozwinięciem metod wykorzystywanych w procesie zarządzania jakością oprogramowania komputerowego opartych na koncepcji pomiaru właściwości produktu (oprogramowania) i procesu jego tworzenia (projektu). Dzięki temu jej wykorzystanie w praktyce nie powinno wymagać znaczących zmian w istniejących procesach projektowych. Literatura CMMI for Development [2006], ver. 1.2, Carnegie Mellon University, CMU/SEI2006-TR-008, August. Dymek D. [2008a], The Institutional Aspect of the Responsibility Distribution in the IT Enterprise, Proceedings of the IASTED International Conference on Internet and Multimedia Systems and Application, Innsbruck, Austria, 17–19 march 2008, ISBN 978-0-88986-727-7, Acta Press, Innsbruck. Dymek D. [2008b], Nieciągłość nadzoru w przedsięwzięciach informatycznych jako czynnik ryzyka, Zeszyty Naukowe Wyższej Szkoły Ekonomiczno-Społecznej w Ostrołęce, ISBN 1897-7391, nr 6, Ostrołęka. Kerzner H. [2005], Advanced Project Management, edycja polska, Helion, Kraków. Kuraś M., Zając A. [1999], Czynniki powodzenia i ryzyka projektów informatycznych, Zeszyty Naukowe Akademii Ekonomicznej nr 522, , Kraków. Pawlak M. [2006], Zarządzanie projektami, PWN, Warszawa. Practical Software Measurement – A Guide to Objective Program Insight [1996], Joint Logistic Commanders, Joint Group on System Engineering, U.S. Dept. of Defence, version 2.1. Software Measurement Guidebook [1995], Software Engineering Laboratory Series SEL94-102, NASA. Stabryła A. [2006], Zarządzanie projektami ekonomicznymi i organizacyjnymi, PWN, Warszawa. Szyjewski Z. [2001], Zarządzanie projektami informatycznymi, Placet, Kraków 2001. Identification of Risk Factors Occurrence in Information Technology Projects Identification of events (risk factors), which occur in a project or in its environment and can negatively influence the possibility of its realisation according to the presumptions, is an important aspect of risk management. Early detection and recognition of such incidents enable undertaking prevention and compensation activities sooner than their consequences significantly affect the project. The expert methods, utilised in this problem, may fail in case of phenomena that proceed slowly or result from a number of seemingly independent events. Therefore a tool, which supports experts’ efforts and allows detecting such phenomena earlier than their outcomes reach critical point, is necessary. The article submits an idea of a method allowing construction of a set of measures (indicators) that enable detection of such events on the basis of measuring the project parameters and.

(13) Identyfikacja wystąpienia czynników…. 33. selected risk factors. The proposed solution delivers an objective view on the project, useful for evaluation of project risk. Its results provide indications for further experts’ work. Key words: risk management, risk factors identification..

(14)