Rozpocznij swoje projekty właściwie (z Suze Haworth)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów przy użyciu programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie jest poprawny w 100% przypadków.

Ben Aston:

Witamy w podcaście DPM, w którym wykraczamy poza teorię, aby udzielać ekspertom ds. zarządzania projektami porad dotyczących skuteczniejszego prowadzenia projektów cyfrowych. Dziękuję za dostrojenie się. Nazywam się Ben Aston, jestem założycielem The Digital Project Manager.

Wszyscy wiemy, że początek projektu ma kluczowe znaczenie dla jego sukcesu, ale może być też bardzo trudnym etapem. Pojawia się wiele niejasności, zamieszania, nieporozumień i ogromna doza niepewności. Jako kierownicy projektów naszym zadaniem jest uruchomienie projektu i utrzymanie jego tempa, a dodatkowe punkty otrzymujemy wtedy, gdy faktycznie zaczniemy prowadzić go we właściwym kierunku. Co możemy zrobić, aby upewnić się, że projekt od początku zmierza w dobrą stronę? Jak rozpocząć wszystko właściwie? Właśnie o tym jest dzisiejszy podcast. Słuchaj dalej, aby dowiedzieć się, jak prawidłowo rozpoczynać projekty.

Dziś towarzyszy mi Suze Haworth. Cześć, Suze.

Suze Haworth:

Cześć.

Ben Aston:

Suze jest jedną z naszych stałych ekspertek ds. zarządzania projektami cyfrowymi w The Digital Project Manager. Pracuje w Londynie jako niezależna starsza kierowniczka projektów cyfrowych. Suze, może opowiesz nam trochę o projektach, nad którymi ostatnio pracowałaś?

Suze Haworth:

Tak. Jestem niezależną kierowniczką projektów. Kilka tygodni temu zakończyłam kontrakt w agencji, który trwał dość długo. Pełniłam tam dwie kluczowe funkcje. Pierwsza przypominała rolę dyrektorki programu w ramach jednego klienta. Była to firma Specsavers — bardzo duża brytyjska marka okularów działająca również w krajach nordyckich i Australii. Zarządzałam starszym kierownikiem projektu odpowiedzialnym za obszary kreatywne, doświadczenie użytkownika i projekty cyfrowe Specsavers. Był to więc dość duży program prac. Pracowałam także nad projektem dla Ikei. Był to projekt zaprojektowania i zbudowania prototypu systemu projektowego dla tej marki.

Ben Aston:

Świetnie. Czyli Specsavers to bardziej projekt związany z handlem elektronicznym i optymalizacją konwersji?

Suze Haworth:

Tak, zależało to od rynku, ale firma właściwie nie sprzedaje okularów online z powodu określonych regulacji. Duża część prac polegała więc na kierowaniu ludzi do umawiania wizyt i odwiedzania salonów. Było tam jednak sporo optymalizacji konwersji, tak jak mówisz.

Ben Aston:

Co było trudne w tych projektach? Z jakimi wyzwaniami mierzyliście się w samym projekcie, we współpracy z klientem albo w zespole? Zawsze interesujące jest usłyszeć, że inni mają podobne problemy. Co było trudne?

Suze Haworth:

W przypadku programu Specsavers był to bardzo interesujący moment, ponieważ rozpoczęłam pracę w marcu, czyli na początku nowego roku, i przeszliśmy na zupełnie nowy sposób pracy. Wcześniej działaliśmy jako agencja projektowa współpracująca z ich agencją deweloperską. Nasi pracownicy byli częścią wszystkich zespołów Scrum: w każdym zespole i strumieniu prac znajdowali się projektant i specjalista UX. Zdecydowaliśmy się usunąć wszystkich projektantów i specjalistów UX z tych zespołów, połączyć ich po naszej stronie w jeden zespół i przejść na proces dwutorowy. Prowadziliśmy tor odkrywania, który znajdował się niejako nad torem realizacji, opartym bardziej na pracy zespołu deweloperskiego w Scrumie.

Dzięki temu mieliśmy przestrzeń na testy użytkowników, eksplorację, formułowanie hipotez i założeń oraz ich sprawdzanie z użytkownikami. Prowadziliśmy znacznie więcej badań i korzystaliśmy z większej ilości danych, które zasilały ten proces. Dawało nam to większe pole manewru i pozwalało dostarczać rzeczy, których użytkownicy rzeczywiście potrzebowali. Wdrożenie tego sposobu pracy, uruchomienie go i doprowadzenie do sprawnego działania było bardzo interesujące. Było też sporym wyzwaniem, ale naprawdę ekscytującym.

Ben Aston:

Czy twoją rolą była wtedy rola właścicielki produktu? Mieliście dwa równoległe strumienie prac: jeden dotyczący strategii, UX i projektowania, gdzie zapewne przeprowadzaliście testy użytkowników, aby rozpoznać ich potrzeby, następnie ustalaliście priorytety, przekazywaliście część potrzeb do strumienia UX i projektowania, a potem do deweloperów. Czy tak to działało?

Suze Haworth:

Tak. Zauważyliśmy, że gdy projektant i specjalista UX pracowali w zespole Scrum, praca w dwutygodniowych sprintach i próba dostarczenia czegoś w tym czasie bardzo ich ograniczały. Dużo czasu zajmowały techniczne aspekty pracy. Uczestniczyli w długich spotkaniach planowania sprintu, choć dotyczyła ich tylko niewielka część, albo brali udział w spotkaniach i codziennych odprawach poświęconych głównie błędom. Zamiast koncentrować się na potrzebach klientów, praca stawała się bardziej techniczna. Dlatego usunęliśmy ich z zespołu i utworzyliśmy niemal nadrzędny tor pracy, zapewniający odpowiednią ilość czasu. Nadal działaliśmy szybko, ale mogliśmy analizować istniejące dane i badania, a także własne badania, następnie identyfikować założenia i hipotezy dotyczące sposobów rozwiązania problemów klientów.

Potem mogliśmy szybko przygotować projekt UX lub prototyp, zależnie od potrzeby, i bardzo szybko pokazać go klientom. Mogli oni zweryfikować rozwiązanie, zanim trafiło do realizacji. Pozwalało to usprawnić proces tworzenia, ponieważ nie budowaliśmy rzeczy, których klienci nie chcieli. Aktualizowaliśmy decyzje projektowe i UX przed rozpoczęciem sprintów. W torze odkrywania nadal uczestniczyli pracownicy techniczni, ale zamiast sprawdzać wyłącznie wykonalność techniczną, mogliśmy powiedzieć: „To jest to, czego chce klient, i podoba mu się zaprojektowana przez nas funkcja”. Chodziło więc o usprawnienie procesu, ale także o skoncentrowanie się na dostarczaniu tego, czego potrzebuje klient, a nie tylko tego, co da się zrobić.

Ben Aston:

Myślę, że to wyzwanie dotyczy wielu agencji próbujących pracować w Scrumie. Scrum nie jest oczywiście jedynym sposobem prowadzenia projektu zwinnego, ale wydaje się ogólnie przyjętą zasadą. Jednym z głównych problemów podczas stosowania Scruma w agencji jest pytanie: co w sprincie mają robić UX i projektowanie? Można sprawić, że UX i projektowanie będą kilka sprintów przed programistami, ale wtedy nic nie jest faktycznie kończone. Sprint powinien kończyć się czymś gotowym do wdrożenia i spełniającym kryteria akceptacji, a przejście przez strategię, UX, projektowanie i budowę funkcji w ciągu dwóch tygodni jest bardzo trudne.

Podoba mi się pomysł prowadzenia dwóch równoległych strumieni prac, a następnie przenoszenia zweryfikowanych elementów przez właściciela produktu do rejestru prac deweloperskich. Mamy wtedy dwa rejestry: strategiczny, w którym pytamy, czy robimy właściwą rzecz, oraz drugi, w którym znajdują się elementy już zweryfikowane i gotowe do zbudowania. To rzeczywiście rozwiązuje część problemów.

Suze Haworth:

Dokładnie. Jak mówiłam, budujemy funkcje, które zostały zweryfikowane i których klienci potrzebują, więc powstaje znacznie mniej marnotrawstwa. Proces jest bardziej oszczędny, co moim zdaniem może być tylko korzystne.

Ben Aston:

Dobrze. Porozmawiajmy o inicjowaniu projektów i ich faktycznym rozpoczynaniu. Czy byłaś zaangażowana od początku w projekt Ikei albo Specsavers?

Suze Haworth:

W przypadku Specsavers był to zespół utrzymywany przez cały rok, z określonym zakresem prac i strukturą zespołu. Dołączyłam po wstępnym, dość ogólnym określeniu sposobu pracy i spisaniu zakresu. Jednym z wyzwań, o których piszę w artykule, jest przejęcie czegoś, co już się rozpoczęło albo zostało określone przez kogoś innego. Przejęłam ten projekt niedługo po ustaleniu zakresu, ale sposób pracy był zdefiniowany tylko ogólnie. Gdy zaczęliśmy go wdrażać, okazało się, że wymaga korekt i zmian. W praktyce znacznie się rozwinął w stosunku do pierwotnych założeń, ponieważ podczas pracy odkrywa się rzeczy, które nie działają i wymagają dostosowania.

Projekt Ikei również był realizowany etapami. Nie pracowałam przy pierwszym etapie i dołączyłam dopiero przy drugim, więc projekt rozpoczął się przed moim przyjściem.

Ben Aston:

Często tak właśnie wyglądają projekty przejmowane przez kierowników projektów. Nie zawsze obejmujemy je od samego początku. To może zwiększać zamieszanie, prawda? Jako kierownik projektu zostajesz dołączony do projektu, który ktoś przekazał z działu rozwoju biznesu, obsługi klienta albo sprzedaży. Dziedziczysz coś, co zostało zaplanowane, ale nie w pełni. Pozostaje pewien poziom niepewności. Dlatego inicjowanie projektu dotyczy także sytuacji, gdy projekt zostaje przekazany w dowolnym momencie jego trwania.

Porozmawiajmy o rzeczach opisanych przez ciebie w artykule: zarządzaniu ludźmi, procesem i produktem oraz uzyskiwaniu zgodności i jasności w tych obszarach. Chodzi więc o to, kto, jak i co. Zacznijmy od ludzi. Kiedy przejmujesz projekt albo rozpoczynasz go po raz pierwszy, co próbujesz zrobić z perspektywy zespołu, aby wszystko ruszyło we właściwym kierunku?

Suze Haworth:

Jest kilka podstawowych grup i osób, o których trzeba pomyśleć. Po pierwsze, zespół: kto będzie pracował nad projektem? Na etapie inicjowania określasz, kogo można zarezerwować i kto będzie pracować przy projekcie. Ważne jest nie tylko to, kto jest dostępny, lecz także kto pasuje do projektu — jakie ma umiejętności, jak pracuje, z jakimi projektami i klientami mamy do czynienia.

Jeśli znasz członków zespołu, warto zastanowić się, kto najlepiej sprawdzi się w danej pracy i kto będzie dobrze współpracował z innymi. Oczywiście nie zawsze jest to możliwe i czasem decyduje wyłącznie dostępność, ale warto pomyśleć o tym z wyprzedzeniem. Nawet jeśli musisz wykorzystać określone osoby, świadomość tego, jak pracują, może pomóc później, gdy pojawią się problemy.

Trzeba też zadbać o to, aby osoby pracujące przy projekcie były zaangażowane od początku. Przez lata pracy z projektantami, programistami i osobami zajmującymi się zapewnianiem jakości zauważyłam, że jedną z najbardziej nielubianych sytuacji jest dołączenie do projektu dopiero wtedy, gdy wszystko zostało już określone i zdecydowane. Nie chodzi o to, aby ktoś otrzymał gotowe zadanie i usłyszał: „Czy możesz po prostu to zaprojektować?” albo „Czy możesz po prostu to zbudować?”. Gdy odbiera się ludziom autonomię i wyłącznie mówi im, co mają robić, pojawia się problem.

Jeśli mamy wystarczająco dużo czasu i budżetu, dobrze jest zaangażować ich choćby w niewielkim stopniu od początku. Po początkowym wewnętrznym spotkaniu rozpoczynającym projekt porozmawiaj z nimi o tym, co sądzą o projekcie, jak chcieliby pracować i jakie mają oczekiwania. Dzięki temu od początku czują się zaangażowani.

Ben Aston:

To wraca do kwestii zasobów. W miarę możliwości trzeba z wyprzedzeniem zapewnić potrzebny zespół i jak najwcześniej zaangażować go w projekt, aby uzyskać jego poparcie. Ludzie często reagują, gdy przejmują coś, co ktoś przemyślał, ale nie miał wystarczająco dużo czasu, by zrobić to właściwie. Mówią wtedy: „Chwileczkę, dlaczego to robimy? Ja zrobiłbym to inaczej”. Chcemy, aby myśleli: „Tak, to jest także mój projekt”. Poczucie własności, zamiast reagowania na cudzy niedopracowany pomysł, zwykle prowadzi do znacznie lepszych rezultatów.

Suze Haworth:

Dokładnie.

Ben Aston:

Przejdźmy do procesu. Wiemy już, kto jest w zespole. Jak wykorzystamy ten zespół do realizacji projektu? Często pojawiają się nieporozumienia dotyczące sposobu realizacji projektu, procesu, metodyki czy narzędzi. Jak uzgadniasz stanowiska zespołu i radzisz sobie z niemal nieuniknionymi różnicami zdań?

Suze Haworth:

Prawdopodobnie nigdy nie znajdziemy idealnego procesu, który pod każdym względem będzie odpowiadał wszystkim. Napięcia mogą pojawiać się na różnych etapach projektu. Czasem dziedziczysz proces, który obowiązuje w agencji lub organizacji, a czasem narzuca go klient. Jeśli możesz ustalić go samodzielnie, masz szczęście, bo możesz dopasować go do projektu i klienta.

Jeżeli proces jest już określony, warto podczas wewnętrznego spotkania rozpoczynającego projekt omówić go z zespołem, wyjaśnić, dlaczego go stosujemy, i spróbować wcześnie uzyskać poparcie członków zespołu. Bardzo ważne jest też dostosowywanie procesu w trakcie pracy. Nie należy sztywno trzymać się czegoś, co nie działa. Zespół powinien wiedzieć, że jeśli ma problemy z procesem, narzędziami albo sposobem komunikacji, powinien otwarcie o tym mówić. Wtedy można znaleźć sposób na ograniczenie problemów, dostosować działania i posunąć pracę naprzód.

Ben Aston:

Elastyczność jest tu kluczem do sukcesu. Kierownicy projektów albo członkowie zespołów często mówią: „Tak nie działa Scrum”, „To nie jest zwinne” albo „To zbyt kaskadowe”. Tak naprawdę nie ma znaczenia, czym coś jest lub czym nie jest. Liczy się to, co najlepiej działa dla zespołu, projektu i klienta. Nie warto dogmatycznie trzymać się jednej metody. Trzeba odpowiedzieć na pytanie: przy tym zespole i tej pracy, jaki sposób realizacji będzie najlepszy?

W pewnym sensie oznacza to wymyślanie koła na nowo, ale nasze projekty są różne, dlatego zastosowanie jednego procesu albo jednej metody do wszystkiego jest bardzo trudne. Wyjątkiem mogą być prace utrzymaniowe lub niewielkie, ciągłe aktualizacje funkcji, gdzie standaryzacja ma sens.

Omówiliśmy więc to, kto, czyli zespół i interesariusze, oraz jak, czyli proces i elastyczność. Pozostaje pytanie, co faktycznie tworzymy i dostarczamy. Często przejmujesz luźny zakres prac od zespołu sprzedaży albo luźny zestaw wymagań klienta. Jak usuwasz niejasności dotyczące projektu lub produktu i dochodzisz do momentu, w którym można powiedzieć: „Ustalmy, że dostarczymy właśnie to”?

Suze Haworth:

Zależy to od rodzaju projektu. Na początku nie chcę, aby wszystko było zbyt sztywno określone, ponieważ wiele rzeczy może się zmienić i projekt może ostatecznie wyglądać zupełnie inaczej. Wolę zakresy, które dopuszczają zmiany i nie ustalają całkowicie sztywno wszystkich rezultatów z góry.

Aby określić zakres, trzeba rozpocząć rozmowy i uzyskać od klienta jasne wymagania. Należy upewnić się, że rozumiemy potrzeby użytkowników, potrzeby biznesowe i kontekst projektu. Następnie trzeba opracować wymagania wspólnie z zespołem. Chodzi o wczesne zaangażowanie nie jednej osoby, lecz kilku liderów poszczególnych dziedzin albo członków zespołu. Należy omówić z nimi zakres i wymagania oraz określić możliwe ramy projektu.

Ben Aston:

Podczas pierwszych sesji, w których próbujemy zdefiniować, co właściwie robimy, dobrze jest zebrać ludzi w jednym pomieszczeniu na pół dnia, przygotować tablicę, karteczki samoprzylepne i wspólnie zbudować ogólny obraz rozwiązania. Chodzi o uzyskanie wspólnego zrozumienia i zgodności. Na początku ludzie często różnie rozumieją te same rzeczy. Rysowanie i umieszczanie elementów na ścianie wymusza rozmowę: ktoś mówi „Myślałem, że to oznacza coś innego”, a ktoś inny odpowiada „Nie, chodzi o coś zupełnie innego”. W ten sposób identyfikujemy obszary niejasności, a następnie możemy wrócić do klienta z różnymi sposobami podejścia.

Ważny jest ogólny obraz projektu i doprowadzenie wszystkich do wspólnego rozumienia. Zdjęcie tablicy z takiej sesji staje się później punktem odniesienia. Pozwala zobaczyć, jak wszystkie elementy łączą się ze sobą i co dostarczamy. Wstępna architektura rozwiązania wyznacza granice projektu i pokazuje, dokąd zmierzamy. W ten sposób można określić parametry projektu, a następnie rozpocząć proces odkrywania z pewnym poziomem zgodności.

Suze Haworth:

Zdecydowanie. Warsztaty tego rodzaju są świetne. Nawet jeśli ustalenia się zmienią, stanowią punkt wyjścia. Warto przeprowadzić podobne warsztaty z klientem. To dobry sposób na rozpoczęcie projektu, ponieważ pozwala lepiej zrozumieć jego perspektywę, a klient widzi, jak my rozumiemy projekt. Można najpierw przeprowadzić sesję wewnętrzną, a potem wspólnie z klientem pracować podczas półdniowych spotkań.

Ben Aston:

Omówiliśmy więc kto, czyli ludzi i zespół, jak, czyli proces i metodykę, oraz co, czyli wstępny zarys rozwiązania i architektury. Możemy przy tym nakreślić również budżet, harmonogram i wskaźniki sukcesu. Umieszczenie wszystkiego na jednej dużej tablicy, nawet jeśli później ulegnie zmianie, jest bardzo pomocne.

Czasem inicjowanie projektu odbywa się jeszcze przed jego formalnym zatwierdzeniem. Pojawia się wtedy pytanie, jak daleko się posunąć. Czy robisz tyle, ile się da, czy zachowujesz ostrożność i robisz tylko tyle, aby trochę przesunąć projekt do przodu? Często nie ma jeszcze pełnej akceptacji, ale wiemy, że bez dodatkowej pracy nie dotrzymamy terminu realizacji. Jak zarządzasz napięciem między ryzykiem wejścia w ślepą uliczkę a ostrożnością, która może sprawić, że za kilka tygodni nie będziesz wystarczająco daleko z pracami?

Suze Haworth:

Skłaniam się raczej ku ostrożności, ale trzeba być całkowicie otwartym. Jeśli klient opóźnia zatwierdzenie albo wielokrotnie wraca do zakresu, należy uświadomić mu, jak opóźnienie wpłynie na cały projekt. Trzeba znać ryzyko związane z brakiem ustaleń, aby móc formalnie rozpocząć pracę.

Jednocześnie warto popychać rzeczy naprzód. Nawet ostrożne podejście może oznaczać zrobienie tylko tyle, aby trochę utrzymać ruch projektu. Na początku ważne jest zachowanie tempa. Zespół angażuje się, rozmawia o projekcie i ekscytuje się tym, co zbuduje lub zaprojektuje. Jeśli wszystko zwolni i się zatrzyma, członkowie zespołu, a czasem także klienci, mogą przenieść uwagę na coś innego. Dlatego dobrze jest utrzymywać choćby niewielki postęp.

Ben Aston:

Brak tempa na początku projektu jest typowym problemem. Ludzie słyszą o projekcie, ale nic się nie dzieje. Z powodu niejasności albo pytań, na które trzeba odpowiedzieć, projekt się zatrzymuje. Co robisz w sytuacji, gdy wszystko wydaje się stać w miejscu?

Suze Haworth:

To trudne, ponieważ ludzie mogą być już zarezerwowani do projektu, ale nie ma jeszcze formalnej zgody i nie można przydzielić im godzin pracy. Jeśli jednak masz czas, który możesz wykorzystać, warto przeznaczyć go na lekkie rozpoczęcie działań przez zespół. Można utrzymać zaangażowanie, wykonując podstawowe badania, analizując istniejące dane i konkurencję albo rozpoczynając proces myślowy. Dzięki temu zespół pozostaje zaangażowany na niższym poziomie do czasu oficjalnego rozpoczęcia prac.

Ben Aston:

Nawet krótkie spotkanie z zespołem może pomóc. Można powiedzieć: „Wiem, że sądziliśmy, iż projekt rozpocznie się w tym tygodniu. Tak się nie stanie, ale oto najnowsze informacje”. Warto utrzymywać zaangażowanie zespołu, aby projekt całkowicie nie zniknął z jego radaru.

Suze Haworth:

Nie ma nic gorszego niż całkowita cisza, a następnie pojawienie się po trzech tygodniach lub miesiącu z informacją: „Świetnie, teraz możemy zaczynać”. Warto informować zespół o rozmowach z klientem, powodach opóźnienia, przewidywanym terminie rozpoczęcia i tym, co można zrobić w międzyczasie. Najważniejsze jest podtrzymywanie rozmowy.

Ben Aston:

Porozmawiajmy o jeszcze jednym wyzwaniu, z którym mierzy się wielu kierowników projektów: przejęciu projektu w połowie jego trwania. Dziedziczymy wtedy czyjś plan dotyczący ludzi, procesu i produktu, ale odpowiedzialność za realizację spada na nas. Jak radzisz sobie z takim chaosem?

Suze Haworth:

To jedno z największych wyzwań, ponieważ zwykle nie uczestniczysz w projekcie od samego początku. Początkowe prace często odbywają się na etapie oferty albo wtedy, gdy zespół sprzedaży definiuje projekt. Zajmuje się tym szef zarządzania projektami, dostarczania lub inni członkowie zespołu. Projekty, nad którymi pracujesz, pochodzą więc często z innego miejsca i mają już określone oczekiwania.

Często pracujesz z wcześniej uzgodnionymi kosztami i bardzo luźnym zakresem, który trzeba dopasować do budżetu. Należy wziąć istniejące parametry i ustalić, gdzie jest elastyczność oraz pole manewru. Jeśli koszt został już określony, trzeba przyjrzeć się zakresowi i sprawdzić, co rzeczywiście można dostarczyć. Jeśli projekt został sprzedany zbyt szeroko, trzeba szczerze porozmawiać o tym, że zakres jest zbyt duży w stosunku do kosztu. Należy realistycznie ocenić, co można dostarczyć, i ustalić, czy trzeba zmienić zakres albo harmonogram.

Jeśli przejmujesz projekt w połowie jego trwania, najważniejsze jest zebranie jak największej ilości informacji: o projekcie, dotychczasowych działaniach, dostarczonych elementach, kliencie i wszystkim, co się wydarzyło. Następnie warto niemal zresetować projekt. Zorganizuj kolejne, krótkie spotkanie rozpoczynające, nawet jeśli projekt już trwa. Zbierz zespół, spotkaj się z klientem i jasno pokaż, że jest to punkt ponownego uruchomienia. To ważne, ponieważ nawet jeśli ludzie czują, że już raz przechodzili przez ten etap, ponowne rozpoczęcie pozwala zrozumieć, co się wydarzyło, co nie działało, co należy zmienić, a co kontynuować.

Ben Aston:

Taki reset wymaga pewności siebie i jest bardzo skuteczny. Kiedy dołączasz do projektu, początkowo możesz niczego nie wiedzieć, ale zadawanie trudnych, a nawet pozornie głupich pytań niemal zawsze ujawnia niejasności, które mają również inni członkowie zespołu. W trakcie projektu ludzie zaczynają przyjmować założenia, których nie dokumentują, a ich rozumienie ponownie zaczyna się rozchodzić. Reset pozwala zapytać: „To może być głupie pytanie, ale jak działa ten element? Jak łączy się z inną rzeczą, którą budujemy?”. W ten sposób ujawniają się problemy, o których nikt jeszcze nie pomyślał, oraz ukryte wyzwania wymagające rozwiązania. To bardzo użyteczne działanie.

Suze Haworth:

Zdecydowanie nie należy bać się zadawania wielu pytań. Zawsze to powtarzam, szczególnie nowym kierownikom projektów: pytajcie. Nie obawiajcie się, że zabrzmicie głupio. Lepiej zadać pytania i dowiedzieć się wszystkiego, co jest potrzebne, niż milczeć i później zostać zaskoczonym. Trzeba zadawać wiele pytań.

Ben Aston:

To dobra rada dotycząca inicjowania projektów jako całości. Sztuka dobrego rozpoczynania projektów sprowadza się w dużej mierze do komunikacji. Chodzi o zadawanie trudnych pytań, których nikt nie chce zadawać, oraz o odwagę, by pytać o kwestie trudne, niezręczne i irytujące. Właśnie tak dochodzimy do jasności. Gdy uda się zdefiniować rzeczy i uzyskać wspólne rozumienie celu, projekt przebiega znacznie sprawniej, a marnotrawstwo pracy i wysiłku jest mniejsze. Wszyscy zaczynają zmierzać w stronę wspólnego celu. Suze, bardzo dziękuję za udział. Wspaniale było mieć cię z nami.

Suze Haworth:

Dziękuję. To była przyjemność.

Ben Aston:

Jako jedna z naszych ekspertek DPM Suze pojawi się również w naszym nadchodzącym kursie, który rozpoczyna się w lutym. Nazywa się on „Mistrzostwo w zarządzaniu projektami cyfrowymi” i jest siedmiotygodniowym intensywnym kursem obejmującym interaktywne lekcje wideo, dyskusje panelowe oraz możliwość udziału w sesjach coachingowych. Jeśli chcesz lepiej zrozumieć, jak skuteczniej inicjować projekty i właściwie je rozpoczynać, odwiedź stronę DPMSchool.com i zapisz się, zanim kurs zostanie zapełniony. Jeśli chcesz dołączyć do rozmowy o inicjowaniu projektów i sposobach jego usprawnienia, skomentuj wpis, a także odwiedź sekcję zasobów serwisu DigitalProjectManager.com, aby dołączyć do naszego zespołu na Slacku. Znajdziesz tam wiele rozmów o inicjowaniu projektów i zarządzaniu nimi. Do usłyszenia następnym razem. Dziękuję za słuchanie.