Dlaczego warto stosować analizę przedwdrożeniową IT?
Wprowadzenie
Wyobraźmy sobie hipotetyczną, acz standardową sytuację, w której Rafał - właściciel średniej firmy usługowej stwierdził, że potrzebuje systemu do raportów, by móc lepiej zarządzać swoim biznesem. W tym celu robi prosty research by znaleźć firmę IT, która zrealizuje jego potrzebę. Po krótkiej analizie wybiera trzy firmy, które wyglądają na profesjonalne i zrealizowały podobne projekty. Odzywa się do każdej z nich, krótko i zwięźle informując je czego potrzebuje.
Firma A nie zadawała więcej pytań i dwa dni później wysyła swoją ofertę, z bardzo szerokim zakresem widełek - powiedzmy od 10 do 30 tysięcy.
Konsultant z firmy B rozmawiał z właścicielem firmy przez ponad pół godziny, wypytując o sytuację w firmie, problemy jakie ma, potrzeby biznesowe, a także czego się spodziewa po systemie do raportowania. Dzięki bardziej wnikliwej analizie, firma B przesyła następnego dnia ofertę na konkretną kwotę 15 tysięcy.
Firma C zachowuje się inaczej. Po wstępnym zadaniu tych samych pytań co konsultant z firmy B, firma C proponuje Rafałowi, właścicielowi firmy, usługę analizy przedwdrożeniowej, która polegałaby na wizycie doświadczonego konsultanta w firmie Rafała, by dowiedział się w pełni jak funkcjonuje jego firma, jakie potrzeby mają jego pracownicy i jakie dane faktycznie będą potrzebne, by rozwijać biznes, a nawet czy taki system do raportowania jest w ogóle potrzebny. Koszt takiej usługi został wyceniony na 5 tysięcy.
Którą ofertę wybrał Rafał? Prawdopodobnie ofertę firmy B, ale mając na stole ofertę firmy A, która zaczynała się od 10 tysięcy, wynegocjował jeszcze zniżkę i docelowo zapłacił 12 tysięcy złotych.
Czy podjął dobrą decyzję? Można powiedzieć, że tak - w końcu firma B wiedziała dokładnie czego Rafał potrzebuje i przygotowała system IT po naprawdę dobrej cenie.
Ale czy była to najlepsza możliwa biznesowo decyzja?
Być może audyt firmy C wykazałby, że żaden system do raportowania nie jest potrzebny, bo wystarczyłoby dokupić wyższy pakiet obecnie stosowanego oprogramowania. Firma C, co prawda, nie zarobiłaby na stworzeniu nowego systemu, ale pomogłaby klientowi oszczędzić znacznie koszty, zyskując również wdzięczność i, prawdopodobnie, lojalność klienta. A może audyt wykazałby, że w innym miejscu firmie drzemie niewykorzystany potencjał?
Tego Rafał się nie dowie, bo nie brał pod uwagę w ogóle oferty firmy C z różnych względów - nie mógł porównać jej oferty z pozostałymi (a przywykł do podejmowania decyzji na podstawie ceny i pierwszego wrażenia), nie chciał “wyrzucać w błoto” 5 tysięcy na audyt, który pokazałby to, co on już wie (a raczej co mu się wydaje, że wie), a także konsulting opóźniłby cały projekt, a czas to pieniądz.
Jaki jest morał z tej historii? Nie bądź jak Rafał ;).
A już całkiem serio - często nie wiemy tego, czego nie wiemy, a często to co nam się wydaje, że wiemy, nie jest do końca takie w rzeczywistości. Dlatego warto posiłkować się doświadczeniem ekspertów w obszarach, na których się nie znamy lub znamy się częściowo.
I o tym będzie ten artykuł.
Jak wygląda szacowanie wytworzenia oprogramowania?
Zanim przejdziemy dalej, zatrzymajmy się na chwilę i zastanówmy się jak obecnie tworzone są wyceny usług IT.
Najczęściej firma IT (czy to software house czy agencja interaktywna) otrzymuje brief od klienta, w którym zawarte są klienta potrzeby (czasem również obecny kontekst i przyczyny zajęcia się tym tematem). Następnie business developer (kiedyś sprzedawca) dopytuje klienta o szczegóły i potrzebne informacje, niezbędne do zrobienia wyceny.
Po uzyskaniu wszystkich informacji, dział biznesowy wraz z IT opracowuje wstępną wycenę, bazującą na informacjach od klienta, ale także swoich założeniach i domysłach, zawyżając czas na wykonanie poszczególnych zadań, by uzyskać bufor zarówno czasowy, jak i finansowy. Często taka wycena jest wielowariantowa, z modułami/zadaniami opcjonalnymi, a jeśli firma jest mniej transparentna to najczęściej wycena jest podana w widełkach od-do.
Ten styl współpracy, mimo że techniki zwinnego wytwarzania oprogramowania są popularyzowane od prawie 20 lat, jest nadal dominujący we współpracy między biznesem a IT. Jeśli jednak doradca ze strony firmy IT przekona klienta, że warto tworzyć oprogramowanie zwinnie - wtedy nie do końca da się przewidzieć finalny koszt, gdyż zakres prac IT ustalany jest na bieżąco.
W tej sytuacji analiza przedwdrożeniowa, której wynikiem będzie wstępna specyfikacja, bardzo konkretnie spisane potrzeby oraz cele klienta, a także procesy biznesowe, terminologia i wiedza ekspercka - będzie niezbędna, by projekt mógł zostać oszacowany, a także by miał większe szanse na powodzenie (co rozumiemy jako realizację potrzeb klienta, spełnienie jego celów biznesowych, zmieszczenie się w budżecie oraz harmonogramie).
Ale czy w poprzedniej sytuacji - gdy klient nie ma czasu na współpracę z firmą IT - po prostu chce otrzymać stronę internetową, platformę czy aplikację mobilną - taka analiza nie dałaby korzyści klientowi?
Skontaktuj się z nami już teraz by otrzymać niezobowiązującą poradę dotyczącą wdrażania projektów IT:
Dlaczego tak wygląda wycenianie projektów IT?
Zanim odpowiemy sobie na to pytanie, zastanówmy się czemu wyceny tworzone przez firmy IT wyglądają tak, jak wyglądają?
Głównych powodów są trzy:
- Doradcy pracujący w software house’ach nie czytają w myślach klientów - rzadko kiedy klient jest w stanie przekazać wszystkie ważne informacje i potrzeby w jednym briefie czy przez telefon, a nawet na spotkaniu.
- Klienci nie są specjalistami IT (przeważnie), ale są przedsiębiorcami, pracownikami działów marketingu, produkcji - więc często koncentrują się na rozwiązaniach, a nie na swoich potrzebach i wyzwaniach.
- Szacowanie nawet kilkumiesięcznego projektu jest bardzo trudną sztuką, przy wielkiej liczbie niewiadomych i zmiennych - więc im więcej danych i wiedzy, tym mniej niewiadomych.
Te trzy powody są genezą najważniejszego problemu, który dotyka projekty IT. To ZMIANA.
Już Heraklit z Efezu powiedział: “Jedyną stałą rzeczą w życiu jest zmiana”. Nie ma bardziej prawdziwego zdania dotyczącego projektów IT, niż ta sentencja.
Dzieje się tak, gdyż nieuświadomione potrzeby klienta, skupianie się na rozwiązaniach, a nie potrzebach i duża złożoność tworzenia oprogramowania powoduje, że w trakcie projektu (albo na jego koniec) klient uświadomi sobie kolejne potrzeby IT (wynikające z jego potrzeb biznesowych) albo zmieni się sytuacja na rynku, lub jedno z założeń firmy IT okaże się nieprawdziwe. W naszej pracy spotykamy się z tymi kwestiami bardzo często, a można by ich wymienić jeszcze parę. A to niestety rodzi poważne problemy we współpracy.
By to zobrazować wróćmy do historii z Rafałem. Rafał, jak pamiętamy, wybrał firmę B, która zainteresowała się jego potrzebami i podała konkretną kwotę za system do raportowania. Wszystko idzie płynnie, aż w połowie projektu Rafał uświadomił sobie, że jeden z raportów, który będzie generował system, ma w swoim obecnym systemie do zarządzania firmą. Równocześnie uświadomił sobie, że przydałby mu się inny w zamian. Kontaktuje się więc z firmą B i przedstawia swoje życzenie i otrzymujemy taki dialog:
Rafał: “Chciałbym zrezygnować z raportu X, za to mieć raport Y”.
Firma B: “Niestety to nie możliwe. Zrobiliśmy już raport X”.
Rafał: “Ale ja nie potrzebuję raportu X, bo go już mam u siebie na komputerze. Chcę raport Y”.
Firma B: “Panie Rafale, nawet gdybyśmy nie zrobili raportu X, to raport Y jest 3 razy bardziej skomplikowany, co oznaczałoby potrzebę dopłaty 10 roboczogodzin do niego”
Rafał: “10 godzin więcej? Przecież to tylko trochę bardziej skomplikowany raport. Na pewno potraficie go zrobić szybciej”
Dyskusja trwa dalej, najprawdopodobniej skończy się na tym, że raport X nie ujrzy światła dziennego w nowym systemie, a za raport Y firma B uzyska 5 roboczogodzin, spisując na straty koszty włożone w przygotowanie raportu X.
Oczywiście jest to przejaskrawiona sytuacja, ale niestety często ma miejsce - z każdym rodzajem klienta, i z każdym rodzajem firmy IT. Dlatego też techniki Agile i Scrum są tak skuteczne, ale wymagają dużego zaangażowania i zaufania.
A czy obie strony są zadowolone z sytuacji? Zdecydowanie nie. Rafał musiał mocno negocjować, by nie musieć płacić, za coś, co miał od dawna (a czego nie był świadomy), a firma IT poniosła kolejną obniżkę marży, by zachować relacje z klientem. Oczywiście mogła się w pełni postawić, ale to by mogło grozić przerwaniem projektu i sprawą w sądzie.
Wielu z problemów, które pojawią się w projekcie, można by uniknąć, wykonując pracę analityczną i doradczą na początku projektu. Prawdopodobnie nie wszystkie, ale znaczną część, dzięki czemu współpraca między obiema stronami byłaby znacznie lepsza, a także efekt końcowy by znacznie lepiej realizował cele biznesowe klienta.
Jak powinno wyglądać idealne szacowanie kosztów projektu IT?
Teraz chciałbym opisać prawdziwą historię - z jednym z naszych klientów, który jest jednym z trzech liderów w Polsce branży leasingu odzieży roboczej.
Jakub, dyrektor logistyki, odezwał się do nas, gdyż potrzebował rozwiązań IT, by usprawnić pracę kierowców (de facto, przedstawicieli firmy) oraz biura obsługi klienta. Nasz klient miał w głowie swoje pomysły, co przydałoby się jego firmie, ale wiedział, że potrzebuje partnera i doradcy, który rzetelnie to oceni.
Zamiast poinformować nas, że potrzebuje aplikację X i system Y, opowiedział jakie ma problemy i czy jesteśmy w stanie mu pomóc je rozwiązać. Jest to dokładnie jedna z rzeczy, którymi się zajmujemy - nie tylko tworzymy dedykowane rozwiązania IT dla biznesu, ale także pomagamy naszym klientom w realizowaniu ich biznesowych celów.
I mimo że już na pierwszym spotkaniu w głowie mieliśmy, czego firma Jakuba potrzebuje - wiedzieliśmy, że trzeba przeprowadzić profesjonalną analizę sytuacji biznesowej firmy poprzez audyt procesów, poznanie potrzeb, wyzwań i celów wszystkich osób, których ta zmiana dotknie.
Zatem zamiast od razu przedstawić ofertę i próbować zamknąć “deal’a”, zarekomendowaliśmy przeprowadzenie audytu IT, który nie tylko potwierdzi Jakuba i nasze przypuszczenia, ale także da niezbędną wiedzę, co można zrobić, jak to zrobić, jakie są ograniczenia, a może okaże się coś, czego nikt wcześniej nie przewidział.
Jednym z takich odkryć było, że stosunkowo niskim nakładem kosztów można by stworzyć nowy program do skanowania odzieży, który będzie miał znacznie czytelniejszy interfejs, co spowoduje mniej błędów w sortowaniu odzieży, a co przełoży się na mniej błędów już u klientów, co z kolei przełoży się na lepszą reputację firmy.
Efektem końcowym było nie tylko potwierdzenie przypuszczeń co będzie potrzebne, lecz także zamapowanie procesów firmy (w analizowanym obszarze), przyszłe możliwe usprawnienia, zestawienie ograniczeń, a także specyfikacja i konkretna oferta.
Taka współpraca jest możliwa jedynie, gdy firmę IT traktujemy jako partnera, specjalistę w swojej dziedzinie, a nie jedynie dostawcę, który zrobi dla nas to, co nam się wydaje, że potrzebujemy. To jest ta sama zasada, jak przy zatrudnianiu ludzi w swojej firmie - powinniśmy zatrudniać specjalistów, by wykonywali swoją pracę najlepiej jak potrafią, a nie tak jak nam się wydaje.
Zastanawiasz się od czego zacząć wdrażanie projektu IT? Skontaktuj się z nami już teraz!
Korzyści z przeprowadzenia analizy przedwdrożeniowej IT
Gdy już wiemy, że warto w złożonych sytuacjach przeprowadzić dogłębną analizę, zastanówmy się jakie konkretnie korzyści możemy osiągnąć.
Główna korzyść to urealnienie kosztów. Im mniej niewiadomych dla software house’u, tym bardziej dokładna wycena (przez bardziej dokładna mam na myśli lepiej oddająca oczekiwany stan końcowy). Zatem będziemy mogli lepiej określić koszty, bez widełek i bez dużych zakładanych buforów.
Dodatkowo warto być świadomym, że im później w trakcie życia projektu zajdzie zmiana zmieniająca wymagania lub zakres prac, tym większy jest koszt jej obsłużenia. To jest najważniejsze zadanie analizy przedwdrożeniowej - zminimalizować liczbę zmian w trakcie prac nad projektem.
Wizualizacja rosnących kosztów zmiany w projekcie w zależności od etapu zaangażowania projektu.
Kolejny olbrzymi zysk z przeprowadzenia analizy przedwdrożeniowej to zwiększenie szans na zrealizowanie oczekiwań. Dzięki analizie wszyscy będą bardziej świadomi rzeczywistych potrzeb klienta. I efekt końcowy powinien realizować zakładane cele klienta.
Inną potencjalną korzyścią jest skrócenie czasu projektu. Skoro wiemy co dokładnie jest do zrobienia oraz posiadamy wiedzę dotyczącą przedsiębiorstwa - jesteśmy w stanie lepiej określić harmonogram i założyć mniejsze bufory rezerwowe.
Wynikiem przeprowadzenia analizy jest również lepsze poznanie się obu firm i zespołów. W ramach współpracy obie strony poznają się, zobaczą jak współpracują, co jest dużą zaletą przed rozpoczęciem właściwych prac nad systemem IT. Dodatkowo od początku uzyskujemy zaangażowanie klienta w prace nad projektem, zamiast częstego oczekiwania, że firma IT zrobi wszystko.
Kolejną zaletą dla klienta z przeprowadzenia analizy przedwdrożeniowej IT jest to, że zostanie zadane mnóstwo pytań, na które on sam sobie od dłuższego czasu nie udzielał odpowiedzi. To jest jeden z plusów konsultingu - że odpowiesz sobie na pytania, których sam sobie nie zadajesz, poszerzysz swoje horyzonty albo przypomnisz sobie o ważnych rzeczach, o których w zabieganej codzienności zapomniałeś.
Efektem końcowym analizy jest specyfikacja (w zależności od potrzeb również makiety UX), ale także zbiór wymagań, analiza ograniczeń i ryzyk, propozycja zmian w procesach firmy, a także oferta zawierająca wymagany budżet i harmonogram.
Skąd wynika niechęć do przeprowadzenia analizy przedwdrożeniowej IT?
Skoro wiemy jakie korzyści może przynieść analiza przedwdrożeniowa, zastanówmy się jeszcze nad argumentami przemawiającymi na jej niekorzyść.
Jednym z głównych argumentów, które słyszymy to czas jej trwania, a więc wpływ analizy jako dodatkowej czynności na opóźnienie rozpoczęcia prac. Prawda natomiast jest taka, że czas odpowiednio wykonanej analizy przedwdrożeniowej jest wielokrotnie mniejszy (i tańszy) niż nieprzewidziane zmiany na projekcie wynikające z braku wcześniejszej analizy.
Poważniejszy argument to oczywiście dodatkowy koszt. Zapewne po części wynika to z braku standardu tego rozwiązania w branży, gdy wszyscy startujemy w przetargach i konkurujemy ceną, a nie jakością. Tutaj należy solidnie podkreślić, że analiza przedwdrożeniowa nie jest kosztem, lecz inwestycją i szansą na zmniejszenie docelowych kosztów projektu.
A skoro jesteśmy przy konkurencji, to nie można wspomnieć o potrzebie właścicieli firm by porównywać oferty wielu dostawców oprogramowania. Takie podejście jest oczywiście słuszne, ale przywołując historię Rafała z początku artykułu - rozsyłamy prośby o wyceny czegoś, co mamy nie do końca sprecyzowane i nie jesteśmy pewni czy jest nam potrzebne w takiej formie, a zatem otrzymamy wielki rozstrzał i możemy skończyć sfrustrowani, bez tego, o co nam chodziło.
Czy nie lepiej byłoby najpierw przeprowadzić analizę przedwdrożeniową - wiedzieć dokładnie, czego potrzebujemy, mieć konkretną specyfikację, analizę ryzyk oraz ograniczeń i dopiero tak przygotowanym poprosić inne firmy IT o przesłanie oferty? Naszym zdaniem, tak by było zdecydowanie lepiej dla wszystkich stron.
Inną kwestią jest fakt, że analizy przedwdrożeniowe najczęściej do tej pory były stosowane przed wdrożeniem systemów ERP, co może wpływać na postrzeganie ich jako rozwiązań drogich i trwających długo. Jednakże w zależności od złożoności projektu może to potrwać od 1 do 4 tygodni (chyba że mówimy o rozwiązaniach ERP - wtedy jest to czas dłuższy - bliższy 3 miesiącom).
Case Study projektu analizy przedwdrożeniowej IT
Przytoczę teraz jeszcze inną historię z naszym niedoszłym klientem. Zostaliśmy zaproszeni do bardzo szybko rozwijającej się agencji pracy tymczasowej, by porozmawiać o stworzeniu dedykowanego systemu dla ich potrzeb, gdyż obecnie wszystkie dane trzymają w małym systemie ERP oraz w wielu plikach Excel.
W firmie od miesiąca pracował doświadczony konsultant, który spisał wszystkie procesy firmy (po raz pierwszy w historii firmy) i na ich podstawie zostały wyciągnięte pierwsze wnioski, czego firma potrzebuje, by dalej móc się rozwijać, ale także jak zwiększyć jakość oraz wydajność.
Nasze podejście w takiej sytuacji zakłada przeprowadzenie dogłębnej analizy przedwdrożeniowej, czyli w tym przypadku audytu zamapowanych procesów, rozmowy z przedstawicielami każdej grupy współpracowników, analizie obecnie wykorzystywanych narzędzi (Excel) oraz sposobie ich wykorzystania w codziennej pracy. I dopiero potem bylibyśmy w stanie przygotować konkretną ofertę, zawierającą wstępną specyfikację prac, zakładany harmonogram i zaproponowalibyśmy podejście iteracyjne, czyli wytwarzanie oprogramowania w równych etapach czasowych (tzw. sprinty - np. 2 tygodnie), skupiając się na aktualnym priorytecie firmy.
Takie podejście nie tylko zapewniłoby zwiększenie szans na pomyślną informatyzację firmy, ale także szybkie rezultaty finansowe dzięki wdrażaniu co chwilę kolejnych usprawnień.
Niestety nasz niedoszły klient oczekiwał od razu konkretnej oferty (która nie była możliwa do przygotowania po jednym półtoragodzinnym spotkaniu), a także od początku wyrażał nieufność wobec firm z branży IT. Z takim podejściem nie było możliwe partnerstwo i nawiązanie współpracy win-win dla obu stron.
W dniu kiedy powstaje ten artykuł, minęły 4 miesiące od tamtego spotkania i do tej pory nie rozpoczęto współpracy z żadnym software housem, co trzeba traktować jak zmarnowany czas, który można było wykorzystać na podniesienie konkurencyjności przedsiębiorstwa i przyspieszenie jego rozwoju. Nie ma wątpliwości, że kiedyś pojawią się w tej firmie rozwiązania IT, o których rozmawialiśmy, ale prawdopodobnie już gdy skończy się olbrzymi boom w tej branży.
Jak wygląda analiza przedwdrożeniowa IT?
Wiemy już jakie są korzyści ze stosowania analizy przedwdrożeniowej. Wiemy również czemu, błędnie, nie wszyscy się na nią decydują. Spójrzmy zatem jak dokładnie ona wygląda.
Pierwszym krokiem zazwyczaj powinien być szczegółowy audyt firmy, by konsultant mógł poznać dokładnie charakterystykę środowiska, procesy zachodzące w firmie, jak wygląda praca oraz komunikacja pracowników. Przy mniej złożonych tematach można ten krok znacząco skrócić, ale warto go wykonać.
Drugim krokiem powinien być warsztat z głównymi osobami w firmie klienta, których dotyczyć będzie zmiana (nie tylko osoby decyzyjne, ale też osoby które będą wdrażać nowe rozwiązanie oraz osoby, które będą użytkownikami nowego systemu). Może on przybrać formę Q&A (pytania i odpowiedzi), wspólnej analizy wymagań, ryzyk i ograniczeń albo sesji Event Storming.
Jako, że Event Storming jest bardzo ciekawą, ale i zaawansowaną metodą projektowania wymagań, zdarzeń, ograniczeń w istniejącym kontekście biznesowym, zasługuje ona na oddzielny wpis. W skrócie polega ona na wspólnej pracy kilku osób, które obsługują cały proces w firmie, których zadaniem jest wypisanie wpierw wszystkich możliwych zdarzeń jakie się dzieją w tym procesie. Następnie wszystkie te zdarzenia są grupowane i próbuje się je ułożyć w logiczną całość, dodając ograniczenia, wyzwalacze akcji i wymagania posiadania odpowiednich zasobów. Mając tak opracowany diagram, z którego już nic nie można zabrać, ani nic dodać - jesteśmy w stanie zaprojektować model biznesowy i odzwierciedlić w kodzie wszystkie reguły biznesowe dotyczące tego procesu. Event Storming jest podstawowym narzędziem metodyki DDD (ang. Domain-Driven Development).
Jeśli nie wykonamy sesji Event Storming, to wynikiem audytu powinno być zamapowanie procesu (czy to w notacji BPMN czy podobnej). Na podstawie zebranych danych i diagramów, konsultant następnie opracowuje wstępną specyfikację rozwiązania, a jeśli dużą rolę w systemie spełnia interfejs użytkownika, to także projektowane są makiety UX (proste rysunki interfejsu, obrazujące ideę i intencję użytkowników, bez kładzenia nacisku na grafikę czy estetykę).
Po wspólnym przeanalizowaniu opracowanej specyfikacji i makiet UX z klientem, software house jest gotów do przygotowania oferty zawierającej znacznie dokładniejsze oszacowanie kosztów oraz harmonogramu, rozumiejąc dokładnie wyzwania, potrzeby i zagrożenia dla klienta.
To jest też moment, kiedy kończy się analiza przedwdrożeniowa i klient może się zdecydować na współpracę z software housem przygotowującym całą analizę (jeśli współpraca układała się dobrze) albo wykorzystać wszystkie materiały jako podstawy do zrobienia researchu na rynku (zamiast tradycyjnego briefu).
Często zdarza się również, że firmy IT udzielają 50% (albo 100%) zniżek na przeprowadzenie analizy przedwdrożeniowej, jeśli klient zdecyduje się na realizację projektu u nich.
Podsumujmy jeszcze raz, co finalnie uzyskuje firma, gdy zdecyduje się na przeprowadzenie analizy przedwdrożeniowej:
- identyfikacja i opis procesów biznesowych, których dotyczy problem/wyzwanie/potrzeba z punktu widzenia niezależnego konsultanta,
- rekomendacja odnośnie zakresu funkcjonalnego wdrożenia rozwiązań IT,
- ustalenie z klientem jego celów biznesowych oraz oczekiwanych korzyści, które są możliwe do osiągnięcia narzędziami IT,
- stosunkowo dokładny harmonogram,
- dokładnie rozpisane koszty,
- opisanie potrzeb technicznych (np. parametry serwera, dodatkowe oprogramowanie itp.)
I to wszystko posiadamy jeszcze zanim zaczną się właściwe prace programistyczno-graficzne. Przy większych projektach trudno wyobrazić sobie start projektu, bez tak dokładnie przeprowadzonej analizy.
Czy bez analizy uda się dobrze spiąć projekt?
No właśnie. Czy może się udać duży projekt bez takiej analizy? Oczywiście że tak, ale ryzyko nieporozumień, zmiany w wymaganiach, stworzenia niepotrzebnych modułów jest wtedy znacznie wyższe. A czy nie odpowiedzialnością profesjonalistów powinno być minimalizowanie ryzyka?
Analiza przedwdrożeniowa staje się standardem przy bardziej skomplikowanych projektach. Przy prostszych projektach może wystarczyć dobrze wykonana praca doradcy i eksperta po stronie firmy IT by poznać potrzeby klienta, ale nie zastąpi to nigdy profesjonalnie wykonanego audytu i analizy.
Może to się też udać, gdy firma posiada duże doświadczenie w prowadzeniu projektów IT, posiada kulturę uczącą się i za każdym razem usprawnia swoje praktyki. Wtedy mogą sami wykonać większą część pracy konsultacyjnej i mogą przekazać firmie IT dokładne wymagania i ograniczenia.
Niestety, najczęściej klienci nie mają takich kompetencji. I jeśli nie skorzystali z oferty analizy przedwdrożeniowej to czy potem wolno narzekać, że firma IT nie dowiozła projektu w terminie bądź koszty wykroczyły poza zakładany budżet? To już dużo zależy od tego jaką pracę wykonała firma IT, ale tworzenie oprogramowania jest tak mocno obarczone pracą z wieloma zmiennymi/niewiadomymi, że minimalizacja każdego z tych utrudnień zawsze wpłynie pozytywnie na wynik końcowy.
Także podsumowując: szansa oczywiście jest, że wszystko się powiedzie bez analizy, ale czemu nie zwiększyć szans na powodzenie?
Szans, które są liczone w pieniądzach?
