TOMASZ KOWALCZYK
Szkoła Główna Handlowa w Warszawie
Streszczenie
Niepowodzenia w realizacji przedsiĊwziĊü informatycznych, polegające na prze-kraczaniu zaplanowanego budĪetu, niedotrzymywaniu harmonogramu, oddawaniu oprogramowania o niedostatecznej jakoĞci, są powszechne. W miarĊ upływu lat sy-tuacja polepsza siĊ nieznacznie. Proponowanych jest wiele sposobów poprawy nie-korzystnej sytuacji. Jednym z nich jest promowanie dobrych praktyk zarządzania. W artykule opisane zostało badanie, którego celem było stwierdzenie, które z zasad zarządzania rekomendowanych w metodyce PRINCE2 mają najwiĊkszy wpływ na je-den z podstawowych parametrów sukcesu przedsiĊwziĊcia, jakim jest zgodnoĞü reali-zacji prac z zaplanowanym budĪetem.
Słowa kluczowe: zarzdzanie projektami informatycznymi, budet przedsiwzicia informatycz-nego, czynniki rodowiska wytwórczego oprogramowania, PRINCE2
1. Wprowadzenie
Jest niezaprzeczalnym faktem, e znaczna cz przedsiwzi informatycznych realizowa-nych na wiecie koczy si czciowym, a nawet całkowitym fiaskiem [10], [11], [12]. Przyczyn tak niekorzystnej sytuacji mona wyliczy wiele. Zwykle przyjło si uwaa, e nale do nich: niewłaciwe zarzdzanie projektem informatycznym, błdnie oszacowany budet i harmonogram przedsiwzicia, niekompetentni wykonawcy, przyczyny „polityczne” itp. W licznych ksikach dotyczcych omawianej kwestii, autorzy wskazuj na róne przyczyny problemu: DeMarco i Lister [3] ukazuj wag czynnika ludzkiego, Brooks [1] podkrela konieczno promowania wybitnych, wizjonerskich projektantów, potraficych porwa za sob pozostałych członków zespołu, Zahran [13] kładzie nacisk na podejcie procesowe. Z kolei remedium na niewłaciwe zarzdzanie realiza-cj przedsiwzicia informatycznego miały stanowi zasady zarzdzania projektem opracowane w Project Management Institute (PMI) i opublikowane jako Project Management Body of Knowled-ge (PMBOK) [8], jak i inne zbiory dobrych praktyk zarzdzania, jak PRINCE2 [7]. Czynniki techniczne – brak odpowiednio wydajnego sprztu, niedostatki dostpnych narzdzi programi-stycznych – które we wczesnych latach rozwoju informatyki wydawały si stanowi najpowaniej-sz barier, w latach póniejszych stały si nieistotne.
Wiele sporód powyszych diagnoz, chocia niewtpliwie słusznych, było wyłcznie spostrze-eniami poszczególnych autorów, którzy w swych publikacjach wyraali po prostu osobiste opinie i dowiadczenia. Ale od przynajmniej 15 lat prowadzone s naukowe badania, dziki którym daje si jednoznacznie stwierdzi, które czynniki rodowiska wytwórczego oprogramowania maj decydujcy wpływ na sukces przedsiwzicia informatycznego. Od 1995 r. instytut badawczy
Standish Group International publikuje wyniki bada, w których prezentowana jest lista najistot-niejszych czynników ograniczajcych lub podwyszajcych prawdopodobiestwo sukcesu przed-siwzicia informatycznego [10], [11], 12].
Celem niniejszej pracy jest zbadanie zalenoci pomidzy zasadami promowanymi we współ-czesnych metodach zarzdzania, stosowanych w przedsiwziciach informatycznych a jednym z podstawowych parametrów sukcesu przedsiwzicia, jakim jest zgodno realizacji prac z zaplanowanym budetem.
2. Czynniki sukcesu przedsiwzicia informatycznego
Jak wspomniano wyej, najpełniejsze, a jednoczenie systematyczne badania dotyczce czyn-ników, jakie decyduj o sukcesie przedsiwzicia informatycznego od lat przeprowadza Standish Group International [10], [11], 12]. Analiza wyników bada przeprowadzonych w okresie 10 lat 1995-2005 wykazuje do znaczn niezmienno tych czynników [2]. Do najwaniejszych czynni-ków sukcesu przedsiwzicia, od lat znajdujcych si w czołówce rankingu, mona zaliczy: 1. zaangaowanie uytkowników – projekty odgórnie narzucone przez kierownictwo,
nieakcepto-wane przez przyszłych uytkowników, maj nikłe szanse powodzenia; wiedza na temat infor-matyzowanych procesów i informatyki, jak zdobywaj uytkownicy podczas współpracy z pracownikami IT, jest nie do przeceniania [9, s. 28],
2. wsparcie kierownictwa – pozwala zdoby niezbdne zasoby, ułatwia równie osigniecie porozumienia w przypadku zaistnienia sytuacji konfliktowej wewntrz organizacji [9, s. 28], 3. jasno zdefiniowany zakres projektu – pozyskiwanie wymaga, ich analiza i specyfikowanie
s czsto postrzegane jako najtrudniejsze w całym cyklu realizacyjnym; niezalenie od tego, e wymaga znacznego zaangaowania wysokiej klasy specjalistów, to typowym problemem jest niestabilno wymaga, które nagminnie s zmieniane jeszcze w trakcie realizacji przedsi-wzicia [9, 31-32].
Wymienione trzy czynniki w cytowanych badaniach uzyskiwały po kilkanacie procent odpo-wiedzi. Inne czynniki sukcesu, w tym wymienione poniej, nie przekroczyły progu 10% odpowie-dzi: odpowied
4. krótsze harmonogramy z wiksz iloci kamieni milowych – czstsze kontrole, wynikajce z gsto rozmieszczonych kamieni milowych, działaj mobilizujco i pozytywnie wpływaj na zwikszenie prawdopodobiestwa ukoczenia przedsiwzicia w terminie [9, s. 33],
5. dowiadczony kierownik projektu – według bada, a 97% zakoczonych sukcesem projektów budowy oprogramowania miało dowiadczonych kierowników [9, s. 31],
6. jasno zdefiniowany proces zarzdzania projektem – pomaga wyeliminowa zbdne czynnoci, a na bieco korygowany prowadzi do cigłego doskonalenia procesu wytwórczego, a tym sa-mym do poprawy jakoci wytwarzanego oprogramowania [5],
7. jasno zdefiniowane cele projektu – na brak definicji celu przedsiwzicia najczciej wpływaj czynniki zwizane z funkcjonowaniem informatyzowanej organizacji, w tym polityka korpora-cyjna, priorytetyzacja zada, problemy zwizane z przepływami finansowymi lub restruktury-zacj, co utrudnia lub uniemoliwia zdefiniowanie konkretnych celów [9, s. 31],
8. wykorzystanie elementów powielarnych – prowadzi do zwikszenia stabilnoci i poprawy jakoci aplikacji, gdy elementy takie s dobrze przetestowane i zoptymalizowane; jednocze-nie wzrasta produktywno informatyków, którzy nie s zmuszani do ponownego pisania po-dobnych fragmentów kodu [9, s. 35-36].
3. Matryca elastycznoci projektu
Projekt mona okreli jako funkcjonujc w naturze tymczasow form organizacji rónego rodzaju zasobów. Zgodnie z definicj stosowan w jednym z uznanych na wiecie rodowisk zarzdzania, okrela si go jako:
„ rodowisko zarzdcze stworzone w celu dostarczenia jednego lub wikszej liczby produktów biznesowych zgodnie z okrelonym uzasadnieniem biznesowym” [7, s. 7].
Przeciwiestwem podejcia projektowego s natomiast procesy (operacje), które mona zdefi-niowa jako czynnoci o charakterze powtarzalnym. Obejmuj one zazwyczaj kompleksy działa nie ograniczonych czasowo. Powtarzaj czsto te same zestawy czynnoci i osigaj te same rezultaty. Celem operacji jest zatem zapewnienie cigłoci funkcjonowania organizacji.
Kady projekt o charakterze informatycznym osadzony jest w okrelonym rodowisku wy-twórczym, udostpniajcym konkretne zasoby, zarówno ludzkie, jak i sprztowe. Podobnie jak w przypadku produkcji wyrobów materialnych, tak i w projektach majcych na celu wytwarzanie oprogramowania naley zatem liczy si z ich ograniczeniami. Miar tych ogranicze jest matryca elastycznoci projektu, obejmujca takie parametry jak: zakres, czas, koszty oraz jako oprogra-mowania [5]. Relacje pomidzy tymi parametrami przedstawia si czsto w postaci iloczynu kartezjaskiego. Nie jest bowiem moliwe podstawienie wartoci tych czterech elementów do klasycznego równania i przeprowadzenie realnych oblicze matematycznych.
ZAKRES := X(CZAS, KOSZT, JAKO)
• ZAKRES formułuje si poprzez okrelenie produktów, które maj by efektem realizacji projektu oraz celów, które rzeczone produkty pomagaj osign.
• CZAS realizacji projektu formułuje si, jako całkowity czas potrzebny do wytworzenia jego produktów, a tym samym do osignicia stawianych przed nim celów.
• KOSZT realizacji przedsiwzicia formułuje si, jako całkowity koszt wytworzenia produk-tów projektu, obejmujcy zarówno koszty bezporednie, jak i porednie.
• JAKO odnosi si do wymaga stawianych przed projektowanym systemem informatycz-nym i dotyczy zazwyczaj jego funkcji lub wydajnoci. Jest to element matrycy elastycznoci projektu, który powica si w pierwszej kolejnoci, gdy projekt nie mieci si w harmono-gramie lub ma kłopoty z funduszami.
Z przedstawionego powyej zwizku wynika, i zwikszenie zakresu przedsiwzicia bdzie skutkowało koniecznoci modyfikacji przynajmniej jednego z trzech pozostałych elementów matrycy, znajdujcych si po drugiej stronie równania. Trzeba bdzie zatem powici wicej czasu na realizacj przedsiwzicia lub zwikszy jego budet. W szczególnych przypadkach konieczne bdzie zwikszenie obydwu omawianych parametrów. Alternatywnie, zwikszenie zakresu projektu bez moliwoci wydłuenia czasu realizacji prac lub podniesienia jego kosztów, spowoduje konieczno obnienia jakoci poszczególnych produktów. Wniosek z tego jest nast-pujcy: nie mona wstpnie zdefiniowa wszystkich czterech zmiennych matrycy elastycznoci projektu; aby obliczenia za pomoc iloczynu kartezjaskiego dały rozsdny rezultat, musi on zawiera przynajmniej jedn zmienn.
W rzeczywistym rodowisku biznesowym zdarza si jednak niestety, e wraz z otrzymaniem przedsiwzicia do realizacji, kierownik dowiaduje si, co ma by wykonane (tj. zakres), jak szybko naley to zrobi (tj. czas), jaki bdzie budet (tj. koszt) oraz jakie funkcjonalnoci ma
oferowa projektowany system informatyczny (tj. jako). Jest to najlepsza z moliwych recepta na katastrof. Sposobem eliminacji tego ryzyka moe by iteracyjne podejcie do szacowania złoo-noci przedsiwzicia i odpowiednio czste prezentowanie danych na forum zespołu zarzdzania projektem (np. komitetu sterujcego) [9, s. 37-38.].
4. Zastosowanie metodyki zarzdzania projektami
Do najczstszych powodów niepowodze w realizacji projektów o charakterze informatycz-nym mona zaliczy [7, s. 1-2.]:
• brak wiedzy na temat aktualnoci uzasadnienia biznesowego,
• brak wytycznych dotyczcych jakoci poszczególnych produktów projektu, • brak porozumienia z interesariuszami w zakresie definicji rezultatów projektu, • brak jasno zdefiniowanej struktury zarzdzania projektem,
• niskiej jakoci szacowania dotyczce czasu trwania oraz kosztów projektu, • nieodpowiednie planowanie i koordynacja zasobów,
• braki i niedocignicia w obszarze monitorowania postpów prac, • brak zastosowania mechanizmów kontroli jakoci.
Bez metodycznego podejcia do zarzdzania projektami, interesariusze bd mieli róne wy-obraenia o strukturze projektu oraz o stanie realizacji poszczególnych zada. Zainteresowani nie bd pewni, jakie s ich obowizki, jakie posiadaj uprawnienia i za co odpowiadaj. Rezultatem bdzie pogłbianie si chaosu w strukturach oraz najbliszym otoczeniu projektu, a pochodn tego stanu bdzie najczciej przekroczenie terminu realizacji prac oraz granic dopuszczalnych kosztów – twierdzenie to odnosi si szczególnie do duych projektów [7, s. 2].
W ostatnich dwóch dekadach rynek uzyskał znaczc wiadomo moliwoci, jakie oferuje podejcie projektowe w obszarze wprowadzania zmian biznesowych. Organizacje uwiadomiły sobie korzyci, które moe przynie jedna, wspólna, strukturalna metodyka zarzdzania projekta-mi. Zrozumiały wag jej powtarzalnoci oraz moliwoci łatwego przekazywania wiedzy na jej temat. Jej elementy sterowania, pro-aktywno oraz trzon merytoryczny oparty na dowiadczeniach stały si dla współczesnego biznesu godne zaufania. Znaczcym atutem takiego podejcia jest równie jego uniwersalno. Moe by ono bowiem stosowane w przypadku projektów o charakterze samodzielnym, ale równie i takich, które maj zwizki z innymi projektami lub s czci wikszych programów. Metodyka zarzdzania projektami umoliwia organizacji kontrolo-wane zarzdzanie zmian, jak równie aktywne zaangaowanie uytkowników i interesariuszy w całym cyklu ycia projektu, zapewniajc tym samym, e produkty spełni wymagania bizneso-we, funkcjonalne i rodowiskowe. Kierownictwo projektu oraz organizacji uzyskuje w ten sposób korzyci poprzez kontrolowane uycie zasobów i umoliwienie skuteczniejszego zarzdzania ryzykiem. Obowizki w projekcie przydzielane s w sposób formalny, co pozwala na pełn kon-centracj mocy wytwórczych na tym, co projekt ma dostarczy, dlaczego, kiedy i komu.
Wymienione powyej korzyci odnosz si w zasadzie do wszystkich uznanych na wiecie me-todyk zarzdzania projektami (np. PMI, PRINCE2, itd.). Czsto mona napotka zmienno w obszarze słownika poj wykorzystywanych w konkretnym rodowisku. Sens i istota stosowania dobrych praktyk z tej dziedziny jest jednak we wszystkich omawianych przypadkach identyczna.
5. Opis badania
W ramach niniejszego artykułu została podjta próba analizy wyników bada ankietowych przeprowadzonych w wybranych przedsibiorstwach sektora prywatnego oraz organizacjach administracji pastwowej, posiadajcych własne słuby informatyczne lub korzystajcych w tym obszarze z usług i wsparcia firm trzecich. W całym badaniu wzito pierwotnie pod uwag 60 osób. Finalnie uzyskano odpowiedzi od 46 respondentów, reprezentujcych 9 funkcjonujcych na rynku polskim obiektów gospodarczych.
Za główny problem badawczy przyjto prób okrelenia, które z parametrów rodowiska wy-twórczego oprogramowania, sugerowanych w dobrych praktykach zarzdzania (np. PRINCE2), maj najwikszy wpływ na stabilno budetu przedsiwzicia informatycznego. Z metodycznego punktu widzenia badania zostały przeprowadzone w pierwszej kolejnoci za pomoc liniowego modelu prawdopodobiestwa w którym analizowane były relacje pomidzy zmienn objanian y (tj. budetem projektu) a zmiennymi objaniajcymi x1, x2, …, xk (tj. praktykami zarzdzania). Wszystkie zastosowane w modelu zmienne, zarówno endogeniczna, jak i egzogeniczne, miały charakter zerojedynkowy. Dlatego te model przyjł zwykłe równanie regresji o postaci:
. n ...., , 2 , 1 i dla x ... x x yi= β0 +β1 1 +β2 2 + +βk k +εi =
Biorc jednak pod uwag fakt, i zmienna objaniana mogła przyjmowa potencjalnie warto-ci spoza dyskretnego przedziału od 0 do 1, lepszym rozwizaniem okazało si zastosowanie modelu regresji logistycznej [6, s. 371-374].
ε α α α α + + + + + = = − = 9 9 2 2 1 1 0 ... ) 1 ( 1 ) 1 ( ln X X X Y P Y P
Podejcie takie pozwoliło na okrelenie zachowania si zmiennej objanianej w zakresie po-midzy wartociami 0 i 1, wskazujc wpływ parametrów rodowiska wytwórczego oprogramowa-nia na szans zakoczeoprogramowa-nia projektu, zgodnie z wczeniej zdefiniowanymi tolerancjami finansowy-mi. Zmienna objaniana nazwana została w tym przypadku logitem, czyli logarytmem ilorazu szans zajcia badanego zdarzenia w stosunku do sytuacji jego nie zajcia. W modelu logitowym logarytm ilorazu szans jest liniow funkcj zmiennych objaniajcych, natomiast w liniowym modelu praw-dopodobiestwa tak funkcj było samo prawdopodobiestwo Pi. Parametry równania szacuje si metod najwikszej wiarygodnoci, która polega na wyznaczeniu takich ocen parametrów modelu, które maksymalizuj statystyczn wiarygodno próby. W przypadku logitu, okrelajcego warto-ci prawdopodobiestw wystpienia zjawiska pod wpływem rónych kombinacji zmiennych niezalenych, poziom tego ryzyka mona szacowa, posługujc si wzorem:
) ... exp(α0 α1X1 αkXk ψ = + + + w którym
e
j αwyraa przyrost ryzyka wzgldnego w wyniku działania czynnika opisywanego przez zmienn Xj. Warto t interpretuje si porównujc z wartoci 1, a uzyskan rónic wyraa
si w procentach. Oszacowane, zgodnie z powyszymi załoeniami oceny parametrów równania logistycznego posiadaj nastpujc interpretacj [6, rozdz. 8.9]:
• gdy wynik z próby wskazuje, e
e
jα
> 1, to uznaje si, e czynnik opisywany przez zmienn Xj działa stymulujco na prawdopodobiestwo (moliwo) wystpienia badanego zjawiska,
• gdy wynik z próby wskazuje, e
e
jα
< 1, to uznaje si, e czynnik opisywany przez zmienn Xjdziała ograniczajco na prawdopodobiestwo wystpienia badanego zjawiska,
• gdy wynik z próby wskazuje, e
e
jα
= 1, to uznaje si, e czynnik opisywany przez zmienn Xjnie ma wpływu na prawdopodobiestwo (moliwo) wystpienia badanego zjawiska.
W tablicy 1 zostały przedstawione wyniki estymacji (zrealizowanej za pomoc narzdzia GRETL), w której badaniom poddano wybrane parametry zarzdzania (pełen opis dostpny w załczniku), sklasyfikowane w pierwszej kolejnoci na podstawie subiektywnej oceny ich wpływu na budet projektu informatycznego, a nastpnie na podstawie eliminacji pod wpływem ich istot-noci statystycznej (tj. wartoci statystyki t oraz prawdopodobiestwa popełnienia błdu).
Tabela 1. Estymacja Logit z wykorzystaniem 46 obserwacji 1-46. Zmienna zaleĪna: Y2 (budĪet)
Zmienna Współczynnik Błąd stand. Statystka t Efekt kraĔc.
const -4,72231 2,19906 -2,147 B_Pyt3 (x3) -2,03826 1,86347 -1,094 -0,125284 B_Pyt8 (x8) 1,46168 1,65829 0,881 0,0898444 H_B_Pyt10 (x10) 3,49853 1,43218 2,443 0,215042 H_B_Pyt12 (x12) 3,79139 1,91574 1,979 0,233043 H_B_Pyt21 (x21) 3,86122 1,10851 3,483 0,237335 H_B_Pyt23 (x23) -5,91674 2,29714 -2,576 -0,363681 B_Pyt25 (x25) 4,16903 2,42389 1,720 0,256255 rednia dla zmiennej Y2_BUDZ_ = 0,739
Liczba przypadków poprawnej predykcji = 44 (95,7%) Liczba przypadków błdnej predykcji = 2 (4,3%) f(beta'x) do rednich niezalenych zmiennych = 0,061 McFaddena pseudo-R-kwadrat = 0,587574
Logarytm wiarygodnoci = -10,889
Test ilorazu wiarygodnoci: Chi-kwadrat(7) = 31,0267 (warto p 0,000061) ródło: Opracowanie własne.
W kategoriach formalnych, pierwszym z badanych parametrów decydujcych o dopasowaniu modelu był parametr McFaddena pseudo-R-kwadrat. W zrealizowanej estymacji przyjł on war-to 0.587574. Oznacza to, e model wyjania około 59% zmiennoci logitów. Ze statystycznego punktu widzenia jest to zatem wynik dobry, a na jego podstawie mona oceni przydatno oraz poprawno modelu. Drugim z parametrów decydujcych o dopasowaniu estymacji była liczba przypadków poprawnej predykcji. W badanym modelu przyjła ona warto 44 z 46 obserwacji, czyli 95,7% wszystkich przypadków. Oznacza to, e zaobserwowano bardzo du ilo popraw-nych prognoz w stosunku do obserwacji empiryczpopraw-nych. Trafno działania modelu okazała si zatem wysoka.
Kierunek oddziaływania poszczególnych parametrów strukturalnych modelu na zmienn en-dogeniczn w wikszoci sytuacji zwikszał prawdopodobiestwo zachowania tolerancji czaso-wych projektu. Punktem wyjcia do właciwej interpretacji wartoci uwzgldnionych zmiennych było ich przekształcenie przez funkcj exp, gdzie e=~2.718282, a parametr równał si wartoci współczynnika przy danym parametrze strukturalnym.
Tabela 2. Przekształcenia wartoĞci przy parametrach modelu przez funkcjĊ eksponencjalną
Zmienna Współczynnik ea const -4,72231 0,008895 B_Pyt3 (x3) -2,03826 0,130255 B_Pyt8 (x8) 1,46168 4,3132 H_B_Pyt10 (x10) 3,49853 33,06681 H_B_Pyt12 (x12) 3,79139 44,31796 H_B_Pyt21 (x21) 3,86122 47,52329 H_B_Pyt23 (x23) -5,91674 0,002694 B_Pyt25 (x25) 4,16903 64,65271
ródło: Opracowanie własne.
Stosujc zatem kompleksowe podejcie do analizy zmiennych objaniajcych mona stwier-dzi, e do grupy parametrów charakteryzujcych si zarówno wysok istotnoci statystyczn, jak równie wysokim poziomem stymulacji prawdopodobiestwa wystpienia badanego zjawiska naleały:
1. Zmienna H_B_Pyt21, odpowiadajca na pytanie, czy odpowiedzialno za poszczególne zadania lub produkty projektu została delegowana na kierowników zespołów realizacyjnych lub inne dedykowane osoby. Statystyka t osignła w tym przypadku najwysz w modelu warto co do modułu równ 3.483, przy jednoczesnej najniszej wartoci błdu standardowe-go, szacowanego na 1.10851. Wyniki badania wskazuj zatem na bardzo wysok wag odpo-wiedniego delegowania odpowiedzialnoci za realizacj poszczególnych produktów projektu. 2. Zmienna H_B_Pyt10, odpowiadajca na pytanie, czy w pocztkowych etapach
przedsiwzi-cia zdefiniowano hierarchi produktów projektu. W tym przypadku statystyka t osignła war-to bezwzgldn równ 2.443, przy jednoczesnej wartoci błdu standardowego na poziomie 1.43218. Jest to zatem kolejne potwierdzenie niepodwaalnej wagi, jak naley przyłoy do definicji produktów projektu na etapie jego inicjalizacji.
3. Zmienna H_B_Pyt12, odpowiadajca na pytanie, czy w pocztkowych etapach realizacji przedsiwzicia zdefiniowano list działa majcych na celu wytworzenie poszczególnych produktów projektu. Statystyka t osignła w tym przypadku warto co do modułu równ 1.979, przy jednoczesnej wartoci błdu standardowego na poziomie 1.91574. W aspekcie merytorycznym waga badanego parametru jest zatem nie do przecenienia. Wskazuje bowiem na bezporedni relacj pomidzy produktami projektu, a list czynnoci, niezbdnych do ich wytworzenia.
4. Zmienna H_B_Pyt25, odpowiadajca na pytanie, czy przed zamkniciem przedsiwzicia nastpiło formalne potwierdzenie moliwoci eksploatacji systemu przez odpowiednie słuby utrzymania. W tym przypadku statystyka t osignła warto bezwzgldn równ 1.720, przy jednoczesnej wartoci błdu standardowego na poziomie 2.42389. Jak wida z bada okrele-nie warunków utrzymania systemu naley do cisłej czołówki parametrów rodowiska wy-twórczego, które mog wpłyn na budet przedsiwzicia.
5. Zmienna B_Pyt8, odpowiadajca na pytanie, czy w ramach badanego przedsiwzicia został ustalony system zapewnienia jakoci. Statystyka t osignła w tym przypadku warto co do modułu równ 0.881, przy jednoczesnej wartoci błdu standardowego na poziomie 1.65829. Wartoci te ze statystycznego punktu widzenia s najnisze w całym badanym modelu, dlatego te interpretacja zmiennych moe by obarczona błdem. Analizujc jednak kwesti jakoci systemów informatycznych, mona stwierdzi, e odpowiedni system wspierajcy produkcj oprogramowania, nie bdzie ograniczał moliwoci utrzymania projektu w załoonym bude-cie.
Pozostałe parametry modelu znalazły si natomiast na drugim biegunie, ograniczajc prawdo-podobiestwo wystpienia badanego zjawiska. Ich interpretacja w kontekcie wpływu na pierwotny budet przedsiwzicia sprowadza si zatem do koniecznoci uruchomienia i wykorzystania odpowiednich rezerw, okrelonych w ramach tolerancji finansowych projektu.
6. Wnioski
Zgodnie z wynikami przeprowadzonych bada, najwaniejszym z parametrów rodowiska wy-twórczego oprogramowania, wpływajcym na budet przedsiwzicia okazał si parametr opisuj-cy odpowiedzialno za dostarczenie poszczególnych produktów projektu. Uzyskał on jedn z najwyszych ocen wpływu na zmienn objanian, zarówno w perspektywie istotnoci staty-stycznej, jak i poziomu stymulacji prawdopodobiestwa wystpienia badanego zjawiska. Obserwa-cja ta okazała si w szerszym spojrzeniu zbiena z wynikami bada opublikowanymi w The Chaos Raport [10], który pozycjonuje podobne parametry w pierwszej dziesitce najistotniejszych czyn-ników decydujcych o sukcesie przedsiwzicia informatycznego. Znacznie wysza korelacja bada wystpowała natomiast w przypadku parametrów opisujcych hierarchi produktów projek-tu. Precyzyjna i jasna definicja wymaga została w [10] sklasyfikowana w pierwszej trójce naj-waniejszych czynników sukcesu. W dalszej kolejnoci wysoki wpływ na badany element matrycy elastycznoci projektu wykazywał parametr opisujcy list działa niezbdnych do wytworzenia produktów projektu. Koresponduje on w swym zakresie informacyjnym z identyfikowanym w [10] czynnikiem dotyczcym właciwego planowania. Brak wród wyników bada cisłego wskazania na wag uczestnictwa w przedsiwziciu uytkowników projektowanego systemu spowodowane by moe specyficzn konstrukcj oraz zawartoci informacyjn zmiennych egzogenicznych. W przypadku pozostałych zmiennych istotno statystyczna uzyskana w modelu regresji nie była wystarczajca do rzetelnej oceny ich wpływu na zmienn objanian.
Opierajc si zatem na interpretacji parametrów istotnych ze statystycznego punktu widzenia mona zauway, e istot dobrego zarzdzania projektem informatycznym jest poprawna defini-cja jego zakresu, sprowadzajca si najczciej do okrelenia wszystkich produktów przedsiwzi-cia, czynnoci oraz odpowiedzialnoci za ich wytworzenie.
Starajc si jednak zrozumie przyczyn tak czstego wystpowania niskiej istotnoci staty-stycznej pozostałych zmiennych egzogenicznych, naley na pocztku okreli charakter zjawiska,
jakim jest projekt informatyczny. Analiz problemu mona rozpocz od przyporzdkowania do niego odpowiedniego typu układu dynamicznego. Najbliszy istocie budowy oprogramowania wydaje si by układ chaotyczny, stanowicy porednie ogniwo midzy układami rozwizywalny-mi, a układami całkowicie stochastycznymi. Układy chaotyczne wykazuj bowiem właciwoci charakterystyczne zarówno dla układów deterministycznych, jak i probabilistycznych. W przypad-ku projektów informatycznych moliwe jest okrelenie pewnych algorytmów zachowa oraz parametrów ograniczajcych prace projektowe. Nie jest jednak moliwe zaplanowanie wszystkich zdarze oraz czynników wpływajcych na rodowisko wytwórcze oprogramowania. Rozsdne prognozowanie jest zatem moliwe jedynie w krótkim horyzoncie czasowym, co jest zbiene z istot zachowania układów chaotycznych. Podobne zalenoci mona zauway, analizujc kwesti definiowania warunków pocztkowych projektu, co w obszarze układów chaotycznych opisywane jest tak zwanymi wykładnikami Lapunowa. Teoria ta wie si równie z pojciem dziwnego atraktora, bdcego jedynym bytem w przestrzeni fazowej badanego zjawiska, który (jeli si go odnajdzie) jest w stanie wyznaczy przyblione zachowania układu w dłuszym horyzoncie czasowym [4, s. 250-257].
Analiza trajektorii zachowa chaotycznych, a tym samym poszukiwania dziwnych atraktorów s by moe jedynym rozwizaniem problemu opanowania sztuki realizacji projektów informa-tycznych w sposób zbliony do operowania w rodowisku układów determinisinforma-tycznych.
Bibliografia
1. Brooks F.P. Jr.: Mityczny osobomiesic. Eseje o inynierii oprogramowania, WNT, Warszawa 2000.
2. Czarnacka-Chrobot B.: Typowe czynniki niepowodzenia w realizacji informatycznych przedsiewziec projektowych - spojrzenie Standish Group. W: Dylematy zarzadzania projektem informatycznym, red. M. Miłosz, J.K. Grabara, Polskie Towarzystwo Informatyczne, Katowice 2006, s. 77-104.
3. DeMarco T., Lister T.: Czynnik ludzki. Skuteczne przedsiwzicia i wydajne zespoły, WNT, Warszawa 2002.
4. Inteligentne systemy w zarzdzaniu, red. J. Zieliski, WN PWN, Warszawa 2000. 5. Kobyliski A.: Modele jakoci produktów i procesów programowych, OW SGH,
Warszawa 2005.
6. Maddala G.S.: Ekonometria, WN PWN, Warszawa 2006.
7. OGC: PRINCE2. Skuteczne zarzdzanie projektami, Londyn 2006.
8. PMI: A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3rd ed., 2004.
9. Snedaker S., Zarzdzanie projektami IT w małym palcu, Helion, Gliwice 2007. 10. Standish Group International: The Chaos Report, West Yarmouth (MA) 1995. 11. Standish Group International: Extreme Chaos, West Yarmouth (MA) 2001.
12. Standish Group International: The Chaos Chronicles Version 3.0., West Yarmouth, 2003. 13. Zahran S.: Software Process Improvement. Practical Guidelines for Business Success,
Załącznik. Lista zastosowanych w badaniu zmiennych endogenicznej i egzogenicznych
BUDZ (Y2):
Czy badane przedsiwzicie zostało ukoczone zgodnie z planowanym budetem?
H_B_Pyt1 (x1):
Czy badane przedsiwzicie było inicjowane formalnym zleceniem przygotowania projektu?
H_B_Pyt2 (x2):
Czy na podstawie dokumentu inicjujcego projekt została okrelona złoono oraz zakres planowanego przedsi-wzicia?
B_Pyt3 (x3):
Czy dokumentacja ródłowa zawierała informacje o biznesowym uzasadnieniu przedsiwzicia?
H_B_Pyt5 (x5):
Czy struktura organizacyjna przedsiwzicia zakładała istnienie i funkcjonowanie nadzoru projektowego?
H_B_Pyt7 (x7):
Czy na etapie przygotowania przedsiwzicia został utwo-rzony i inicjalnie zasilony danymi rejestr ryzyk i ograni-cze projektowych? B_Pyt8 (x8):
Czy w ramach badanego przedsiwzicia został ustalony system zapewnienia jakoci?
H_B_Pyt9 (x9):
Czy w ramach badanego przedsiwzicia został przygo-towany szczegółowy plan projektu?
H_B_Pyt10 (x10):
Czy w pocztkowych etapach przedsiwzicia zdefiniowano hierarchi produktów projektu?
B_Pyt11 (x11):
Czy opisy poszczególnych produktów projektu wskazy-wały na ich wzajemne zale-noci?
H_B_Pyt12 (x12):
Czy w pocztkowych etapach przedsiwzicia zdefiniowano list działa majcych na celu wytworzenie poszczególnych produktów projektu?
H_B_Pyt15 (x15):
Czy w ramach prac nad harmonogramem projektu oraz struktur zespołu zarzdzania projektem dokonano weryfi-kacji dostpnoci zasobów niezbdnych do realizacji przedsiwzicia?
H_B_Pyt18 (x18):
Czy w organizacji, w której realizowano przedsiwzicie obowizywał jasno zdefiniowa-ny proces wspierajcy zarz-dzanie projektami informatycz-nymi?
B_Pyt19 (x19):
Czy architektura projektowa-nego systemu zakładała wykorzystanie komponentów powielarnych?
H_B_Pyt21 (x21):
Czy odpowiedzialno za poszczególne zadania lub produkty badanego projektu została delegowana na kierow-ników zespołów realizacyjnych lub inne dedykowane osoby?
H_B_Pyt22 (x22):
Czy w trakcie realizacji poszczególnych etapów przedsiwzicia aktualizowa-no najwaniejsze rejestry projektowe?
H_B_Pyt23 (x23):
Czy kady etap przedsiwzicia koczył si formalnym odbio-rem produktów czstkowych projektu?
H_B_Pyt24 (x24):
Czy przed zamkniciem przedsiwzicia nastpiła formalna akceptacja wszyst-kich głównych produktów projektu?
B_Pyt25 (x25):
Czy przed zamkniciem przedsiwzicia nastpiło formalne potwierdzenie moliwoci eksploatacji systemu przez odpowiednie słuby utrzymania?
H_B_Pyt26 (x26):
Czy po zakoczeniu prac w ramach głównego nurtu projektowego, został opraco-wany raport kocowy oraz plan działa nastpczych?
THE IMPACT OF GOOD MANAGEMENT PRACTICES ON SOFTWARE PROJECT BUDGET
Summary
Developing good quality software on time and within budget represents a diffi-cult challenge for many organizations. Over the years the situation improved slightly. There are many proposed ways to improve the disadvantaged. One of them is to promote good management practices. The purpose of the study described in the paper was to determine which of the principles recommended in the project man-agement methodology PRINCE2 have the greatest impact on one of the key parame-ters of success of the project: compliance with budget plan.
Keywords: software project management, software project budget, factors of software develop-ment environdevelop-ment, PRINCE2
Andrzej Kobyliski Tomasz Kowalczyk Szkoła Główna Handlowa
02-554 Warszawa, Al. Niepodległoci 164 e-mail: andrzej.kobylinski@sgh.waw.pl