Ewolucja zarządzania projektami: Startupy kontra przedsiębiorstwa
Opublikowany: 2022-03-11Startupy grają w pokera, duże firmy grają w szachy.
Ten cytat Dona Dodge'a, rzecznika programistów w Google, ukazuje różnice między byciem kierownikiem projektu w startupie a przedsiębiorstwem.
Startupy grają w grę prawdopodobieństwa. Podobnie jak w przypadku pokerzystów, najlepsi stale wygrywają, ale czasami przegrywają z amatorami. W zarządzaniu projektami startupowymi potrzebujesz świetnej realizacji, ale prawda jest taka, że nawet najlepsi przedsiębiorcy mogą ponieść porażkę. Podobnie jak w przypadku szachów, system zarządzania projektami w przedsiębiorstwie musi być znacznie bardziej strategiczny, planować dwa kroki do przodu i podejmować mniejsze ryzyko.
To nie wszystko jest czarno-białe
Jedynym zastrzeżeniem, zanim zagłębimy się w ten temat, jest to, że istnieją różne rodzaje firm. Czy firmę zatrudniającą 100 pracowników można już nazwać startupem? A jeśli wzrośnie do 200 lub 300 pracowników? Czasami Uber wciąż jest nazywany w mediach startupem, jednak Uber ma teraz 12 000 pracowników. Inną różnicą jest to, że startup założony przez studentów bardzo różni się od tego, który założyli seryjni przedsiębiorcy z ponad 20-letnim doświadczeniem zawodowym, którzy być może wcześniej pracowali w przedsiębiorstwie i przynieśli stamtąd najlepsze praktyki do swoich startupów.
W związku z tym istnieje wiele przypadków, począwszy od kolokacji startupu z 5 osobami do międzynarodowej korporacji z biurami na całym świecie. Chociaż ten artykuł skupi się głównie na dwóch skrajnościach, podejmij to wszystko z przymrużeniem oka i zastanów się krytycznie, czy dania na wynos odnoszą się do Twojej konkretnej sytuacji.
Startupy a przedsiębiorstwa
Pozbywając się tego zastrzeżenia, spróbujmy zdefiniować dwie skrajności, aby przygotować grunt pod naszą dyskusję. Na potrzeby tego artykułu charakterystyką startupu są:
- Współlokowany zespół (~1-50 pracowników), w którym zazwyczaj znasz wszystkich swoich współpracowników z imienia i nazwiska.
- Role są luźno zdefiniowane.
- Współzałożyciele bardzo aktywnie podejmują większość decyzji.
- Firma traci pieniądze i nie ma już długiego pasa startowego - głównym problemem jest przetrwanie.
Na drugim końcu spektrum przedsiębiorstwo wyglądałoby tak:
- Wiele działów i lokalizacji.
- Znasz dobrze tylko swoich bezpośrednich współpracowników i współpracujesz z kilkoma osobami z innych działów.
- Każdy ma jasne obowiązki i hierarchie.
- Firma może być publiczna.
- Rentowność i krótkoterminowe przeżycie prawdopodobnie nie stanowią problemu.
Zarządzanie projektami startowymi
Kierownik Projektu ≈ Kierownik Produktu
Teoretycznie kierownicy projektów mają zasadniczo inne obowiązki niż menedżerowie produktu. Jednak w ustawieniu startupowym te dwie role zwykle się przeplatają. Jeśli jesteś kierownikiem projektu w startupie, prawdopodobnie przejmiesz o wiele więcej obowiązków poza tym, co robiłbyś tradycyjnie w przedsiębiorstwie.
Szanse dla Project Managerów w Startupach
Szybkie decyzje i duży wpływ
W zarządzaniu projektami startupowymi podejmowanie ważnych decyzji jest dość łatwe, ponieważ nie ma wielu zależności w zakresie procesów, innych zespołów, klientów itp. Coś tak ważnego jak zatrudnienie nowego współpracownika, zmiana strony głównej, dodanie nowych funkcji lub przedłużenie terminu może oznaczać jedno spotkanie lub rozmowę na Slack. Daje to kierownikowi projektu siłę i daje poczucie autonomii.
Startup to dobre miejsce do wypróbowania swoich pomysłów i rozwoju zawodowego. Możesz wypróbować nowe narzędzie do zarządzania projektami, o którym Twój znajomy powiedział Ci, że używa w swojej firmie. Co powiesz na przejście ze Scruma do Kanbana? Cokolwiek sprawia, że dostarczasz szybciej, odpowiada dyrektor generalny. Co sądzisz o wdrożeniu nowego chatbota, który umożliwia odpytywanie Google Analytics w języku naturalnym? Nie potrzebujesz do tego programisty, wyjaśnia podczas lunchu Twój CTO. W przedsiębiorstwie wszystkie te byłyby oddzielnymi, dużymi i długimi inicjatywami zarządzanymi przez dedykowanego kierownika projektu.
Rzeczy załatwiają się szybko
Cykl życia rozwoju w startupach jest znacznie krótszy niż w przedsiębiorstwach. Możesz mieć pomysł dzisiaj i mieć coś w produkcji w przyszłym tygodniu. Przestarzałego kodu jest niewiele, więc programiści nie narzekają, że baza kodu wymaga refaktoryzacji, dzięki czemu są w stanie szybko dostarczać wyniki. Dzięki temu możesz być w ciągłej pętli sprzężenia zwrotnego z klientami i być naprawdę zwinny.
Łatwy w adaptacji lub obracaniu
Ta sama szybkość dostarczania i brak zależności pozwala zespołowi startupowemu na szybką zmianę kursu. Znanym przykładem jest PayPal. W ciągu pierwszych 15 miesięcy od powstania rozwiązania „kryptograficznego dla telefonów” Paypal zmienił się 5 razy. Rynek płatności szybko się zmieniał, a PayPal był w stanie wyprzedzić eBaya, który rozwijał własne rozwiązanie płatnicze o nazwie Billpoint. Zwinność systemu PayPal pozwoliła mu lepiej kontaktować się z kupującymi i sprzedającymi w serwisie eBay, co ostatecznie doprowadziło do tego, że eBay przejął PayPal.
Procesy płynne
Zwykle nie ma wielu rygorystycznych procesów i procedur dotyczących tego, jak działają ludzie w startupie. Wiele z tego pozostawia się zdrowemu rozsądkowi i wewnętrznym negocjacjom. Jest to jeden z głównych powodów, dla których powyższe punkty faktycznie działają, tzn. możesz szybciej podejmować decyzje i nie potrzebujesz niezliczonych podpisów. Oczywiście jest to nieunikniony kompromis, który powoduje inne problemy, jak zobaczymy w dalszej części tego artykułu. Jednak dla startupu, który szuka dopasowania produktu do rynku i próbuje konkurować z lepiej finansowanymi i większymi konkurentami, jest to rozsądny kompromis.
Wyzwania dla Project Managerów w Startupach
Obowiązki nie są w pełni zdefiniowane
Płynny proces umożliwia szybkie i intuicyjne decyzje. To płynna żegluga, gdy wszystko idzie dobrze, jednak druga strona skutkuje błędami i chaotycznym otoczeniem. W podziale, proces jest zasadniczo listą kontrolną - jakie kroki należy podjąć, aby osiągnąć wynik. Procesy zwykle powstają w wyniku jakiejś awarii, kiedy koledzy zaczynają się wzajemnie obwiniać za nie dbanie o coś, a firma inicjuje tworzenie procesu usprawniającego podejmowanie decyzji w jasno określonych krokach, aby zmniejszyć ryzyko wystąpienia takich problemów w przyszły.
Na przykład nowa wersja spowodowała awarię witryny klienta. Wszyscy w firmie wiedzieli o nadchodzącym wydaniu, ale nikt nie poinformował klienta. Czy kierownik projektu lub kierownik ds. kluczowych klientów powinien kontaktować się z zespołem programistów klienta? Czy CTO powinien być bardziej proaktywny? Po gorącej dyskusji zaangażowane osoby zgadzają się, że następnym razem poszczególni pracownicy będą odpowiedzialni za określone działania przed zwolnieniem, aby upewnić się, że to się nie powtórzy.
Ten przykład to mikrokosmos tego, jak startup ewoluuje w korporację. Ponieważ złożoność startupu rośnie z dnia na dzień, takie decyzje są podejmowane, a niejasności usuwane są z codziennych operacji. Jednak zanim ten stan zostanie osiągnięty, zwykle popełnianych jest wiele bolesnych błędów.
Słaba siła przetargowa
Jako kierownik projektu w startupie częściej angażujesz się w negocjacje zewnętrzne. Współzałożyciele mogą zabierać Cię na późniejsze spotkania z klientami, aby reprezentować techniczną lub produktową stronę prezentacji. Podczas tego spotkania może pojawić się wiele pytań i nowych wymagań, a kierownik projektu musi zadbać o to, aby nie uzgodnić wyników zbyt wcześnie. Współzałożyciele mogą chcieć pozyskać potencjalnego klienta i zgodzić się na jego warunki nawet podczas spotkania, nie zdając sobie w pełni sprawy z kosztów nowych pozycji backlogu. Klient może wykorzystywać fakt, że Twój startup nie ma długiej historii, aby zobowiązać Cię do więcej, niż możesz rozsądnie dostarczyć.
Kierownik projektu musi być w stanie odepchnąć się i poprosić o więcej czasu na ocenę nowych wymagań z zespołem programistów. Gdy masz przynajmniej przybliżone szacunki zespołu, przedstaw je współzałożycielom i przedyskutuj, czy nadal ma sens zgadzanie się na nowe warunki umowy.
Skróty powodują problemy ze starszymi wersjami
Na starcie bardzo łatwo jest być w stałym trybie MVP. Jako kierownik projektu bardzo kuszące jest zmuszanie zespołu programistów do zgody na krótsze terminy i pójście na skróty w przypadku elementów mapy drogowej. Gdy współzałożyciele są stale na twoich plecach, wydaje się to prawie konieczne. Jednak, jak mówi popularne powiedzenie – z wielką mocą wiąże się wielka odpowiedzialność. Jeśli nadużyjesz tej mocy, w końcu Twój zespół zacznie mieć problemy ze starszymi wersjami. I to nie znaczy, że kiedyś w przyszłości - prawdopodobnie natkniesz się na nie, gdy będziesz nadal w trybie uruchamiania.
Załóżmy na przykład, że Twoja firma postanawia utworzyć stronę z listą produktów. Musi mieć wiele filtrów, aby zawęzić wyniki. Musi też mieć opcje sortowania na podstawie różnych atrybutów. Wstępne oszacowanie jest zbyt duże i próbujesz zawęzić wymagane filtry i opcje sortowania. W końcu okazuje się, że większość oszacowania to cały system - wyszukiwanie i zwracanie wyników. Pytasz, czy jest jakiś sposób na szybsze dostarczenie prostszej wersji. Jeden programista sugeruje skorzystanie z rozwiązania innej firmy z miesięczną subskrypcją. Inni programiści rozmawiają o problemach z zależnościami i obawach dotyczących dziedzictwa. Dla Ciebie brzmi to idealnie, ponieważ szybciej zdobywasz MVP, a później subskrypcja może zostać anulowana, jeśli zdecydujesz się na złomowanie projektu. Scrum master zgadza się na korzystanie z rozwiązania innej firmy tylko wtedy, gdy ma szansę na przepisanie kodu, jeśli projekt nie zostanie złomowany.
Rzeczywistość jest jednak taka, że ta umowa prawie nigdy nie jest spełniona, chyba że mistrz scrum faktycznie wprowadzi zadanie związane z długiem technicznym w późniejszym sprincie i będzie go bronić, gdy nadejdzie czas. Jeśli początkowa opinia dotycząca strony z wykazem jest pozytywna, naturalną reakcją kierownika projektu jest opracowanie dodatkowych funkcji, ponieważ MVP był tylko testem. 6 miesięcy później dochodzisz do punktu, w którym dodawanie nowych funkcji staje się bardzo kosztowne, ale refaktoryzacja jest jeszcze droższa, a wtedy są inne priorytety, które stają się ważniejsze i przysłaniają początkową intencję.
Fałszywe pozytywy
Fałszywie pozytywny wynik w przypadku zarządzania projektami IT miałby miejsce wtedy, gdy Twój zespół opracowuje MVP i przyjmujesz początkowe pozytywne opinie jako dowód dopasowania produktu do rynku. Może się to zdarzyć nawet na wcześniejszym etapie procesu, gdy interesariusz powie Ci: „Zaoferowałem nasze rozwiązanie największemu klientowi w naszej branży, a oni powiedzieli, że na pewno go od nas kupią”. Rozwijasz to, a potem tak naprawdę nie kupują tego od ciebie.
Fałszywe alarmy to duże wyzwanie, ale istnieje sposób na ich złagodzenie. Steve Cohn, założyciel Validately, sugeruje, aby zweryfikować zapotrzebowanie na swoje rozwiązanie. Istnieją trzy sygnały, które mogą ci pomóc:
- Czy Twoi klienci są gotowi wydać lub zainwestować pieniądze, zanim jeszcze dostarczysz pełne rozwiązanie? Uzyskanie umowy przed dostarczeniem rozwiązania jest prawdopodobnie najlepszą walidacją, jaką możesz uzyskać.
- Czy Twoi klienci chcą spędzić z Tobą czas na rozwijaniu rozwiązania? Czas to pieniądz, a każdy ma niekończące się zaległości w zadaniach. Im bardziej klient aktywnie angażuje się w określanie wymagań, angażując innych współpracowników w dyskusję, dokładnie testując MVP i dostarczając obszernych informacji zwrotnych, tym większe jest prawdopodobieństwo, że jesteś na właściwej ścieżce.
- Czy Twoi klienci chcą wykorzystać swoją reputację do promowania Ciebie? Niezależnie od tego, czy to w mediach społecznościowych, podczas profesjonalnego wydarzenia, czy w jakiejkolwiek innej formie, kiedy klient Cię promuje, użycza Ci swojej reputacji, która potwierdza jego szczere zainteresowanie.
Zarządzanie interesariuszami
Najważniejszymi interesariuszami project managera w startupie są zwykle współzałożyciele. Jak widzieliśmy w części o możliwościach, współzałożyciele mogą umożliwić szybkie podejmowanie decyzji w oparciu o zdrowy rozsądek. Problem polega jednak na tym, że wielu współzałożycieli dość często polega na swoim instynkcie w podejmowaniu decyzji. Dotyczy to zwłaszcza współzałożycieli, którzy pracowali w określonej branży jako profesjonaliści w tej dziedzinie i teraz zdecydowali się stworzyć rozwiązanie informatyczne, aby rozwiązać problem, z którym sami zmierzyli się w swojej pracy.
Dogłębna znajomość rynku jest niezwykle przydatna dla każdego startupu, jednak nie można na niej polegać wyłącznie podczas tworzenia mapy drogowej. Aspiracją większości startupów jest stworzenie rozwiązania, które będzie skalować się na arenie międzynarodowej. Nawet jeśli na tym samym rynku istnieje wiele firm, niekoniecznie będą one rozwiązywać swoje problemy w ten sam sposób. Współzałożyciel może mieć gruntowną wiedzę o tym, jak robiła rzeczy jego poprzednia firma, ale nie przekłada się to na wiedzę o tym, jak inne firmy, zwłaszcza w innych krajach, rozwiązywały te same wyzwania.

Współzałożyciele najczęściej trzymają się swoich przekonań i potrzebują niezależnego kierownika projektu, aby zrównoważyć ich poglądy. Zadaniem kierownika projektu jest edukowanie współzałożycieli o znaczeniu podejmowania decyzji w oparciu o dane i zwinnego rozwoju na wczesnych etapach odkrywania produktu.
Zarządzanie projektami w przedsiębiorstwie
Kierownik Projektu ≠ Kierownik Produktu
W miarę dojrzewania startupu i przekształcenia się w duże przedsiębiorstwo, role poszczególnych stanowisk stają się coraz bardziej określone, w miarę jak praca staje się bardziej konkretna. Nawet w przedsiębiorstwie zdarzają się przypadki, w których kierownicy projektów i kierownicy produktów nakładają się na siebie. Jednak kierownik projektu ma tendencję do skupiania się bardziej na aspektach operacyjnych projektu, podczas gdy kierownik produktu jest odpowiedzialny za realizację.
Biuro Zarządzania Projektami (PMO)
Wraz z rozwojem firmy rośnie ich portfolio projektów. Dołączają nowi kierownicy projektów, a wraz z nimi nowe narzędzia i metodologie zarządzania projektami. Początkowo sprawy stają się nieco chaotyczne i pojawia się potrzeba biura zarządzania projektami (PMO). PMO zajmuje się cyklem życia zarządzania projektami i może rozpowszechniać lub egzekwować najlepsze praktyki w całej firmie.
Jako kierownik projektu w przedsiębiorstwie będziesz musiał kontaktować się z PMO. Każdy PMO jest inny, ale z rzeczy, z którymi możesz się zmierzyć, są:
- Wypełnianie różnych formularzy w celu rozpoczęcia i zamknięcia projektu.
- Przesyłanie budżetów do przeglądu.
- Zapewnianie regularnych aktualizacji postępów.
- Uzyskiwanie podpisów dotyczących kamieni milowych lub różnych etapów procesu.
Dla kierownika projektu, który już dużo planuje i śledzi, wiele wymagań PMO może wydawać się niepotrzebną biurokracją, zwłaszcza jeśli zaczyna spowalniać projekt. Chociaż ta biurokracja może być źródłem frustracji, proaktywny kierownik projektu może zminimalizować koszty ogólne, a nawet wydobyć wartość projektu z PMO:
- Zaangażuj PMO na wczesnym etapie, aby ustalić wymagania dotyczące raportowania. Można je następnie dopasować do materiałów wyprodukowanych podczas realizacji projektu, aby zaoszczędzić czas.
- Bądź mistrzem procesu. Przekaż PMO informację zwrotną o tym, jak można zmienić procesy, aby ułatwić życie kierownikom projektów. Jednym z głównych celów PMO jest pomoc menedżerowi produktu w osiągnięciu efektywności.
- Skorzystaj z pomocy PMO, gdy w Twoim projekcie pojawią się problemy. PMO ma spojrzenie na wszystkie projekty w skali całej firmy i ma doświadczenie w radzeniu sobie z różnymi problemami lub zagrożeniami, które pojawiają się podczas realizacji projektu. Wykorzystaj ich wiedzę na swoją korzyść.
Możliwości dla kierowników projektów w przedsiębiorstwie
Wiarygodność
Stabilność i długoterminowe planowanie przedsiębiorstw świadczy o wiarygodności wobec klientów i partnerów. Ludzie, którzy chcą nawiązać kontakt z Twoją firmą, szukają dobrych wyników - abyście byli w stanie dotrzymać obietnic i mieć duże doświadczenie w swojej dziedzinie. To jedna z największych przewag, jakie przedsiębiorstwo ma nad startupami. Ułatwia znalezienie nowych klientów i partnerów.
To zaufanie umożliwia większą integrację z klientem. Jako dostawca technologii umożliwiasz swoim klientom, a oni z kolei mogą dostosować swoje własne plany do Twoich, aby móc dostarczać nowe funkcje tak szybko, jak to możliwe. Taka relacja byłaby bardzo trudna do osiągnięcia przez startup, ponieważ startupy są bardzo niestabilne i trudno im zaufać.
Łatwiejsze zebranie wymagań
Przedsiębiorstwo ma znacznie większą obecność na rynku niż startup. W miarę rozwoju firmy, a praca staje się coraz bardziej specyficzna, zatrudnianych jest coraz więcej wyspecjalizowanych profesjonalistów. Jednocześnie, aby podtrzymać wizję, do firmy dołącza coraz więcej doświadczonych menedżerów najwyższego szczebla. Wszyscy ci ludzie wnoszą ogromny wgląd w rynek, który jest bardzo łatwy dla kierownika projektu w celu uzyskania dostępu i wykorzystania w gromadzeniu wymagań użytkowników.
Może to być również wielką zaletą dla rozwoju osobistego PM. Mając do dyspozycji dużą liczbę kontaktów, możesz nawiązać z nimi kontakt, gdy chcesz wpłynąć na innych interesariuszy w przedsiębiorstwie lub upewnić się, że projektowi poświęca się wystarczająco dużo uwagi na wyższych szczeblach firmy.
Kolejną grupę współpracowników, którzy mogą pomóc w spełnieniu wymagań użytkowników, można znaleźć w zespołach sprzedaży, zarządzania kontem czy obsługi klienta. Osoby tam pracujące mają codzienny kontakt z klientami i mogą dostarczyć Ci wielu informacji zwrotnych na temat potrzeb i frustracji użytkowników. Jednak zawsze miej na uwadze kontekst, z którego pochodzi ta informacja zwrotna. Na przykład zespół obsługi klienta może mieć do czynienia z osobami, które korzystają z Twojego produktu, podczas gdy sprzedawcy i menedżerowie ds. klientów mogą mieć do czynienia z kierownikami najwyższego szczebla, którzy podejmują decyzje o zakupie, ale w rzeczywistości nie używają Twojego oprogramowania.
Zbuduj lub kup
Szansą niedostępną dla startupów jest rozwój poprzez fuzje i przejęcia (M&A). W 2018 r. odnotowano już rekordową liczbę transakcji fuzji i przejęć na całym świecie. Duża część tego trendu to mega-transakcje, takie jak niedawne przejęcie Time Warner przez AT&T za 85 miliardów dolarów. Jednak według badania przeprowadzonego przez Harvard Business Review część transakcji jest niewielka pod względem wycen i generuje lepsze zwroty. Istnieje wiele małych startupów z jednopunktowymi rozwiązaniami, a kierownicy projektów w przedsiębiorstwach powinni mieć na uwadze, że czasami warto wykupić je zamiast próbować kopiować ich rozwiązanie. Kierownik projektu może nie być decydentem w takim scenariuszu, ale może być tym, który przedstawi tę opcję.
Wyzwania dla kierowników projektów w przedsiębiorstwie
Zatwierdzenia trwają dłużej
Wraz z rozwojem firmy rośnie hierarchia raportowania. Powstaje wiele działów, procesów i procedur. Powstają wytyczne dotyczące marki. Należy wziąć pod uwagę ryzyka prawne, czasem pomijane w startupach. Wycena wspólnego komunikatu prasowego z nowym partnerem może zająć kilka tygodni, zanim zebranie wszystkich potrzebnych podpisów.
Oznacza to, że kierownik projektu musi planować z dużo większym wyprzedzeniem i być bardziej sumienny. Jednak zawsze zdarzają się doraźne i nieoczekiwane sytuacje, w których musisz uzyskać wszystkie zgody tak szybko, jak to możliwe. W takich sytuacjach dobre relacje z innymi działami będą bardzo cenne. Kierownik projektu, który jest w stanie pomóc innym w potrzebie, w zamian z większym prawdopodobieństwem otrzyma przysługi od kolegów.
Niezrozumienie
„Nic nie zakładaj” powinno być mottem kierownika projektu. Wraz ze wzrostem złożoności w firmie praca kierownika projektu staje się coraz trudniejsza pod względem utrzymania skutecznej komunikacji w zespole projektowym i poza nim. Przyjrzyjmy się przykładowemu scenariuszowi.
Twój zespół potrzebuje kilku nowych ikon dla nowych funkcji, nad którymi pracuje. Podczas lunchu niespodziewanie spotykasz szefową zespołu projektowego i opowiadasz jej o ikonach. Mówi, że obecnie pracują nad podobnymi ikonami i wkrótce będą gotowe. Następnego dnia podczas stand-upu przekazujesz informacje zespołowi i mówisz im, aby skontaktowali się z zespołem projektowym, kiedy będą potrzebować ikon. Wspomniane funkcje mają pojawić się za 4 tygodnie, więc wszyscy zakładają, że ikony będą w tym czasie gotowe. Deweloperzy umieszczają symbole zastępcze i dopiero podczas kontroli jakości ktoś zauważa, że zapomnieli je zastąpić. Starają się dotrzeć do zespołu projektowego, który w rzeczywistości odłożył stworzenie tych ikon z powodu innych pilnych zadań. Nikt z Twojego zespołu nie skontaktował się z nimi, a kierownik zespołu projektowego założył, że nie będziesz już potrzebować ikon. Wytyczne marki nie pozwalają na przejście do produkcji z losowymi ikonami, a Twój zespół zostaje tam z ukończonymi funkcjami, które nie mogą ich wdrożyć.
Praca kierownika projektu w przedsiębiorstwie jest pełna takich momentów, które sprzyjają nieporozumieniom. Istnieją dwie strategie, które możesz zastosować tutaj:
- Skorzystaj z retrospektywy, aby dowiedzieć się z zespołem, czy nowy proces może pomóc w uniknięciu takich błędów w przyszłości. Być może odpowiedzią w tym scenariuszu może być utrzymywanie listy wszystkich zależności od innych zespołów z cotygodniowym przeglądem i działaniami uzupełniającymi.
- Nadmierna komunikacja. Ogólnie rzecz biorąc, dobrą strategią dla kierownika projektu jest komunikowanie się więcej, niż myślisz, że jest to konieczne. Wyrobienie nawyku meldowania się z ludźmi, proszenia o szybkie aktualizacje w tych krótkich chwilach, czekając na windę lub idąc do samochodu. To dobry sposób, aby mniej rzeczy prześlizgnęło się przez szczeliny.
Poruszaj się powoli i niczego nie psuj
Im starsza baza kodu, tym trudniej jest opracować nowe funkcje. Kierownik projektu może zacząć zauważać, że mniejsze startupy szybciej wchodzą na rynek dzięki nowym innowacjom i przewyższają je.
Jednocześnie, odpierając wyzwania małych start-upów, przedsiębiorstwa muszą również uważać na konkurentów o podobnej wielkości. W miarę dojrzewania startupów rozwiązania jednopunktowe stają się pełnoprawnymi platformami, które mają różne funkcje i przypadki użycia. Problemem staje się zrównanie cech z innymi dużymi konkurentami.
Jako kierownik projektu w przedsiębiorstwie będziesz musiał podejmować decyzje, czy angażować się w innowacje i tworzyć nowe propozycje wartości dla swoich klientów, czy próbować osiągnąć parytet cech z konkurencją. Jednak w większości przypadków nie będziesz w stanie samodzielnie podejmować takich decyzji i będziesz musiał wywrzeć wpływ na wielu interesariuszy, aby podejmowali te decyzje za Ciebie. Może to być frustrujące, zwłaszcza jeśli ci interesariusze są mniej obeznani z technologiami cyfrowymi i nie są zaznajomieni z funkcjami, do stworzenia których próbujesz ich przekonać.
Wniosek
W tym artykule omówiliśmy, w jaki sposób mechanizmy leżące u podstaw startupu i przedsiębiorstwa stwarzają szanse i wyzwania dla kierownika projektu. W startupie kierownik projektu prawdopodobnie przejmie wiele funkcji kierownika produktu, ale w przedsiębiorstwie te dwie role są wyraźnie rozdzielone. Należy pamiętać, że każda firma jest wyjątkowa i nie wszystkie omawiane tematy będą miały zastosowanie do każdej sytuacji, więc zróżnicowane środowiska będą wymagały od kierownika projektu wykorzystania różnych cech i umiejętności zarządzania projektami.
Podsumowując, startup ma płynne procesy, a kierownik projektu jest w stanie podejmować szybkie decyzje i mieć duży wpływ na całą firmę. Cykle rozwoju są znacznie krótsze, co pozwala kierownikowi projektu zachować elastyczność i dostosować się do zmieniających się warunków rynkowych.
Kierownik projektu w startupie również stoi przed sporymi wyzwaniami. Nie do końca zdefiniowane obowiązki mogą prowadzić do wielu problemów w miarę rozwoju startupu. Klienci i współzałożyciele mogą naciskać na kierownika projektu, aby zaangażował się w więcej, niż zespół jest w stanie zapewnić. Następnie na planie można umieścić różne skróty, co prowadzi do problemów ze spuścizną w przyszłości. Współzałożyciele startupu bardzo aktywnie określają roadmapę. Ich przekonania mogą jednak prowadzić do fałszywych alarmów, a kierownik projektu musi być oparty na danych i sprawny, aby złagodzić te wyzwania.
Po stronie przedsiębiorstwa kierownik projektu może wykorzystać wiarygodność i historię firmy do nawiązania dobrych relacji roboczych z podmiotami zewnętrznymi. Łatwiej jest zebrać wymagania od doświadczonych menedżerów i współpracowników, którzy regularnie kontaktują się z klientami. Wreszcie, biuro zarządzania projektami, jakkolwiek ograniczające, może pomóc w łagodzeniu problemów i zarządzaniu ryzykiem, które pojawia się podczas realizacji projektu.
Wyzwania w zarządzaniu projektami w przedsiębiorstwie są nieuchronnie związane z wielkością firmy. Różne zatwierdzenia i podpisy oznaczają, że kierownik projektu musi bardzo starannie planować i angażować PMO, aby uniknąć spowolnienia realizacji projektu. Prawdopodobne jest wystąpienie nieporozumień, ponieważ zaangażowanych jest coraz więcej osób i działów, co należy złagodzić, wprowadzając odpowiednie procesy. Wreszcie cykle rozwoju stają się dłuższe, a kierownik projektu musi konkurować zarówno ze start-upami, jak i innymi przedsiębiorstwami na rynku.
To są podstawowe różnice między tymi dwoma środowiskami, w których pracują kierownicy projektów. Dzięki zrozumieniu tych wyzwań możemy lepiej przewidzieć, co możemy napotkać, przechodząc z jednego środowiska do drugiego.