Inteca

Analiza wymagań jako klucz do redukcji ryzyka

2016.05.10

W rozmowach z naszymi klientami lub partnerami, często poruszamy problem ryzyka w projektach informatycznych czy też zagadnień związanych z budowaniem przewidywalności przedsięwzięć opartych o zmiany w IT. To, co najbardziej w tych dyskusjach zaskakuje to podejście do analizy wymagań w kontekście zarządzania ryzykiem przedsięwzięcia.

Aby dobrze zdefiniować zagadnienie, rozważmy klasyczny problem szacowania kosztu, czasu oraz zakresu na poziomie planowania inwestycji. Naturalnym jest, iż każda organizacja chce znać te parametry przed podjęciem decyzji o uruchomieniu danej inicjatywy. Co zastanawia to fakt, iż często decyzje takie podejmowane są na podstawie informacji o bardzo wysokiej niepewności, bez wykorzystania współczesnych metod minimalizacji ryzyka i definicji istotnych cech przedsięwzięcia.

Jednym z klasycznych przykładów takiego działania jest budowanie postępowań przetargowych w modelu stałej ceny (tzw. Fixed-price) w oparciu o wstępną listę wymagań biznesowych z założeniem, iż analizę wymagań (pomijając zagadnienia pełnej analizy biznesowej, bo to materiał na osobny artykuł) przeprowadza dostawca, który wygrał postępowanie. Zasadniczo problemem jest tutaj kwestia konfliktu interesów pomiędzy celami analityka – spełnienie celów biznesowych a celem dostawcy – wdrożenie rozwiązania w estymowanym budżecie. W praktyce najczęściej można mieć pewność, iż projekt końcowego rozwiązania będzie odpowiadać temu, co założył i estymował na etapie postępowania zakupowego, a w konsekwencji sprzedał dostawca, nie zawsze spełniając cele zamawiającego.
Oczywistym powodem takiego postępowania jest fakt, iż na etapie koncepcji biznesowej czy też zestawu życzeń wobec nowego rozwiązania, bez usystematyzowanego opisu i jego specyfikacji bardzo trudno jest przyjąć poprawne założenia co do zakresu, czasu trwania oraz ceny. Konsekwencją tego a zarazem częstym problemem obserwowanym w wielu organizacjach jest duża rozpiętość cenowa ofert dostawców, której nie da się jednoznacznie uzasadnić obiektywnymi przesłankami (np. koszty licencji).

Aby lepiej zobrazować ten problem, przyjrzyjmy się zagadnieniu stożka niepewności („The cone of uncertainity”), które jako pierwszy konceptualnie zdefiniował Barry Boehm w opisie estymacji projektów metodą COCOMO II*, walidując je później empirycznie na podstawie badań licznych projektów w US AirForce oraz NASA . Nazwy „The cone of uncertainity” dla zdefiniowania koncepcji Boehma jako pierwszy użył Steve McConnell**.

Software Estimation Demystifying the Black Art

Źródło: „Software Estimation: Demystifying the Black Art.”, S. McConnell, Microsoft Press, 2006

 

Stożek przedstawia wykres niepewności estymacji projektu mierzonej, jako poziom niedoszacowania lub przeszacowania na kolejnych etapach projektu. Kształt stożka jest raczej intuicyjny, jednak to co istotne i godne dyskusji to zbadane wartości wskaźników niepewności. Jak widać, na etapie koncepcji rozwiązania, współczynnik niepewności wynosi 4 x. Co oznacza, iż średnio dostawca jest w stanie 4-krotnie zawyżyć (estymacja na poziomie 400% oryginalnego rozmiaru) lub zaniżyć (estymacja na poziomie 25% oryginalnego rozmiaru) rozmiar projektu.  Co ciekawe wiele organizacji rozpoczyna negocjacje projektów stałej ceny z dostawcami właśnie na tym etapie przedsięwzięcia. Doskonale tłumaczy to efekt znaczącej rozbieżności wycen na poziomie ofert, a co gorsza pokazuje poziom ryzyka z jakim musi liczyć się zamawiający w momencie zawierania umowy (Aby lepiej uzmysłowić sobie skalę problemu, proponujemy przemnożyć przez podane wskaźniki budżet ostatniego Państwa projektu). Podejście takie skutkuje szeregiem problemów, które są naturalną konsekwencją braku wspólnej definicji zakresu między stronami; do głównych z nich należą:

  • Zmniejszenie zakresu dostarczonego rozwiązania,
  • Re-negocjacje ceny w trakcie wdrożenia,
  • Wydłużenie czasu projektu wskutek zmienności wymagań,
  • Brak spełnienia kluczowych wymagań,
  • Brak spełnienia zakładanych celów biznesowych

Analizując dalej przebieg stożka niepewności, na uwagę zasługują dwa fakty. Zakończenie etapu analizy wymagań redukuje wskaźnik niepewności do poziomu 1.5, a zdefiniowanie interfejsu użytkownika zmniejsza go do poziomu 1.25, który stanowi poziom ryzyka, z którym poradzi sobie większość dobrych project managerów, doprowadzając przedsięwzięcie do sukcesu.

Obserwacje na temat roli projektu interfejsu użytkownika na etapie analizy wymagań i definicji rozwiązania zdają się być potwierdzane przez wielu analityków, którzy chętnie włączają to narzędzie do swojego warsztatu pracy. Nasze doświadczenia w Inteca również potwierdzają istotę tego elementu, dlatego zalecamy stosowanie projektu interfejsów użytkownika na etapie walidacji wymagań, np. podczas Structured Walthrough lub Business Process Walkthrough (Istotę sukcesu stanowi tutaj jednak odpowiednie ujęcie problemu, skupiając uwagę interesariuszy biznesowych na pytaniach kategorii „CO?” a nie „JAK?”).

Podsumowując przytoczone powyżej rozważania, analiza biznesowa, czy też analiza wymagań są istotnymi elementem wpływającym na redukcję ryzyka realizowanego przedsięwzięcia. Istotne jest zatem aby decyzje o uruchomieniu projektu lub wyborze dostawcy podejmować po wykonaniu tych aktywności.

Co ciekawe, mimo iż większość naszych rozmówców zgadza się z tą tezą, w praktyce nadal wiele organizacji funkcjonuje w modelu wyceny i decyzji o uruchomieniu projektów na podstawie ogólnych założeń, zarówno w przypadku projektów wewnętrznych jak i tych realizowanych przez zewnętrznych dostawców. Obrazując tą sytuację, często lubimy operować analogią do budownictwa, w którym żaden wykonawca nie wyobraża sobie wiarygodnej dokładnej wyceny całości inwestycji bez wglądu choćby w dokumentacje architektoniczną czy konstrukcyjną, wykonaną zgodnie z normami i standardami budowlanymi.
Tłumacząc to – wydawałoby się nieintuicyjne – postępowanie, wielu rozmówców przytacza problem braku odpowiednich zasobów / kompetencji w organizacji, dość abstrakcyjnym charakterem projektów IT czy też brakiem dojrzałości w metodykach i standardach pracy w IT w porównaniu do przytaczanego budownictwa. Jakkolwiek problem zasobów i kompetencji jest tutaj zasadny (jest to jednak temat na osobny artykuł), to sprawa abstrakcji materii czy też standardów i metod pracy wydaje się być pojmowana błędnie.

Istnieją bowiem sprawdzone metodyki i standardy dla praktyki analizy biznesowej (wiodącym staje się tu ostatnio BABOK wydany przez International Institute of Business Analysis), które pozwalają na systematyzację tej dziedziny w organizacjach. W Inteca pomagamy naszym klientom w standaryzacji procesów analizy biznesowej, promując m.in. najlepsze praktyki z BABOK, poprzez wdrożenie rozwiązania Inteca Business Analysis Enterprise Standard, którego celem jest budowa skutecznej, powtarzalnej i dopasowanej do charakteru organizacji praktyki analizy biznesowej, która przyczynia się do istotnej redukcji ryzyka inwestycji bazujących na technologiach informatycznych.

Zainsteresuj się również:

Używamy cookies w celach świadczenia usług i statystyk. Brak zmiany ustawień przeglądarki oznacza, że będą one umieszczane na Twoim urządzeniu. Możesz zmienić te ustawienia. zamknij