Nie rób niczego bez wyraźnego celu

Nie powinieneś robić niczego, co nie ma jasnego celu. Wyobraź sobie dwa równoległe światy, w których wszystko jest takie samo, z wyjątkiem tego, co zamierzasz zrobić: Jak różne byłyby te światy? Czy różnica jest warta wysiłku koniecznego, aby to zrobić?

Jeśli nie masz jasnego celu i robisz coś tylko dlatego, że wszyscy to robią lub wszyscy mówią, że jest to ważne, to może to nie przynieść żadnej realnej korzyści. Możesz więc nic z tego nie uzyskać; lub może to nadal mieć potencjalne korzyści, ale ponieważ nie masz na myśli konkretnego celu, twój sposób na zrobienie tego może nie być pomocny w osiągnięciu korzyści.

Przykład: Portfele i programy

Jeśli jesteś zaangażowany w wybór i inicjowanie projektów, powinieneś mieć pewność, że koncentrujesz się na korzyściach i problemach, które należy rozwiązać, a nie na produkcie, który ma te rzeczy umożliwić. Klasycznym przykładem jest producent wind, który otrzymywał skargi na prędkość swoich wind, a więc przeprowadził wiele projektów mających na celu zwiększenie prędkości. Bez pełnego sukcesu. Trwało to, dopóki nie zdecydowali się skupić na problemie (nuda lub dyskomfort w windzie) zamiast „naturalnego” rozwiązania (szybsze windy). W rezultacie zainstalowano w windach lustra, co rozwiązało problem w prosty i tani sposób.

Pamiętaj, że zarządzanie projektami polega głównie na robieniu rzeczy właściwie, podczas gdy zarządzanie portfelem polega na robieniu właściwych rzeczy. Nie ma znaczenia, jak dobrze prowadzisz swoje projekty, jeśli są to nieodpowiednie projekty. Chodzi o to, by mieć wyraźny cel.

Przykład: projekt jako całość

Elastyczność produktu różni się w zależności od projektu. W niektórych projektach informatycznych produkt jest całkowicie elastyczny, a jego ostateczna forma zależy od informacji zwrotnych, które są generowane przez przyrosty produktu w trakcie projektu. Wymaga to podejścia adaptacyjnego (Agile). W praktyce jest to połączenie warstwy portfela, programu i projektu, które wymaga poświęcenia maksymalnej uwagi ostatecznemu celowi. Dobrym pomysłem jest udokumentowanie celu i udostępnienie go. Jest to jeden z celów „wizji produktu”, używanej w niektórych projektach Scrum. Dbałość o wartość biznesową w projektach Agile jest ich sposobem na zapewnienie zgodności z celem.

W innych typach projektów, gdzie produkt jest stosunkowo stały i istnieją inne mechanizmy zapewniające, że zidentyfikowany produkt spełni cel, członkowie zespołu projektowego mogą przenieść dużą część swojej uwagi z celu na produkt (stąd zasada „koncentracji na produktach” w PRINCE2^®), ale przynajmniej minimalna dbałość o cel jest nadal przydatna, aby zapewnić, że to, co jest budowane, pozwoli osiągnąć cel. Można to zrobić porównując prognozowane korzyści z oczekiwanymi korzyściami (stąd zasada „ciągłego uzasadnienia biznesowego” i temat „uzasadnienia biznesowego” w PRINCE2^®).

Gdy projekt jest prowadzony dla klienta zewnętrznego, klient zwykle ma swój własny cel dla projektu, a Twoja firma jako dostawca może mieć inny cel. Powinieneś zrozumieć i wykorzystać oba te elementy, aby naprawdę odnieść sukces projektu.

Przykład: Monitorowanie projektu

Skupienie się na celu finalnym jest konieczne, ale może być zbyt abstrakcyjne dla wielu codziennych działań. Dlatego potrzebna jest hierarchia czynników biznesowych. Najpierw uzasadnienie i korzyści z projektu są definiowane na podstawie ostatecznego celu, a następnie zarysują się wyraźne i ukryte cele dla poszczególnych parametrów projektu (np. czas, koszt i jakość), których osiągniecie będzie konieczne dla utrzymania zasadności biznesowej, co z kolei pozwoli osiągnąć cel ostateczny. Są to cele niższego poziomu, które są przydatne w wielu naszych codziennych zadaniach.

Jeśli chodzi o monitorowanie projektu, na niskim poziomie będzie się ono odbywać przy użyciu zmiennych o najniższym poziomie, ponieważ śledzenie ostatecznego celu może nie być możliwe. W takim przypadku nadal powinieneś mieć na uwadze cel. Jaki jest inny cel monitorowania?

Normalną i akceptowalną odpowiedzią jest sprawdzenie, czy jesteśmy na dobrej drodze, a jeśli już nie jesteśmy, przeprowadzenie pewnej reakcji, która sprowadzi nas z powrotem na właściwy tor lub modyfikacja celów i sprawdzenie, czy nadal jest osiągalny cel ostateczny. Nasze pomiary powinny zatem pozwolić nam w realizacji celów niskiego poziomu i dają prognozy dla zmiennych na zakończenie projektu, w tym: kiedy będziemy mogli domknąć projekt? Ile pieniędzy potrzebowalibyśmy na ukończenie projektu?

Wszystkie inne pomiary, takie jak dotychczasowe wartości planowane i rzeczywiste, są tylko wartościami pośrednimi, które są potrzebne do obliczenia prognoz, a nie wartościami końcowymi, które stosujesz do celów zarządczych.

Przykład: Dokumenty

Bez względu na to, jakie podejście do rozwoju produktu zastosujesz w projekcie, planowanie jest zawsze konieczne. Ważną kwestią jest poziom szczegółowości każdego rodzaju planu. Jeśli w planie nie ma wystarczająco dużo szczegółów, plan nie zapewni wystarczających informacji, a realizacja projektu będzie oparta na decyzjach doraźnych, a nie zintegrowanych i całościowych. Z drugiej strony wiele osób stara się być ostrożnym, dodając do planu zbyt wiele szczegółów, co sprawia, że jest on zbyt trudny zarówno w przygotowaniu jak i utrzymaniu, a przy tym zbyt sztywny, zważając na niepewność projektu. W rezultacie plan staje się nierealny i bezużyteczny.

Najlepszym sposobem na określenie poziomu szczegółowości jest uwzględnienie celu dla każdego elementu planu. Na przykład, jeśli rozważasz dodanie zasobów do planu, powinieneś mieć dla tego cel: Jak zamierzasz z niego korzystać? Jak to pomoże projektowi? Ile wysiłku to wymaga? Czy warto?

Czasami chodzi o podjęcie decyzji, czy chcesz mieć jakiś element w swoich planach, a czasami o sposób, w jaki chcesz coś zaplanować lub przygotować. Niezależnie od tego, czy jest to uzasadnienie biznesowe, karta projektu, czy raport: nadal powinieneś zadać sobie pytanie, dlaczego przygotowujesz ten dokument i jak może on pomóc projektowi.

Szukanie „szablonu” jest przeciwieństwem robienia czegoś w określonym celu.

Przykład: raportowanie stanu projektu

W wielu projektach często pojawiają się naprawdę długie raporty o stanie projektu. W oparciu o NUPP powinniśmy zadać sobie pytanie, jaki jest cel raportu i jak możemy go osiągnąć, niezależnie od tego, co robi wiele innych osób.

W wielu przypadkach może to prowadzić nas do przygotowania bardzo prostych, jednostronicowych raportów, które interesariusze naprawdę czytają i rozumieją, zamiast długich raportów. To zwrócenie uwagi na cel.

Jeśli jednak przygotowujesz jednostronicowe raporty, niektóre osoby mogą mieć do ciebie zastrzeżenia i sądzić, że nie masz „właściwego” systemu monitorowania. W praktyce tworzy to dla ciebie drugi cel (oprócz pierwszego celu, którym jest pomoc interesariuszom w zrozumieniu statusu projektu), i aby go zaspokoić, możesz po prostu utworzyć drugi rodzaj raportu, który jest bardzo długi. Jednak nie powinieneś mieszać tego z pierwszym raportem, ponieważ te dwa cele są zupełnie inne.

Przykład: uzasadnienie biznesowe i karta projektu

Przygotowanie dokumentów, takich jak uzasadnienie biznesowe i karta projektu, jest nierzadko postrzegane jak nudna, bezowocna, biurokratyczna konieczność, podczas gdy wszystkie te dokumenty mają uzasadnione cele, które odnoszą się do większości projektów. Jeśli spróbujesz znaleźć „szablon” i go wypełnić, praca jest po prostu zmarnowana; podczas gdy zamiast tego możesz sprawdzić prawdziwy cel tych dokumentów, zobaczyć, czy i jak mogą być pomocne w twoim projekcie, a następnie przygotować dokument w dowolny sposób, aby spełnić te cele. I to będzie właściwy dokument.

Gdy zastanawiasz się, w jaki sposób możesz dostosować dokumenty, aby spełniały ich cele, możesz nie przewidzieć każdego możliwego scenariusza i możesz coś przeoczyć. Aby tego uniknąć, warto sprawdzić, co sugerują różne metodyki i kompendia , takie jak PRINCE2^®, PMBOK^® Guide, P3.express i DSDM^®, a następnie ocenić te sugestie w oparciu o cele.

Przykład: post-projekt

Chociaż projekt ma określony cel i możemy go mieć na uwadze w całym cyklu życia projektu, realizacja celu jest oceniana głównie na podstawie prognoz dokonanych w trakcie projektu. Nie powinniśmy jednak o ocenie zapominać w momencie zakończenia projektu. Ważne jest, aby na zakończeniu projektu sprawdzić realizację celów, ponieważ możemy zobaczyć, w jakim stopniu zostały osiągnięte cele ostateczne i potraktować to jako źródło wartościowej wiedzy dla kolejnych projektów. Czasami też cele są osiągane dopiero wtedy, gdy po zakończeniu projektu wykonujemy jakieś dodatkowe zadania. Te dodatkowe zadania wymagają również monitorowania.

Monitorowanie po zakończeniu projektu jest niezbędnym krokiem, ściśle powiązane z ukierunkowaniem na cel. Jest to głównie obowiązkiem systemów zarządzania programami i portfelami, a ponieważ większość firm nie ma takich warstw zarządzania, ten krok jest zwykle zaniedbywany. Dlatego metody takie jak P3.express i DSDM^® dodają ten krok do metodyk zarządzania projektami.

Przykład: Prostota

Świat jest złożony i chaotyczny, a nasze modele są abstrakcyjnymi przybliżeniami, które odzwierciedlają wycinki rzeczywistości, mogą zatem być proste. Do tego jeszcze proste systemy zazwyczaj działają lepiej, ponieważ możemy skupić się na głównej idei.

Wielu z nas próbuje uzyskać lepsze wyniki, podnosząc złożoność naszych systemów, mając nadzieję, że w ten sposób systemy dopasują się do złożoności świata. W praktyce jednak utrudnia to pracę z systemem i zwykle uniemożliwia nam spełnienie celu.

Przykład: dostosowanie

Oprogramowanie do strumieniowego przesyłania muzyki ma zupełnie inne uwarunkowania niż oprogramowanie używane w szpitalu lub w samolocie, od którego może zależeć życie ludzi, lub oprogramowanie, które będzie używane na satelicie, gdzie muszą pracować przez wiele lat bez awarii, a wszystkie różnią się od budowy letniej willi, straży pożarnej i zakładu przetwórczego.

Mając na uwadze cele, lepiej zrozumiesz, jak dostosować systemy i artefakty do różnych projektów.

▼ PDF