Oficjalny dokument: Czy leci z nami pilot?

„Jeśli na pokładzie jest jakiś pilot, niech naciśnie przycisk wezwania” — to coś, czego nie chce usłyszeć żaden pasażer. Przeczytałem ponownie niezwykłą relację z podobnego do tego, prawdziwego zdarzenia, które miało miejsce w grudniu 2013 r. Gdy pilot lotu z Des Moines w stanie Iowa nagle zachorował, drugi pilot poprosił o pomoc jakiegokolwiek pilota znajdującego się na pokładzie samolotu. Zgłosił się kapitan Mark Gongol, pilot bombowca B1 amerykańskiego lotnictwa wojskowego. Samolot, pasażerowie i załoga wylądowali bezpiecznie.

To wspaniała historia, ale mój niedawny powrót do tej opowieści wywołało coś zupełnie innego. Nasz potencjalny klient zadzwonił ostatnio i zapytał, czy może uruchomić „pilota” naszego oprogramowania grafiku projektu w przedsiębiorstwie. Podobne rozmowy zawsze powodują u mnie chwilę zastanowienia. Gdy ktoś w samolocie mówi „pilot”, wszyscy doskonale wiemy, co ma na myśli. Ale gdy ktoś oceniający opcje oprogramowania mówi „pilot”, nie mam takiej pewności.

Termin „pilot” w świecie oprogramowania jest często łączony z innymi wymagającymi metodami oceny, takimi jak „dowód koncepcji”. Przyjrzyjmy się, co oznaczają te pojęcia i jak można najlepiej wykorzystać je w procesie oceny w przedsiębiorstwie.

Dowód koncepcji

To istniejące już od wielu lat pojęcie jest popularne w branży elektrycznej. W celu sprawdzenia, czy obwód będzie działał, tworzy się płytkę prototypową, zamiast płytki produkcyjnej. Dowód koncepcji wymaga spędzenia większej ilości czasu na stanowisku laboratoryjnym niż w przypadku tworzenia obwodu produkcyjnego, ale jedyne zniszczenia, jakie mogą powstać, dotyczą tylko płytki obwodu badanej w laboratorium. Jest to niedroga i mało ryzykowna metoda sprawdzenia, czy obwód elektryczny działa w pożądany sposób.

W przypadku oprogramowania dowód koncepcji powinien być zaprojektowany tak, aby coś udowadniał. Gdy potencjalni klienci dzwonią z pytaniem, czy mogę pomóc im w uzyskaniu dowodu koncepcji dla zarządzania projektem w przedsiębiorstwie lub oprogramowania grafiku w przedsiębiorstwie, zawsze odpowiadam tak samo: „Jakie koncepcje chcecie udowodnić?”

Odpowiedzią zazwyczaj jest cisza i zmieszanie.

Jeśli zamierzasz przeprowadzić dowód koncepcji i nie masz pojęcia, co próbujesz udowodnić, skąd będziesz wiedzieć, czy jest to sukces, czy porażka? Oczywiście nie ma żadnego sposobu.

W takim razie dlaczego w ogóle ktoś chce przeprowadzić dowód koncepcji? Najczęstsza odpowiedź jest taka, że zleceniodawca prawdopodobnie nie ma wystarczającego wsparcia od kierownictwa, aby zaimplementować badane oprogramowanie, i ma nadzieję, że jeśli oprogramowanie zostanie uruchomione na jego oczach, spodoba mu się pomysł i zgodzi się na jego wdrożenie. W takim przypadku „dowód” jest dla kierownictwa, a „koncepcja” to ogólna idea oprogramowania w przedsiębiorstwie.

Gdyby przekonanie kierownictwa, że oprogramowanie projektu i grafiku w przedsiębiorstwie znakomicie się dla niego nadaje, było takie proste, wdrożylibyśmy tego o wiele więcej.

Problem z tą metodą polega na tym, że praca, którą należy wykonać w celu wdrożenia tego dowodu koncepcji, zdecydowanie nie będzie miała takiego samego wsparcia jak wdrożenie produkcyjne systemu w przedsiębiorstwie. Gdy organizacja wdraża system w przedsiębiorstwie, na przykład grafik lub system zarządzania projektami, do osiągnięcia sukcesu wymaganych jest wiele czynników. Przede wszystkim potrzebny jest wkład kierownictwa i pracowników w każdym aspekcie organizacji, którego dotyczy wdrożenie. Poza tym potrzebny jest czas na konfigurację, pomoc służb technicznych mająca na celu połączenie wdrożenia z innymi systemami przedsiębiorstwa, sponsoring kierownictwa, czas na szkolenia i — tak — pieniądze.

Jeśli nie masz żadnej z tych rzeczy, jaki będzie system, który możesz wykonać w ramach dowodu koncepcji? W najlepszym razie będzie cieniem tego, czego potrzebujesz. W dzisiejszej epoce chmury prawdopodobnie możesz uzyskać dostęp do całkowicie hostowanego systemu, aby przynajmniej nie martwić się zakupem serwerów i oprogramowania, ale zainstalowanie systemu to zaledwie ułamek pracy wymaganej do nawet podstawowego wdrożenia systemu dowodu koncepcji.

Łatwo zrozumieć, dlaczego organizacja będzie wahała się, czy poświęcić mnóstwo pieniędzy i zasobów na zaimplementowanie czegoś, co może wpłynąć na całą organizację. To bardzo ryzykowne doświadczenie. Mamy tendencję do mówienia tylko o korzyściach wynikających z oprogramowania do zarządzania projektami w przedsiębiorstwie, ale łatwo sobie wyobrazić, że ten sam projekt zakończony niepowodzeniem może mieć równie negatywny wpływ. Dlatego ograniczanie ryzyka jest oczywistym problemem. Jeśli jednak prawdziwym wyzwaniem jest przekonanie kierownictwa o zaletach systemu, z pewnością istnieją lepsze sposoby. W firmie HMS Software skoncentrowaliśmy się na kilku z poniższych technik:

  1. Mów do prawdziwego, już istniejącego klienta.

    Mamy szczęście, że mamy kilku wspaniałych klientów, którzy są całkiem zadowoleni. Gdy nowy, potencjalny klient ma obawy, na co się decyduje, kontaktujemy go z naszym dotychczasowym klientem. Często istniejący klient jest na tyle wspaniałomyślny, że proponuje osobiste spotkanie. Innym razem klienci kontaktują się ze sobą, a my celowo się w to nie włączamy. Zachęcamy istniejących klientów do dzielenia się zarówno dobrymi wieściami, jak i wyzwaniami.

  2. Pozwól nam to udowodnić.

    Jeśli masz koncepcję, która wymaga udowodnienia, pozwól nam ją udowodnić. Istnieją uzasadnione przyczyny, dla których pewne aspekty niektórych implementacji trzeba najpierw sprawdzić. Być może wdrożenie będzie obejmowało bardzo duże ilości pewnego rodzaju danych. Pewnego razu poproszono nas na przykład o zademonstrowanie naszego rozwiązania w działaniu z wyjątkowo dużym obciążeniem projektu. Zostaliśmy poproszeni o pokazanie oprogramowania współpracującego z określonymi przeglądarkami lub bazami danych albo łączącego się z określonymi wersjami pewnych systemów zewnętrznych. Jeśli to jest ten rodzaj koncepcji, który blokuje ocenę, najlepszymi osobami, które mogą pokonać to wyzwanie są eksperci w danej dziedzinie.

  3. Możesz przejść jakieś przeszkolenie.

    W przypadku gdy potencjalny klient zdecydowanie musi pokazać system działający z jego danymi używanymi przez jego personel, pomagamy załadować dane do hostowanego systemu, a następnie przeprowadzamy minimalną konfigurację systemu zgodnie z życzeniem klienta i szkolimy ludzi, którzy będą zaangażowani w projekt. Zdecydowanie preferujemy przyjazd do firmy w celu udzielenia pomocy z samym pokazem, ale jeśli to niemożliwe, prosimy o możliwość przejrzenia skryptu lub pokazu, który zostanie użyty. Prosimy także o możliwość pomocy w jego dostosowaniu lub szkolimy do tego ludzi.

Gdzie jest pilot, gdy go potrzebujesz?

Więc co z tym projektem pilotażowym? Tak lepiej, prawda? Mogłoby być. Jeśli poproszono Was o przygotowanie wdrożenia pilotażowego grafiku lub systemu zarządzania projektami w przedsiębiorstwie, powinniście zacząć od określenia celów. Jeśli celem jest tylko przeprowadzenie dowodu koncepcji, to w ogóle nie mamy do czynienia z programem pilotażowym.

Projekt pilotażowy to prawdziwe, produkcyjne wdrożenie na żywo. Zazwyczaj obejmuje podzbiór ogólnej bazy użytkowników, która jest rozważana dla ocenianego systemu. Z tego powodu program pilotażowy prawdopodobnie zajmie trochę czasu. Podczas gdy od początku są rozważane potrzeby pełnej bazy użytkowników docelowych, program pilotażowy koncentruje się na wykonaniu prawdziwej implementacji użytkowników pilotażowych. Będą oni faktycznie zarządzać swoimi projektami lub wypełniać swoje grafiki w nowym systemie.

Implementacja pilotażowa napotyka na takie same wyzwania jak pełne wdrożenie produkcyjne, z wyjątkiem ilości lub złożoności danych. Najczęściej spotykane problemy projektów pilotażowych to brak sponsoringu, niewystarczający budżet, czas i zasoby oraz — co jest prawdopodobnie najgorsze ze wszystkiego — brak wyartykułowanych celów umożliwiających stwierdzenie, czy projekt pilotażowy zakończył się sukcesem, czy nie.

To nie znaczy, że projekt pilotażowy jest zły. Projekt pilotażowy może być bardzo sensowny i przyczynić się do ograniczenia ryzyka wpływu nie w pełni lub niewłaściwie skonfigurowanego wdrożenia na całą organizację. Ale stworzenie zakończonego sukcesem projektu pilotażowego wymaga przemyślenia.

Niedawno zaczęliśmy pracę nad bardzo dużym wdrożeniem dla organizacji z sektora publicznego. Satysfakcjonujące w tym doświadczeniu jest to, że organizacja wykorzystała już cały czas, który powinna, na dokonanie oceny. Wybrano system korporacyjny. Na szczęście nasz. Przez ostatni rok współpracowaliśmy z ich zespołem oceniającym, odpowiadając na wszystkie pytania techniczne, ale teraz cała uwaga przeniosła się na codzienne procesy realizowane przez członków tej organizacji.

Zaproponowano nam, abyśmy przez 6 miesięcy pracowali z grupą, która, choć duża, stanowi zaledwie ok. 10 procent całości. Mamy odpowiedni budżet, projekt pilotażowy ma wsparcie kierownictwa na najwyższym szczeblu, mamy też wystarczająco dużo czasu, aby upewnić się, że możemy pomóc we wszystkim, co normalnie robimy we wdrożeniu takim jak to. Grupa, która zostanie zaangażowana do pracy w środowisku grafiku i śledzenia tego projektu, w dającej się przewidzieć przyszłości będzie pracowała w środowisku produkcyjnym, dlatego nie jest to tylko test. Jest to bardziej pierwsza faza wdrożenia, a nie eksperyment typu „spróbujmy i zobaczymy”. Wszystkie te czynniki sprawiają, że w kolejnych miesiącach tego roku spodziewamy się sukcesu.

Podsumowanie

Projekty pilotażowe i dowody koncepcji zdarzają się w oprogramowaniu dla przedsiębiorstw, ale jeśli macie jeden z nich w przyszłości, możecie przyczynić się do jego sukcesu. Oto niektóre z kluczowych czynników sukcesu dla wszystkich zaangażowanych:

  1. Najpierw upewnijcie się, że Wasze cele zostały wyraźnie wyartykułowane.

  2. Następnie upewnijcie się, że kierownictwo rozumie, czego potrzebujecie, i będzie Was wspierać pieniędzmi, zasobami i czasem, aby osiągnąć te cele.

  3. Na koniec upewnijcie się, że planujecie projekt i zarządzacie nim tak samo jak każdym innym projektem w Waszym portfelu.

O autorze

Chris Vandersluis jest prezesem i założycielem firmy HMS Software, certyfikowanego partnera firmy Microsoft, z siedzibą w Montrealu (Kanada). Ma dyplom z ekonomii uniwersytetu McGill University i ponad 30-letnie doświadczenie w dziedzinie automatyzacji systemów kontroli projektów. Jest długoletnim członkiem instytutu Project Management Institute (PMI). Pomagał zakładać oddziały Microsoft Project Users Group (MPUG) w Montrealu, Toronto i Quebecu. Wydawnictwa, do których pisał Chris, to między innymi Fortune, Heavy Construction News, magazyn Computing Canada, PMI’s PMNetwork oraz Project Times. Wykłada zaawansowane zarządzanie projektami na uniwersytecie McGill University i często wypowiada się na temat funkcji stowarzyszeń zarządzania projektami w Ameryce Północnej i na całym świecie. HMS Software to producent systemu zarządzania czasem zorientowanego na projekt TimeControl. Od 1995 roku jest partnerem firmy Microsoft w dziedzinie rozwiązań dotyczących projektów.

Z Chrisem Vandersluisem można skontaktować się pod adresem e-mail: chris.vandersluis@hms.ca

Więcej artykułów Chrisa Vandersluisa na temat zarządzania projektami w przedsiębiorstwach można przeczytać w jego blogu EPM Guidance (http://www.epmguidance.com/?page_id=39).

Rozwijaj umiejętności związane z pakietem Office
Poznaj szkolenia
Uzyskuj nowe funkcje w pierwszej kolejności
Dołącz do niejawnych testerów pakietu Office

Czy te informacje były pomocne?

Dziękujemy za opinię!

Dziękujemy za opinię! Wygląda na to, że połączenie Cię z jednym z naszych agentów pomocy technicznej pakietu Office może być pomocne.

×