Uratuj swój projekt dzięki dokumentowi inicjującemu projekt (z Maikiem Stettnerem z FCV Interactive)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.

Ben Aston:

Dziękuję za dołączenie. Nazywam się Ben Aston, a to jest podcast The Digital Project Manager. Ten podcast powstaje dzięki firmie Clarizen, liderowi w dziedzinie oprogramowania do zarządzania przedsiębiorstwami, projektami i portfelami projektów. Odwiedź stronę clarizen.com, aby dowiedzieć się więcej.

Jeśli jest jedna rzecz, której możemy być pewni w przypadku projektu, to to, że nigdy nie przebiegnie on zgodnie z planem. Dlaczego jednak projekty wymykają się spod kontroli? Czasami po prostu dlatego, że rozpoczynamy je zbyt szybko. Widzimy, że termin realizacji zbliża się coraz bardziej, więc zaczynamy projekt w lekkiej panice, a kiedy sprawy zaczynają iść źle, zastanawiamy się, dlaczego tak się dzieje.

Zwykle mamy w głowie całe tło projektu, strategię, szczegóły, wymagania i mierniki sukcesu. Często popełniamy jednak błąd, zakładając, że wszyscy pozostali również powinni to wszystko wiedzieć. Rzeczywistość jest taka, że jeśli informacje nie zostały udokumentowane, istnieje duża szansa, że nasz zespół po prostu ich nie zna.

Dlatego dziś porozmawiamy o narzędziu, którego możemy użyć, aby od samego początku projektu wszyscy mieli wspólne zrozumienie sytuacji. Chodzi o dokument inicjujący projekt, często nazywany w naszej branży kartą projektu. Pokażemy, jak stworzyć dokument inicjujący projekt i wykorzystywać go do skuteczniejszej realizacji projektów.

Dziś dołącza do mnie Maik Stettner, jeden z moich przyjaciół i współpracowników. Maik jest jednym z naszych ekspertów DPM w The Digital Project Manager. Witaj, Maik.

Maik Stettner:

Cześć. Jak się masz?

Ben Aston:

Dobrze. Wspaniale, że jesteś z nami. Maik, zacznijmy od ciebie i opowiedzmy wszystkim trochę o twojej historii. Oczywiście pracujemy razem i współpracujemy już — czy to pięć lat?

Maik Stettner:

Tak, minęły już cztery albo pięć lat.

Ben Aston:

Pamiętam, że kiedy zatrudniałem Maika, pomyślałem: „Nie wiem, czy ten człowiek sobie poradzi”. Pochodzisz bowiem z nieco innego środowiska, nie z tradycyjnej agencji. Opowiedz nam o swojej historii. Jak zostałeś kierownikiem projektu w agencji cyfrowej?

Maik Stettner:

Łącznie mam około dziesięciu lat doświadczenia w różnych dziedzinach. Początkowo zajmowałem się grami i publikowaniem, zarządzając premierami gier w Europie i Ameryce Północnej. Później przeszedłem do innych obszarów, takich jak medyczne bazy danych, ale ogólnie zawsze była to praca związana z tworzeniem oprogramowania, zarządzaniem projektami, różnymi zespołami i podobnymi zagadnieniami. W trakcie kariery zdobyłem również doświadczenie agencyjne przy tworzeniu aplikacji oraz początkowo także stron internetowych. Kiedy odbyliśmy pierwszą rozmowę o współpracy, właściwie przeszedłem w pełni do tworzenia stron internetowych i pracy w agencji.

Ben Aston:

Tak.

Maik Stettner:

Od około czterech lat pracuję w obecnej firmie, FCV. Obecnie kieruję zespołem zarządzania projektami w agencji i odpowiadam za całościową realizację projektów oraz za zapewnienie, że klienci są zadowoleni z dostarczanych przez nas rezultatów.

Ben Aston:

Świetnie. Dla osób, które słuchają i być może znajdują się w podobnej sytuacji — często spotykamy ludzi, którzy mówią: „Jestem kierownikiem projektu, mam doświadczenie w zarządzaniu oprogramowaniem, ale rozważam przejście do agencji i zostanie cyfrowym kierownikiem projektu”. Jak wyglądało to przejście w twoim przypadku? Jakie były najważniejsze różnice między światem oprogramowania a światem agencyjnego zarządzania projektami cyfrowymi? Chciałbym lepiej zrozumieć ten kontrast i dowiedzieć się, co osoby rozważające taką zmianę powinny wziąć pod uwagę.

Maik Stettner:

Przede wszystkim istnieje wiele podobieństw. Rzeczy, które spotykasz w innych firmach tworzących oprogramowanie lub w innych dziedzinach związanych z zarządzaniem projektami, występują również w agencji. Masz różnorodne zespoły, projekty wymykają się spod kontroli z wielu powodów i możesz stosować te same działania, aby sobie z tym poradzić.

Jedną z głównych różnic było dla mnie zrozumienie i zastosowanie idei koncentrowania się na czasie i materiałach oraz na mniejszych przyrostach pracy zamiast na większych dostawach. Klienci, szczególnie w obszarze, w którym pracuję, chcą większej przejrzystości i kontroli nad mniejszymi partiami wykonywanej pracy. Wiąże się to z bardziej szczegółowym raportowaniem oraz większym wysiłkiem związanym z transparentnością i wyjaśnianiem klientowi dokładnie tego, co robisz, aby zbudować zaufanie. Wymagało to ode mnie pewnego dostosowania w porównaniu z pracą w firmie produktowej, w której zmierzasz do premiery produktu, być może wewnętrznej.

To była dla mnie główna różnica, ale interesujące było odkrycie, że nawet jeśli pracujesz w zupełnie innej dziedzinie, nieważne, czy tworzysz bazę danych, grę czy stronę internetową, napotykasz dość podobne problemy, które można przenosić z jednej dziedziny do drugiej. Jeśli wykorzystasz doświadczenia z poprzedniej pracy, takie jak dobra komunikacja i standardowe dobre praktyki kierownika projektu, istnieje duża szansa na sukces — niezależnie od tego, co tworzysz.

Ben Aston:

To bardzo dobre. Opowiedz nam więc o wyzwaniach, z którymi spotykasz się teraz, gdy nie tylko zarządzasz projektami, ale także zespołami. Jeśli chodzi o zarządzanie całym portfelem projektów, prowadzenie wielu różnych projektów o sprzecznych wymaganiach dotyczących zasobów — jakie typowe wyzwania napotykasz jako osoba kierująca zespołem PMO?

Maik Stettner:

Moja rola jest obecnie bardziej całościowa. Zasadniczo dbam o to, aby wszystko posuwało się do przodu. Jednym z moich głównych zadań jest zarządzanie zasobami i zapewnienie, że mamy odpowiednich ludzi do odpowiedniej pracy i na odpowiedni czas.

Często trzeba iść na kompromis, gdy coś trwa dłużej, a jednocześnie masz już zaplanowany kolejny projekt. Trzeba wtedy łagodzić skutki zmian i zapewniać klientom bezpośredni kontakt ze mną. Ryzykiem związanym z bardziej całościową, wyższą funkcją jest to, że stajesz się jedyną osobą odpowiedzialną za eskalacje. Nie jest to rola, w której chcesz tkwić cały czas, bo wtedy dzwonią do ciebie tylko osoby, które są zdenerwowane.

Mimo wszystko dobrze jest aktywnie uczestniczyć w różnych projektach i budować relacje oparte na zaufaniu, a jednocześnie dbać o właściwe funkcjonowanie organizacji — pod względem zasobów, operacji i ogólnej współpracy, ponieważ mamy kilka biur.

Dla nas ważne jest, aby osoby z biura w Toronto mogły dobrze współpracować z biurem w Victorii. To właśnie zajmuje większość mojej uwagi. Nadal mam jednak kilku klientów, z którymi ściśle współpracuję, więc wciąż wykonuję sporo pracy związanej z zarządzaniem projektami. To nadal moja pasja i naprawdę lubię pracować dla ludzi, więc nie zamierzam z tego rezygnować.

Ben Aston:

Wróćmy do wyzwania związanego z zarządzaniem zasobami. Każdy, kto kieruje zespołem zarządzania projektami lub jest menedżerem zasobów, będzie musiał się z nim zmierzyć. Załóżmy, że masz dwa kolidujące ze sobą projekty, dwóch kierowników projektu, terminy na piątek i zapotrzebowanie na te same zasoby. Jak wygląda twój proces ustalania priorytetów? Jak decydujesz, który projekt wygrywa? Wielu kierowników projektów stale mówi, że nie ma wystarczających zasobów dla swojego zespołu. Co możesz powiedzieć o podejmowaniu decyzji, który projekt będzie realizowany, a który zostanie przesunięty lub odrzucony?

Maik Stettner:

Najpierw patrzę na priorytet projektu. Czy mamy jakiś termin? Czy obiecaliśmy coś klientowi? Czy projekt musi zostać uruchomiony w określonym dniu? Sprawdzam, czy istnieje jakikolwiek margines czasowy.

Znaczenie ma również to, czy coś zostało określone w umowie. Trzeba dopilnować, aby wszystko zostało wykonane. Czy projekt chce po prostu przyspieszyć i zrobić klientowi przysługę? To dobrze i chętnie to zrobimy, jeśli mamy czas, ale jeśli drugi projekt zostanie uruchomiony za trzy dni, prawdopodobnie nie możemy nikogo z niego wycofać.

To jest punkt wyjścia. Idealnie taka sytuacja nie powinna się wydarzyć, ponieważ kierownik projektu powinien przewidywać dodatkową pracę i uwzględniać bufory. Może zabrzmi to dziwnie, ale oczekuję również od mojego zespołu, że będzie walczył o potrzebne zasoby.

Często członkowie zespołu są zbyt uprzejmi i mówią: „Możesz mieć tę osobę przez jeden dzień”. Ostatecznie prowadzi to do przesunięcia pracy wszystkich. Nie podoba mi się podkradanie i zwykłe zabieranie zasobów — to absolutnie niedopuszczalne. Podczas spotkań dotyczących zasobów oczekuję jednak, że ktoś jasno przedstawi ilość potrzebnego czasu i przekaże problem menedżerowi zasobów, aby ten znalazł rozwiązanie, uzyskał dodatkową pomoc lub ustalił, jak zrównoważyć obciążenie.

Ben Aston:

Może to kanadyjski problem z zasobami.

Maik Stettner:

Na pewno kanadyjski impas.

Ben Aston:

Kanadyjczycy są zbyt uprzejmi — jako Europejczycy możemy chyba tak powiedzieć. A może tylko Kanadyjczycy mogą żartować z takich degeneratów.

Maik Stettner:

Dokładnie. W Europie zdecydowanie postrzegam ich inaczej.

Ben Aston:

Zawsze interesują mnie narzędzia. Czy ostatnio odkryłeś jakieś narzędzie albo zacząłeś korzystać z czegoś, co sprawiło, że pomyślałeś: „To jest świetne! Dlaczego nie zaczęliśmy używać tego wcześniej”? Jaki jest twój zestaw narzędzi?

Maik Stettner:

Masz na myśli zarządzanie zasobami?

Ben Aston:

Zarządzanie zasobami albo ogólnie narzędzia do zarządzania projektami.

Maik Stettner:

Korzystamy z dość standardowego zestawu narzędzi do zarządzania czasem. MS Project bywa dla klienta przytłaczający, dlatego dużo eksperymentujemy obecnie z produktami działającymi w chmurze. Project ma na przykład wersję w ramach Office 365. Przyglądamy się również różnym programom do zarządzania czasem i zasobami. Nie znalazłem idealnego rozwiązania, ponieważ mamy dość dopasowany proces, który niestety częściowo jest również ręczny.

Osobiście uważam, że idealne narzędzie odpowiadające naszym potrzebom właściwie nie istnieje. Moim celem byłoby stworzenie lub zakupienie czegoś, a następnie dostosowanie tego do indywidualnych potrzeb.

Ben Aston:

Co musiałoby się znaleźć w takim narzędziu, aby było użyteczne? Czy chodzi o to, że proces jest tak zawiły lub złożony, że obecne narzędzia nie potrafią go obsłużyć?

Maik Stettner:

Niekoniecznie. Proces jest dość prosty. Szukam narzędzia, które łączyłoby zwykłe zarządzanie czasem i rejestrowanie godzin lub karty czasu pracy pracowników z planowaniem zasobów. Czegoś w rodzaju Resource Guru lub podobnego narzędzia, które pozwala zaplanować potrzebne zasoby, a następnie połączyć to z aspektem finansowym. Zwłaszcza przy rozliczaniu czasu i materiałów podstawowe obliczenie to liczba godzin pomnożona przez stawkę rozliczeniową. Następnie cały proces raportowania powinien być skonfigurowany w ramach tego samego systemu.

Brzmi to łatwo, ale trzeba uwzględnić wiele rzeczy: prawdopodobieństwo realizacji projektów, zmiany w ich przebiegu oraz sposób, w jaki systemy sobie z tym radzą. Może to zaburzać raportowanie i powodować dużo dodatkowej pracy ręcznej, przez co wskaźniki przestają się zgadzać. Nadal nie znalazłem idealnego rozwiązania.

Ben Aston:

Porozmawiajmy o artykule, który napisałeś o dokumentach inicjujących projekt, czyli dokumentach DIP. Jak wspomniałem we wstępie, projekty kończą się niepowodzeniem i często dzieje się tak dlatego, że nie rozpoczynamy ich właściwie. Zakładamy, że zespół coś wie, albo przekazujemy mu wiele dokumentów i mówimy: „Wejdźcie na wspólny dysk i przeczytajcie materiały. Wszystko tam jest”. Zakładamy, że zespół zapozna się z informacjami i nadrobi zaległości, a kiedy projekt spektakularnie się nie udaje, nie wiemy dlaczego. W rzeczywistości członkowie zespołu nie rozumieją projektu.

Porozmawiajmy o tym, jak możemy robić to lepiej, pisać lepsze karty projektu i tworzyć dokument inicjujący projekt. Zacznijmy od podstaw. Opowiedz nam o swoim procesie rozpoczynania projektów i wyjaśnij, gdzie w tym procesie znajduje się dokument inicjujący projekt lub karta projektu. Kiedy go tworzysz i co robisz, aby dojść do momentu, w którym można go napisać?

Maik Stettner:

Załóżmy, że masz nowego klienta. Wszyscy jesteście podekscytowani, ponieważ podpisano główną umowę. Jest to prawdopodobnie ogólna umowa ramowa określająca, że twoja firma i druga firma rozpoczynają współpracę. Kolejnym krokiem jest dla mnie ustalenie, jak przełożyć to na bardziej konkretne działania i warunki.

Zwykle na myśl przychodzi opis zakresu prac. Problem polega na tym, że na tak wczesnym etapie wszystko jest bardzo ogólne i stanowi jedynie przybliżenie tego, co ostatecznie będziecie robić. Dokument inicjujący projekt, a także spotkania rozpoczynające projekt, są dobrymi narzędziami do poznania klienta i sprawdzenia, czy istnieją inne czynniki, których nie uwzględniono w początkowym opisie zakresu prac.

Zwykle po przygotowaniu pierwszej wersji opisu zakresu prac, a często jest to jeszcze wersja robocza, zespół w agencji odbywa wewnętrzne spotkanie rozpoczynające projekt, aby wszyscy wiedzieli, co robimy. Następnie odbywa się spotkanie zewnętrzne z klientem, na bardziej ogólnym poziomie: przedstawiamy, co będziemy robić, kto jest w zespole, jak współpracujemy oraz jaki zakres został zdefiniowany.

Dokument inicjujący projekt lub karta projektu to dla mnie kolejny krok w kierunku większej konkretności. Na tym wczesnym etapie trzeba jednak traktować go jako dokument, który będzie się zmieniał, ponieważ nie jest jeszcze w pełni jasne, dokąd dokładnie zmierzamy. Jest to jednak bardzo dobre narzędzie do przedstawienia kontekstu biznesowego i zapewnienia, że podstawowe parametry projektu są jasne nie tylko dla klienta, ale także dla zespołu wewnętrznego.

Ben Aston:

Czyli najpierw powstaje opis zakresu prac albo jakiś rodzaj umowy między tobą a klientem. To punkt, w którym ustalono fundamenty zakresu prac i umowy ramowej, a dokument inicjujący projekt doprecyzowuje kilka kwestii i współgra z opisem zakresu prac.

W artykule wymieniasz elementy, które powinien zawierać dokument: kontekst, szczegółowe parametry projektu, strukturę podziału prac, osoby zaangażowane w projekt oraz zarządzanie ryzykiem. Porozmawiajmy najpierw o kontekście. Jak przedstawić zespołowi kontekst bez wprowadzania chaosu i przeciążania go informacjami? Jak rozróżnić to, co jest szumem, od tego, co będzie naprawdę pomocne? Jakie kluczowe elementy powinny znaleźć się w opisie kontekstu?

Maik Stettner:

Chodzi przede wszystkim o to, dlaczego klient realizuje projekt i jakie problemy należy rozwiązać na wysokim poziomie. Czy istnieją przyczyny biznesowe? Czy klient chce zwiększyć sprzedaż albo edukować odbiorców? Czy projekt obejmuje zmianę marki? Kluczowe pytanie brzmi: jak definiujemy sukces? Skąd będziemy wiedzieć, że projekt zakończył się powodzeniem?

Może to być coś tak prostego jak lepsze rozmowy sprzedażowe albo, w przypadku strony samoobsługowej, przeniesienie treści do systemu zarządzania treścią. Ważne jest przygotowanie zespołu i upewnienie się, że wie, do czego dąży. Nawet jeśli szczegółowe kroki nie zostały jeszcze opisane, pomaga to nadać ramy całemu działaniu.

Jeśli na przykład realizujesz projekt zmiany marki, którego celem jest repozycjonowanie firmy, a na końcu ktoś pyta: „Dlaczego moja sprzedaż nie wzrosła?”, możesz odpowiedzieć: „To nie było celem projektu ani jego kontekstem. Być może projekt miał na to pozytywny wpływ, ale nie był to jego główny obszar zainteresowania”.

Dobrze jest zachować zapis tego, co początkowo omówiono, i uzgodnić z klientem ogólny cel projektu.

Ben Aston:

Myślę, że to bardzo pomocne. Kontekst projektu jest niezwykle ważny, chyba że chodzi o typowe prace utrzymaniowe, gdzie nie trzeba znać szerszej strategii. Jeśli jednak tworzymy coś nowego, zrozumienie, dlaczego klient realizuje projekt, jaki problem rozwiązujemy, jakie są cele biznesowe i jak wygląda sukces, ma kluczowe znaczenie. Tło pomaga zespołowi kształtować rozwiązanie. Porozmawiajmy o parametrach projektu. W jednym sensie określamy, jak projekt wpisuje się w szerszy obraz strategicznych działań klienta. Jakie parametry określasz w samej karcie projektu? W jaki sposób dobrze jest ograniczać zespół?

Maik Stettner:

Nie chcesz ograniczać ekspertów, ale jeśli dasz im całkowitą swobodę, mogą pracować nad zupełnie innym projektem niż ten, który sobie wyobrażałeś. Dlatego ważne jest określenie ram, podstawowych ograniczeń oraz takich elementów jak budżet, harmonogram i ogólny plan. Najlepiej, jeśli oszacowano je wspólnie z częścią zespołu, więc nie powinny być dla niego zaskoczeniem. Zespół powinien wiedzieć, że klient ma określony budżet.

Warto omówić te kwestie. Zespół powinien rozumieć, że nie chodzi o ograniczenie, lecz o uzgodnienie tego, co zostanie dostarczone klientowi za określony budżet. Jeśli coś się zmieni, a ktoś stwierdzi: „Potrzebuję więcej czasu”, zadaniem zespołu jest ustalenie, jak mimo to zrealizować projekt. Trzeba prowadzić taką rozmowę na wysokim poziomie, nie sprawiać wrażenia, że utrudniasz zespołowi życie, lecz umożliwiać mu wykonanie pracy. Zespół powinien wiedzieć, że może liczyć na twoje wsparcie w przypadku zwiększenia budżetu, ryzyka lub zmian harmonogramu.

Ostatecznie zespół musi mieć pewność, że projekt zostanie dostarczony, i powinien być podekscytowany jego rozpoczęciem — tak samo jak klient.

Ben Aston:

Wspomniałeś o innych elementach, które warto uwzględnić. Nie będziemy zdradzać całego artykułu, ale chciałbym porozmawiać o włączeniu do dokumentu inicjującego projektu lub karty projektu podziału projektu, struktury podziału prac i wstępnego planu zasobów. Na początku projektu wiele rzeczy jest nieokreślonych. Jak stworzyć wstępny plan, zanim projekt się rozpocznie i zanim wiadomo, jak dokładnie będzie przebiegał?

Maik Stettner:

Szczerze mówiąc, na tym etapie jest to prawdopodobnie najlepsze przybliżenie. Opierasz się na opisie zakresu prac, istniejących informacjach albo szacunkach przygotowanych przez zespół. Wiele kwestii pozostaje niejasnych: czy klient szybko odpowiada, ile rund poprawek będzie potrzebnych i czy zostały one wystarczająco dobrze określone. Plan może nie zostać zrealizowany dokładnie w tej postaci.

Jednak nawet przybliżony plan pomaga agencji i innym zespołom projektowym zabezpieczyć właściwe zasoby oraz utrzymać stabilność zespołu. Warto przygotować nawet ambitny plan początkowy, który będzie jeszcze wymagał akceptacji klienta. Klient może po pierwszym lub drugim spotkaniu powiedzieć: „Potrzebujemy więcej czasu, to nierealistyczne”. Mimo to plan pomaga uporządkować działania i zrozumieć szczegóły, z którymi zespół będzie musiał się zmierzyć.

Może się okazać, że potrzebujesz projektanta, o którym wcześniej nie pomyślałeś. Jeśli wcześnie rozpoczniesz rozmowę na temat takich kwestii, jako kierownik projektu lepiej rozumiesz, czego wymaga dostarczenie projektu. Łatwiej zadajesz właściwe pytania i odpowiednio kierujesz klientem. Nawet przybliżony plan jest lepszy niż brak planu, ponieważ ludzie mogą o nim dyskutować, a z czasem stanie się bardziej szczegółowy i lepiej odzwierciedli rzeczywistość.

Ben Aston:

To pokazuje, że posiadanie jakiegokolwiek planu jest lepsze niż jego brak, ponieważ plan zawsze można rozwijać. Kiedy zaczynasz projekt i spotykasz się z zespołem, a nie ma żadnego rzeczywistego planu realizacji, nikt nie przeanalizował zależności ani roli klienta, projekt zaczyna się bez odpowiedniego impulsu. Jeśli przedstawisz zespołowi plan, będzie miał coś, do czego może się odnieść i powiedzieć: „Maik, zwariowałeś. Jak mamy to zrobić?”. To przynajmniej punkt wyjścia do dyskusji, a nie pusta kartka. Nawet błędny plan jest lepszy niż jego brak.

Rozmawialiśmy o karcie projektu i dokumencie inicjującym projekt, który brzmi jak bardzo poważny dokument. Nie musi jednak przyjmować formy obszernego, formalnego dokumentu. Zasadniczo przedstawiamy kontekst, parametry i plan. W jakich innych formach może występować karta projektu i jak widzisz jej rolę w całym cyklu życia projektu?

Maik Stettner:

Przygotowany przeze mnie poradnik jest przykładem elementów, które można uwzględnić. Istnieje pewien minimalny zakres informacji, który powinien znaleźć się w dokumencie inicjującym projekt lub karcie projektu, ale można to zorganizować na wiele sposobów. Możesz na przykład połączyć informacje dotyczące zarządzania ryzykiem z innym dokumentem albo wykorzystać macierz RACI, która będzie powiązana z raportami statusowymi.

Nie zawsze trzeba nadawać temu bardzo formalną formę. Najważniejsze jest, aby wszyscy się z tym zgadzali. Dokument może być opublikowany w SharePoint, Basecampie lub innym miejscu, może być aktualizowany i omawiany. Jeśli w pewnym momencie okaże się, że podczas definiowania zakresu pominięto aspekt sprzedażowy, należy go uwzględnić i zaktualizować dokument. Oczywiście może to mieć poważne konsekwencje dla zakresu.

Podsumowując, wystarczy dokument, nawet sformalizowana wiadomość e-mail — coś zapisanego, z czym ludzie mogą się zgodzić i co zostało przez nich zaakceptowane. Nie musi być podpisany i opieczętowany przez wszystkie strony, ale minimalnie musi zostać uznany za obowiązujący. Wszyscy powinni się z nim zgadzać, ponieważ określa to, co zostanie dostarczone i na podstawie czego będzie prowadzona praca.

Ben Aston:

Dobra wiadomość dla osób, które po wysłuchaniu tego odcinka zastanawiają się, od czego zacząć: Maik przygotował bardzo dobry szablon, który można wykorzystać jako kartę projektu lub dokument inicjujący projekt. Zajrzyj do artykułu i pobierz go. Maik, dziękuję za dzisiejszą rozmowę. Wspaniale było mieć cię z nami.

Maik Stettner:

Dziękuję za zaproszenie.

Ben Aston:

Cała przyjemność po mojej stronie. Jako jeden z naszych ekspertów DPM Maik pojawi się również w naszym nadchodzącym kursie rozpoczynającym się we wrześniu, zatytułowanym Mistrzowskie zarządzanie projektami cyfrowymi. Jeśli nie wiesz, o czym mówię, ale potrzebujesz szkolenia z zarządzania projektami, sprawdź ten kurs. To siedmiotygodniowy intensywny program obejmujący interaktywne lekcje wideo, cotygodniowe zadania, dyskusje grupowe i możliwość udziału w sesjach coachingowych. Wejdź na stronę digitalprojectmanagerschool.com i zapisz się, zanim zabraknie miejsc.

Jeśli chcesz dołączyć do rozmowy o dokumentach inicjujących projekt lub kartach projektu, przejdź do sekcji zasobów na stronie digitalprojectmanager.com, a następnie dołącz do naszego zespołu Slack, gdzie znajdziesz wiele interesujących dyskusji. Pamiętaj również, aby skomentować artykuł i udostępnić go innym. Do usłyszenia następnym razem. Dziękuję za słuchanie.