Dlaczego inauguracje projektów zawodzą wobec osób, które dołączają później
Mit inauguracji: Inauguracje projektów zapewniają spójność na początku, ale z czasem nieuchronnie pojawiają się zmiany.
Własność ma znaczenie: Gdy osoby dołączające w trakcie projektu nie mają poczucia odpowiedzialności za jego realizację, ucierpią tempo projektu, morale i jego wpływ.
Wyzwanie związane z dokumentacją: Tradycyjna dokumentacja nie sprawdza się w projektach realizowanych w szybkim tempie; niezbędne są lekkie i elastyczne formaty.
AI i neuroróżnorodność: Narzędzia AI mogą ułatwiać wdrażanie, zapewniając dostępne informacje o projekcie, ale wymagają dokładnych danych.
Kultura przynależności: Budowanie poczucia przynależności ma kluczowe znaczenie dla sprawnej integracji zespołu i powodzenia projektu.
Dlaczego rozpoczęcia projektów są świetne… ale mają wady
Uwielbiam świetne spotkania rozpoczynające projekt. To okazja, by wzbudzić entuzjazm, nabrać rozpędu i zapewnić zgodność wszystkim właściwym osobom obecnym w pokoju.
Tyle że… rozpoczęcia projektów to kompletny mit.
Przynajmniej ta ich wersja.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Wersja, w której gromadzimy wszystkich znanych interesariuszy, uzgadniamy Gwiazdę Północną, wykuwamy nasze podejście w kamieniu, a następnie wspólnie ruszamy z założeniem, że energia kinetyczna, którą wytworzyliśmy tego dnia, sama z siebie poniesie projekt od początku do końca.
Rzeczywistość jest taka, że zmiana jest nieunikniona, a podejście większości zespołów do rozpoczęć projektów jest w rzeczywistości wadliwe.
A to zacznie mieć ogromne znaczenie w gospodarce pracowników cząstkowych wspieranych przez sztuczną inteligencję, w którą właśnie wchodzimy.
Dlaczego dobre rozpoczęcie nie gwarantuje dobrego projektu
Kiedyś uważałem, że moja umiejętność prowadzenia świetnych spotkań rozpoczynających projekt jest moją nieuczciwą przewagą jako kierownika projektu. Gdy rozpoczynałem swoje projekty, zespoły ruszały z bram z jasnością i rozpędem zamiast z dezorientacją i kolejnymi pytaniami bez odpowiedzi.
W rzeczywistości ludzie podchodzili do mnie po spotkaniu rozpoczynającym projekt i prosili o pożyczenie mojego programu spotkania lub prezentacji, aby mogli wykorzystać je w swoich projektach. Był to dla mnie powód do dumy.
Ale potem wydarzyło się coś, co całkowicie zmieniło moje myślenie o rozpoczęciach projektów.
W jednym z moich projektów kluczowych członków mojego zespołu nagle zabrano i przydzielono do innych projektów — bez czasu na właściwe przekazanie wiedzy. Utalentowane osoby, które dołączyły, również były bardzo kompetentne, ale miały poczucie, że zaczynają z gorszej pozycji, żyjąc w cieniu tego, co już się wydarzyło. Każdą rozmowę opatrywały zastrzeżeniem: „ale nie było mnie tutaj, kiedy projekt się rozpoczął” albo „dopiero się z tym zapoznaję, nie pozwól, żeby moje pomysły pokrzyżowały wasze plany”.
W przypadku nowych członków zespołu nie chodziło o to, że nie mieli informacji, uprawnień czy nawet pomysłów. Chodziło o to, że nie czuli, iż mają poczucie własności.
A bez tego poczucia własności wiatr wypadał z żagli. Misja nie była ich własną misją. Czuli się jak nauczyciele na zastępstwie, którzy utknęli z odpowiedzialnością za wszystko — ofiary okoliczności, mające niewiele do powiedzenia i niewielką kontrolę.
Niestety, jeszcze wtedy nie zdawałem sobie z tego sprawy.
Problem z przekazywaniem wiedzy
W tamtym czasie rozwiązanie wydawało się proste: po prostu wdrożyć nowe osoby. Przekazać wiedzę do ich głów. Prawda?
W końcu mamy mnóstwo briefów, opisów zakresu i dokumentów wymagań — nie wspominając o prezentacji rozpoczynającej projekt i wynikach ćwiczeń dotyczących wizji.
Ale nawet gdy wszystkie dokumenty projektu są uporządkowane i zorganizowane, doświadczenie nowego członka zespołu, który próbuje przyswoić górę luźno uporządkowanych informacji, może przypominać prowadzenie audytu śledczego z pistoletem przystawionym do głowy.
Oczywiście nowi członkowie zespołu mogą zadawać pytania, ale nie wiedzą, czego nie wiedzą. A przez większość czasu nie czują się jeszcze na tyle swobodnie, by zadawać „głupie” pytania, obawiając się, że usłyszą przeklętą odpowiedź: „to było w dokumentach, nie widziałeś tego?”
Tworzyło to cykl, w którym nowi członkowie dłużej pozostawali zagubieni — co tylko utrudniało sterowanie projektem.
Problem z higieną informacji
A do tego za każdym razem, gdy wdrażałem nowego członka zespołu do mojego projektu, odkrywałem, że wśród moich wspaniałych dokumentów drobne szczegóły — do licha, czasem nawet ważne szczegóły — nie były zgodne z aktualnym stanem projektu.
Od rozpoczęcia projektu podjęto setki tysięcy mikrodecyzji. Nie tych dużych, które wpisuje się do rejestru decyzji — lecz tych drobnych, które wymykają się aktualizacjom dokumentacji.
Zdarzało mi się wyjaśniać rozbieżności, rozwijać drobne niuanse i przekazywać nieformalne rozmowy między członkami zespołu, których nigdy nie pomyśleliśmy, by zapisać.
Problem z szybkością
Czy mogłem ograniczyć to wszystko, stosując „system mentora”, w którym nowa osoba byłaby łączona z kolegą pracującym przy projekcie? Uwierzcie mi, próbowałem. Ale to również się nie sprawdziło, ponieważ projekt nie mógł sobie pozwolić na to, by jeden z członków zespołu zajmował się wsparciem w niepełnym wymiarze.
Już wtedy pracowaliśmy na pełnych obrotach i nie mogliśmy sobie pozwolić na zwolnienie tempa. Terminy zbliżały się wielkimi krokami, presja rosła, widoczność projektu się zwiększała, a oczekiwano, że wraz z dodawaniem kolejnych osób zespół będzie pracował szybciej, a nie wolniej.
Dlatego zamiast zwolnić tempo, kontynuowałem dotychczasowe podejście: to, w którym osoby dołączające w trakcie projektu zostają uwięzione w sytuacji polegającej na wskakiwaniu do jadącego samochodu i wkładaniu ręki w ogień.
Problem z poczuciem przynależności
Jednak gdy gorączkowo ciskałem dokumentami i zaproszeniami na spotkania w stronę osób dołączających do projektu — a zespół bezmyślnie przekopywał zadania z rejestru prac — stało się dla mnie zupełnie jasne: nie chodziło o informacje. Chodziło o poczucie przynależności. A to stan emocjonalny, którego nie da się osiągnąć za pomocą samej dokumentacji.
Nie potrafiłem sprawić, by nowi członkowie zespołu czuli, że do niego należą, po prostu zapewniając ich o tym lub więcej do nich mówiąc. Żaden system opiekunów wdrożeniowych nie miał tego naprawić. Żadne spotkania w formule „zapytaj mnie o cokolwiek”, z ustaloną agendą, nie miały załagodzić sytuacji. Potrzebne były bezpieczne i alternatywne przestrzenie.
Ludzie odnajdują poczucie przynależności w różny sposób, zależnie od kontekstu: niektórzy chcą spędzić trochę czasu w ciszy, czytając dokumentację, zanim porozmawiają z zespołem; niektórzy chcą mieć opiekuna wdrożeniowego; niektórzy potrzebują bezpiecznej przestrzeni, w której mogą zadawać „głupie” pytania; a niektórzy po prostu chcą zrozumieć „dlaczego” stojące za misją oraz swoją rolę w jej realizacji.
Właśnie w budowanie tego powinienem był inwestować swój czas i energię: w ramy, które pozwalają członkom zespołu odnaleźć poczucie przynależności na własnych zasadach.
Ostatecznie zbyt wiele inwestowałem w ceremonię otwarcia projektu, a potem zostawiałem osoby dołączające do niego w trakcie, by radziły sobie same.
Ten cykl niewystarczającego wdrażania nie tylko frustruje poszczególne osoby — podważa całe projekty. Kiedy nowicjusze nie mogą szybko osiągnąć odpowiedniego poziomu, decyzje podejmuje się wolniej, liczba błędów rośnie, a morale zespołu spada.
A kiedy zmiana jest nieunikniona — gdy członkowie zespołu dołączają do projektu i odchodzą z niego w trakcie jego cyklu życia — takie podejście staje się nie do utrzymania.
W przypadku nowych członków zespołu nie chodziło o to, że nie mieli informacji, uprawnień czy nawet pomysłów. Chodziło o to, że nie czuli, iż mają poczucie odpowiedzialności za projekt.
Inny sposób myślenia o spotkaniach otwierających projekt: ciągłe wdrażanie
Jaka jest więc odpowiedź? Jeśli zbyt wiele inwestujemy w spotkania otwierające projekt, a zbyt mało w reagowanie na zmiany i wdrażanie osób dołączających w trakcie projektu, jak możemy to skorygować?
Miałem swoje hipotezy, ale doznałem też olśnienia dzięki słowom osoby, którą bardzo szanuję:
„Na każdym spotkaniu niemal zawsze na nowo przedstawiam główny punkt, ponieważ „gwiazda przewodnia” ciągle się przesuwa. Przypomina mi to sposób, w jaki ćwiczymy kung-fu… Istnieje centralny punkt, nad którego kontrolowaniem się skupiamy, a wszystko poza nim jest kontekstem pozwalającym wrócić do tej prawdy. To rozmowa, w której obie strony „zadają pytania” i otrzymują odpowiedzi w czasie rzeczywistym, wykorzystując wszystkie zmysły.”
Innymi słowy, zamiast polegać na wielkim entuzjazmie towarzyszącym spotkaniu otwierającemu projekt, możemy wykorzystywać każdą interakcję do wzmacniania tego, co w projekcie jest najważniejsze. Jest to wbudowane w sam akt współpracy, zamiast przyjmować formę wielkiej imprezy, przez którą łatwo poczuć się pominiętym, jeśli nie było się na niej obecnym.
Oto co od tamtej pory staram się robić w każdym projekcie:
1. Zasada lekkiej dokumentacji, którą łatwo aktualizować
Porzuciłem efektowne prezentacje otwierające projekt oraz dopracowane materiały projektowe (opisy, raporty statusu, agendy spotkań, rejestry RAID), a zamiast tego priorytetem jest dla mnie przechowywanie informacji w formacie łatwym do aktualizowania i czytelnym zarówno dla ludzi, jak i członków zespołu korzystających ze sztucznej inteligencji.
Następnie współpracuję z zespołami projektowymi, aby wyznaczyć osoby odpowiedzialne za aktualizowanie dokumentów — podobnie jak wyznaczamy osoby odpowiedzialne za ryzyka. Rozkłada to obciążenie i wzmacnia pozycję członków zespołu, którzy dbają o rzetelność dokumentacji.
Przykładowo, mamy proste i zwięzłe dokumenty w Notion lub Slite dotyczące ról i odpowiedzialności w zespole, opisu projektu oraz planów komunikacji projektowej. Nic nie jest zamknięte w arkuszach kalkulacyjnych ani plikach PDF.
2. Ciągłe wdrażanie jako zaakceptowany fakt
Wraz z dokumentacją od samego początku zarządzam oczekiwaniami zespołu, jasno komunikując, że zespoły, cele i inne elementy otoczenia projektu mogą zmienić się w każdej chwili, a my będziemy musieli się zmobilizować.
Innymi słowy, zamiast mieć nadzieję i modlić się, żeby zespoły i cele się nie zmieniły, załóżmy, że się zmienią.
Oznacza to, że jak najmniej informacji powinno pozostawać wyłącznie w ludzkich głowach lub być przypisanych do konkretnego momentu. Spotkania mają transkrypcje, notatki prelegentów są dostępne w formie pisemnej, większość rozmów projektowych odbywa się na publicznych kanałach, a decyzje są skrupulatnie rejestrowane.
Pomaga to zapewnić, że osoby, które nie uczestniczyły w pierwszym dniu projektu, nadal mają dostęp do informacji, jeśli ich potrzebują. Pomaga nam to również zmieniać kierunek niczym stado skowronków, gdy zmienią się cele lub okoliczności projektu.
3. AI jako źródło prawdy dla wszystkich typów neuroatypowości
Wraz z tym, moje zespoły i ja konfigurujemy chatboty AI lub możliwe do przeszukiwania bazy wiedzy projektowej tak wcześnie w projekcie, jak to możliwe.
W wielu przypadkach nie jest to tak zaawansowane, jak można by sobie wymarzyć w kontekście AI, ale daje nam coś naprawdę ważnego: tworzy stosunkowo prywatny, bezpieczny i mniej upolityczniony sposób, w jaki członkowie zespołu mogą korzystać z informacji projektowych — na własnych zasadach, w sposób odpowiadający ich preferencjom dotyczącym nauki.
Te chatboty są od samego początku zasilane ustrukturyzowanymi i nieustrukturyzowanymi danymi dotyczącymi projektu — briefami, SOW-ami, raportami o statusie, protokołami spotkań oraz niektórymi rozmowami zespołu. A ponieważ dokumentacja jest wystarczająco zwięzła, aby członkowie zespołu mogli ją na bieżąco aktualizować, sztucznej inteligencji stosunkowo łatwo jest śledzić, co zmieniło się w trakcie projektu — jakie decyzje podjęto, jaki budżet dodano, jakie problemy się pojawiły, jakie ryzyka się zmaterializowały, jakie eskalacje miały miejsce itd.
Następnie każdy członek zespołu mógłby w dowolnym momencie zadawać pytania chatbotowi, w sytuacji, w której nie musi martwić się, że wyjdzie na niewiedzącego, ani umawiać spotkania z osobą decyzyjną, która i tak ma już bardzo mało czasu.
Na przykład członek zespołu może zapytać:
- „W jaki sposób moje zadanie wspiera ogólny cel projektu?”
- „Kto czeka na to, aż dostarczę swoje rezultaty na czas?”
- „Gdzie powinienem zapisać ostateczne rezultaty i jakie są nasze zasady nazewnictwa plików?”
Może znać odpowiedzi na te pytania, ale potrzebować dodatkowego upewnienia się, gdy przeskakuje między projektami i innymi zadaniami.
Ostatecznie chatboty AI usprawniają proces uzyskiwania dostępu do informacji, zwiększając wydajność dzięki wyeliminowaniu potrzeby rozbudowanych szkoleń lub konsultacji z wieloma źródłami, a także poprawiają dostępność dzięki przyjaznemu dla użytkownika interfejsowi, do którego można uzyskać dostęp z dowolnego urządzenia z połączeniem internetowym przez całą dobę, 7 dni w tygodniu.
Ale jest pewien haczyk: wiadomo, że sztuczna inteligencja się myli.
A jeśli się pomyli, projekt może bardzo szybko zboczyć z właściwego toru. Ogólną konsekwencją byłby dodatkowy krok: spróbować zapytać chatbota, dokładnie przeanalizować odpowiedź, bo może być błędna, a następnie zaufać własnej intuicji i zdecydować, czy zastosować otrzymaną odpowiedź bez pytania kogokolwiek, czy też znaleźć osobę, którą można zapytać — innymi słowy, kiedy nie ufamy AI, wracamy do punktu wyjścia.
Dane muszą więc być wystarczająco uporządkowane, aby nie były sprzeczne. Następnie ludzie w zespole muszą rzeczywiście ufać, że są one dokładne (zakładając, że nie wprowadziliśmy do systemu dezinformacji).
Aby pomóc to zapewnić, naszym priorytetem jest osiągnięcie jak największej dokładności, przy czym kluczowi członkowie zespołu pełnią rolę rzeczników i arbitrów jakości, korzystając z kilku przypadków testowych i regularnie przeprowadzanych wyrywkowych kontroli.
4. Rytualne wzmacnianie celów
Aby połączyć to wszystko, staram się przenosić niektóre z moich ulubionych elementów tragicznie „jednorazowego” rozpoczęcia projektu i wplatać je w codzienną pracę. Chodzi o takie rzeczy jak przypominanie o wizji produktu lub BHAG i jej ciągłe kwestionowanie, aby misja była wystarczająco dobrze rozumiana i można było ją poddawać analizie, upewniając się, że wciąż budujemy właściwe rozwiązanie.
Na przykład na początku każdego spotkania zespołu staram się przypominać ludziom o oczekiwanych rezultatach projektu. Coś w rodzaju: "przypominam, że ten projekt pomoże osobom korzystającym z transportu publicznego, mającym różne możliwości, bezpieczniej i z mniejszą frustracją dotrzeć do celu".
A jeśli ten drogowskaz się zmienił, staram się również powtarzać to na każdym spotkaniu lub podczas każdej aktualizacji statusu: "Przypominam, że początkowo była to inicjatywa skierowana do osób z niepełnosprawnościami korzystających z transportu publicznego, ale teraz jest to szansa na poprawę doświadczeń wszystkich klientów w wielu sieciach transportowych".
Wykorzystuję również swoją rolę generalisty do zadawania pytań, które kierują decyzje w stronę naszego celu. Na przykład, jeśli zespół próbuje wybrać między dwoma podejściami, pytam: "Które z nich pomoże nam usunąć najwięcej przeszkód z doświadczeń klienta?"
W przypadku takich kwestii jak wartości zespołu i sposoby pracy kończę spotkania przypomnieniem w tym zakresie: "Nie zapominajcie, aby ważne informacje przekazywać na wspólnym kanale, jeśli mogą one pomóc innym w wykonywaniu ich pracy".
Nie tylko sprawia to, że osoby dołączające do projektu w jego trakcie czują się mniej tak, jakby coś ważnego ominęło je na początku, lecz także pomaga nieustannie wzmacniać misję wśród wszystkich interesariuszy.
5. Kultura przynależności
Ale przede wszystkim staram się zmienić swoje nastawienie z „przekazywania wiedzy” na „przekazywanie odpowiedzialności” poprzez nadawanie priorytetu sposobom, które pomagają nowym członkom zespołu lub interesariuszom poczuć, że „należą” do projektu i mogą w pełni zaangażować w niego siebie.
Moim zdaniem nie ma jednego, niezawodnego sposobu, aby to osiągnąć, ale głęboko wierzę, że rozwiązaniem nie jest zasypywanie ludzi jeszcze większą ilością informacji. My, ludzie, musimy wykorzystać nasze człowieczeństwo, aby radzić sobie z kwestiami, które są zdecydowanie ludzkie — emocjami, ego, wspólnotą i poczuciem celu.
Kiedy ludzie nie czują, że coś do nich należy, rzadziej zabierają głos, gdy coś wydaje się nie w porządku, lub kwestionują decyzję, która mogłaby skierować projekt na niewłaściwe tory.
Dlaczego ma to teraz większe znaczenie
Dziś widzę, że problem wdrażania w trakcie projektu staje się coraz większy. Członkowie mojej społeczności prowadzą projekty, w których specjaliści pracujący w niepełnym wymiarze, freelancerzy, a nawet FTE są płynnie przenoszeni między projektami, aby utrzymać ich wykorzystanie.
Jednocześnie narzędzia AI tworzą wśród interesariuszy projektów płynne oczekiwania: projekty mają posuwać się szybciej, lepiej radzić sobie ze zmianami i dostarczać większą wartość dzięki wykorzystywaniu wniosków z danych, automatyzacji oraz podejmowaniu decyzji przez agentów.
Innymi słowy, zespoły są bardziej zmienne, a tempo przyspiesza. Oznacza to, że luka w poczuciu przynależności pogłębia się, gdy wszystko porusza się szybciej i częściej się zmienia.
I tu pojawia się prawdziwe ryzyko: nie chcemy po prostu szybciej zbudować niewłaściwej rzeczy.
Kiedy ludzie nie czują, że coś do nich należy, rzadziej zabierają głos, gdy coś wydaje się nie w porządku, lub kwestionują decyzję, która mogłaby skierować projekt na niewłaściwe tory.
Dlatego ciągłe wdrażanie nie jest już opcjonalne. Nie jest miłym dodatkiem ani umiejętnością miękką. To imperatyw biznesowy. Jeśli chcemy, aby zespoły potrafiły się dostosowywać i dostarczać rzeczywistą wartość w tym szybszym i bardziej rozproszonym środowisku projektowym — potrzebujemy ludzi, którzy czują się zaangażowani w wizję, a nie tylko poinformowani o zadaniach.
Czy zatem spotkania rozpoczynające projekt są martwe?
Spotkania rozpoczynające projekt zdecydowanie nie są martwe. Nie dla mnie i nie dla wielu zespołów projektowych.
Osobiście je uwielbiam. Uważam, że spotkania rozpoczynające projekt to zgromadzenia, które mogą tworzyć więzi między ludźmi i zapewniać przestrzeń do dialogu w kluczowym momencie cyklu życia projektu. Uważam, że są bardzo ludzkie. Więc tak, nadal je organizuję — i będziecie musieli wyrwać ten zwyczaj z moich zimnych, martwych rąk.
To, co robię inaczej, polega jednak na tym, że nie pokładam wszystkich swoich nadziei i marzeń w spotkaniach rozpoczynających projekt. Nie inwestuję już tak wiele energii w to, by były bezbłędne, efektowne i nastawione na robienie wrażenia. Nie dążę do tego, by stały się ceremonią absolutnie najważniejszą, która sprawia, że osoby nieobecne na początku czują się jak obywatele drugiej kategorii. I zdecydowanie nie próbuję robić z nich czegoś, co zamyka nas w oczekiwaniu jednej, niezmiennej ścieżki.
Bo projekty nie są prostą linią. Są jak latawiec na wietrze — miotany na wszystkie strony i wymagający aktywnego sterowania bez względu na to, co się wydarzy. Zmiana jest nieunikniona. Dlatego właśnie na przygotowanie się do niej powinniśmy przeznaczyć naszą energię.
Co o tym sądzicie?
Ale chciałbym również usłyszeć wasze zdanie: czy spotkania rozpoczynające projekt są równie problematyczne, jak je przedstawiłem? Jak myślicie o wdrażaniu na swoich projektach — zwłaszcza gdy członkowie zespołu dołączają w trakcie?
