Zarządzanie projektami to jeden z tych kierunków, gdzie praca magisterska może być naprawdę bliska praktyce – albo całkowicie od niej oderwana. Widzę to regularnie: studenci piszą 80 stron o tym, czym jest Scrum, zamiast zbadać, jak Scrum działa (albo nie działa) w konkretnej organizacji. Efekt? Praca, która nie wnosi nic nowego ani do nauki, ani do praktyki.
Dobra praca z PM to taka, w której masz jasne pytanie badawcze, dobrze dobraną metodologię i wyniki, które można skonfrontować z raportami branżowymi – PMI Pulse of the Profession, State of Agile Report (Digital.ai) czy CHAOS Report (Standish Group). Jeśli Twoja praca mogłaby być cytowana przez project managera szukającego uzasadnienia dla wdrożenia SAFe w firmie, jesteś na dobrej drodze.
Poniżej znajdziesz konkretny przewodnik: od wyboru tematu, przez teorie i metodologię, aż po strukturę i typowe pułapki. Bez ogólników.
Specyfika kierunku i typy prac
Prace magisterskie z zarządzania projektami dzielą się na kilka głównych typów. Pierwsza grupa to prace empiryczne oparte na studiach przypadku – badasz jedną organizację lub kilka firm, analizujesz ich procesy projektowe, zbierasz dane jakościowe i ilościowe. Druga to prace ankietowe, gdzie mierzysz np. postrzeganie efektywności metodyki wśród project managerów lub oceniasz dojrzałość procesową organizacji. Trzecia – prace analityczno-porównawcze – zestawiasz metodyki, standardy lub narzędzia bez własnych badań terenowych (rzadziej akceptowane jako wystarczające).
W Polsce promotorzy z kierunków zarządzania najczęściej oczekują pracy empirycznej z wyraźnym pytaniem badawczym i hipotezami. Samo opisanie PMBOK-a 7th edition to za mało – musisz coś zbadać, zmierzyć lub porównać. Jeśli Twój promotor mówi inaczej, masz szczęście albo wyjątek.
Wybór tematu
Temat powinien być na tyle wąski, żebyś mógł go realnie zbadać w 6-12 miesięcy, i na tyle szeroki, żebyś miał dostęp do literatury i danych. „Zarządzanie projektami IT” to za dużo. „Wpływ implementacji SAFe 6.0 na velocity zespołów scrumowych w polskich firmach software’owych – studium przypadku” – to jest temat.
Metodyki tradycyjne: PMBOK (PMI), PRINCE2, waterfall
Waterfall i klasyczne podejście kaskadowe mają mocną bazę literatury, ale dla pracy magisterskiej pisanej w 2026 roku sama analiza podejścia tradycyjnego bez porównania z podejściem zwinnym może wyglądać przestarzale. Ciekawsze tematy to: skuteczność CPM (Critical Path Method) w projektach budowlanych versus IT, analiza wskaźników SPI (Schedule Performance Index) i CPI (Cost Performance Index) z metodyki Earned Value Management (EVM), albo ocena stosowania PRINCE2 7 w administracji publicznej.
PMBOK 7th edition (2021) zmienił podejście z procesowego na pryncypialne – zamiast 49 procesów masz 12 zasad i 8 dziedzin wydajności. To samo w sobie może być tematem badania: jak organizacje certyfikowane PMP adaptują się do tej zmiany.
Metodyki zwinne: Scrum, Kanban, SAFe, LeSS, XP (Extreme Programming)
To jest gorący obszar. State of Agile Report 2023 (Digital.ai) pokazuje, że Scrum stosuje 81% organizacji używających agile, a SAFe to dominująca framework dla skalowania (37%). Tematy, które się bronią: porównanie velocity przed i po wdrożeniu Scrum, analiza skuteczności SAFe 6.0 w organizacjach powyżej 500 osób, różnice w efektywności Kanbana vs Scrum w projektach maintenance.
XP (Extreme Programming) jest rzadziej badane empirycznie w Polsce – jeśli masz dostęp do organizacji stosującej TDD, pair programming i continuous integration jako praktyki XP, masz niszę.
LeSS (Large-Scale Scrum) to alternatywa dla SAFe, mniej popularna, ale z silną bazą literaturową (Larman i Vodde). Porównanie SAFe vs LeSS w konkretnym kontekście organizacyjnym to temat z potencjałem.
Zarządzanie portfolio projektów i PMO (Project Management Office)
PMO jako temat pracy to dobry wybór, jeśli masz dostęp do dużej organizacji. Możesz badać: jakie role pełni PMO (dyrektywne, wspierające, kontrolne – zgodnie z PMI), jak mierzona jest jego efektywność, jaka jest korelacja między dojrzałością PMO a wskaźnikami sukcesu projektów. PMI Pulse of the Profession 2023 podaje, że organizacje z dojrzałym PMO realizują o 38% więcej projektów „w czasie i budżecie” niż pozostałe – możesz to zweryfikować empirycznie w polskich realiach.
Zarządzanie ryzykiem projektowym
Rejestr ryzyka, macierz prawdopodobieństwo/wpływ, metoda Monte Carlo dla harmonogramu – to narzędzia, które możesz badać empirycznie. Ciekawy temat: w jakim stopniu project managerzy w Polsce rzeczywiście stosują formalne metody zarządzania ryzykiem vs podejście intuicyjne. Hipoteza: duże rozbieżności między deklarowanym a rzeczywistym stosowaniem metod – i to jest coś, co możesz sprawdzić wywiadami i obserwacją dokumentacji.
Transformacja agile w organizacjach
Transformacja agile (agile transformation) to obszar szczególnie bogaty w możliwości badawcze. Pytania: jakie bariery pojawiają się przy skalowaniu Scruma? Jak zmienia się rola project managera po przejściu na SAFe? Czy po 2 latach od transformacji organizacje mierzą ROI? State of Agile Report wskazuje, że 65% organizacji ma trudności z utrzymaniem kultury agile po początkowym wdrożeniu – masz gotową bazę porównawczą dla własnych badań.
Teorie i modele
Dobra praca magisterska to nie tylko opis praktyki – to osadzenie obserwacji w teorii. Poniżej teorie, które reelnie pasują do badań z PM.
Theory of Constraints (Goldratt) w zarządzaniu projektami
Teoria ograniczeń Goldratta (TOC, 1984) mówi, że w każdym systemie jest jedno wąskie gardło ograniczające przepustowość całości. W zarządzaniu projektami przekłada się na Critical Chain Project Management (CCPM) – alternatywę dla CPM skupioną na zarządzaniu buforami zamiast terminami zadań. Możesz badać: czy organizacje stosujące CCPM rzeczywiście lepiej radzą sobie z opóźnieniami niż te stosujące klasyczny Gantt? Masz konkretną teorię, konkretne miary, konkretne hipotezy.
Krzywa uczenia (Wright – learning curve, 80% rule)
T.P. Wright opisał w 1936 roku, że każde podwojenie skumulowanej produkcji wiąże się ze stałym spadkiem czasu jednostkowego (klasyczna wersja: 80%, czyli przy podwojeniu produkcji czas jednostkowy spada do 80% poprzedniej wartości). W PM przekłada się to na szacowanie pracy w kolejnych sprintach: czy velocity zespołu Scrum rośnie zgodnie z krzywą uczenia po pierwszych 10 sprintach? To pytanie badawcze, które możesz zmierzyć na danych z Jiry.
Sukces projektu: trojkat projektowy (zakres-czas-koszt), model Atkinson (Iron Triangle + quality + stakeholders)
Klasyczny „Iron Triangle” (zakres-czas-koszt) to za mało do mierzenia sukcesu projektu – to wiemy od lat 90. Atkinson (1999) zaproponował rozszerzenie o jakość i satysfakcję interesariuszy. Shenhar i Dvir (2007) dodali efektywność projektu, wpływ na klienta, korzyści biznesowe i przygotowanie na przyszłość. Twoja praca może weryfikować: którym wymiarem sukcesu PM-owie w Polsce zarządzają najsłabiej? Ankieta + analiza dokumentacji projektowej daje Ci dane do odpowiedzi.
Teoria chaosu w zarządzaniu (Snowden – Cynefin framework: simple/complicated/complex/chaotic)
Dave Snowden stworzył Cynefin framework (1999, rozwinięty z IBM) jako narzędzie sensemaking: rozróżnia sytuacje proste (clear), skomplikowane (complicated), złożone (complex) i chaotyczne (chaotic). W PM pytanie brzmi: czy metodyka jest dobrana do domeny? Waterfall pasuje do skomplikowanego (analitycy mogą dojść do najlepszej praktyki), Scrum do złożonego (wyłaniające się rozwiązania). Możesz badać: czy project managerzy świadomie diagnozują domenę przed wyborem metodyki, czy dobierają ją z przyzwyczajenia lub nacisku organizacyjnego.
Model dojrzalosci projektowej: CMMI, OPM3, P3M3
CMMI (Capability Maturity Model Integration) ma 5 poziomów od initial do optimizing. OPM3 (Organizational Project Management Maturity Model, PMI) i P3M3 (Portfolio, Programme and Project Management Maturity Model, Axelos) dają ustrukturyzowane narzędzia oceny. Badanie dojrzałości projektowej polskich organizacji IT – z podziałem na branże lub wielkość firmy – to temat, który można zrealizować nawet bez dostępu do wewnętrznej dokumentacji (wywiady eksperckie + samoocena respondentów).
Wyślij fragment tekstu, bezpłatną wycenę otrzymasz w 24 h. Poprawki bez limitu w cenie usługi.
Metodologia badan w zarzadzaniu projektami
To jest serce Twojej pracy. Zła metodologia przekreśla dobry temat.
Studium przypadku (Yin 2009 – protokol case study, triangulacja zrodel)
Robert K. Yin (2009, „Case Study Research: Design and Methods”) to standard dla projektowania case study w naukach o zarządzaniu. Protokół Yina obejmuje: pytania badawcze, propozycje (propositions), jednostkę analizy, logikę łączenia danych z propozycjami i kryteria interpretacji wyników. Triangulacja źródeł to minimum: wywiady + dokumentacja projektowa + obserwacja (lub artefakty jak burndown charty, rejestry ryzyka).
W praktyce: jeden case study (single-case design) jest akceptowalny, jeśli przypadek jest wyjątkowy lub typowy w rozumieniu Yina. Dwa-trzy przypadki (multiple-case design) dają możliwość replikacji logicznej i mocniejsze wnioski. Unikaj więcej niż 4-5 przypadków – to już quasi-badanie ilościowe, a nie prawdziwe case study.
Wywiad ekspercki z project managerami (IDI): STAR, pytania behawioralne
IDI (Individual In-Depth Interview) z project managerami to naturalna metoda zbierania danych jakościowych. Technika STAR (Situation-Task-Action-Result) pozwala wyciągnąć konkretne przykłady z praktyki zamiast ogólnych deklaracji. Pytanie ogólne: „Czy stosujesz zarządzanie ryzykiem?” da Ci odpowiedź „tak” od 95% respondentów. Pytanie STAR: „Opisz projekt, w którym nieuwzględnione ryzyko spowodowało opóźnienie – co się wydarzyło i jak zareagowałeś?” da Ci realną wiedzę.
Rekrutacja: LinkedIn (filtr „Project Manager”, „Scrum Master”, „Agile Coach” + lokalizacja) działa lepiej niż kuli przez uczelnie. 8-12 wywiadów po 45-60 minut to zazwyczaj wystarczające nasycenie tematyczne dla jednej kwestii badawczej.
Ankieta online: miary sukcesu projektu, efektywnosc metodyki
Badania ankietowe w PM mają sens, gdy chcesz mierzyć percepcję, częstość stosowania praktyk lub samoocenę. Skale Likerta (1-5 lub 1-7) dla oceny efektywności metodyki, pytania wielokrotnego wyboru dla narzędzi projektowych. Minimalna próba dla analiz statystycznych: 100 respondentów dla regresji, 30-50 dla statystyk opisowych.
Kanały dystrybucji: PMI Poland Chapter, Agile Poland, LinkedIn grupy project managerów, forum Stowarzyszenia Project Management Polska. Tematyczne newslettery branżowe też działają.
Analiza dokumentacji projektowej: rejestry ryzyka, backlog, burndown chart
Analiza dokumentacji projektowej to metoda, którą często pomijają studenci, a która daje unikalne dane. Rejestry ryzyka pokazują, ile ryzyk jest faktycznie aktualizowanych w trakcie projektu (a nie tylko wypełnionych na początku i zapomnianch). Burndown chart z Jiry pozwala zmierzyć velocity i stabilność prędkości zespołu. Backlog refinement – jak bardzo zmienia się zakres między sprintami?
Uwaga: dostęp do dokumentacji wymaga zgody organizacji i zwykle anonimizacji danych. Zaplanuj to wcześniej – nie zakładaj, że firma chętnie otworzy Ci rejestry ryzyk.
Action research: badanie wlasnego projektu/organizacji
Jeśli pracujesz jako PM, Scrum Master lub członek zespołu projektowego, masz dostęp do danych z pierwszej ręki. Action research (badanie w działaniu) to legitymizowana metodologia naukowa – badasz własną praktykę, wprowadzasz zmianę, obserwujesz efekty, reflektujesz. Warunek: musisz zachować rygory metodologiczne – dziennik badacza, dokumentacja interwencji, świadoma analiza własnych uprzedzeń (reflexivity).
Benchmarking: Pulse of the Profession (PMI), State of Agile Report (Digital.ai), Standish Group CHAOS Report
Trzy raporty, które powinieneś znać na pamięć:
- PMI Pulse of the Profession – wydawany corocznie, dane o stopie sukcesu projektów, dojrzałości organizacyjnej, trendach PM. Przykład: edycja 2023 podaje, że 35% projektów kończy się niepowodzeniem (nie osiąga celów lub zostaje przerwanych).
- State of Agile Report (Digital.ai) – coroczne badanie stosowania metodyk zwinnych. Kluczowe dane o popularności frameworków, barierach adoptacji agile, korzyściach wdrożenia
- CHAOS Report (Standish Group) – badanie wskaźników sukcesu projektów IT od 1994 roku. Trzy kategorie: „successful” (na czas, w budżecie, z pełnym zakresem), „challenged” (z opóźnieniami/przekroczeniami), „failed” (przerwane).
Benchmarkujesz swoje wyniki względem tych raportów – to pokazuje, czy Twoja organizacja/przypadek jest typowy czy odstaje od normy.
Narzedzia projektowe
Tradycyjne: MS Project, Primavera P6 – WBS, Gantt, critical path (CPM), PERT
MS Project to standard w dużych organizacjach dla projektów waterfall – WBS (Work Breakdown Structure), Gantt, ścieżka krytyczna (CPM), analiza PERT (Program Evaluation and Review Technique) dla szacowania z niepewnością (optimistic/most likely/pessimistic). Primavera P6 (Oracle) dominuje w budownictwie i energetyce – jeśli badasz projekty infrastrukturalne, będziesz o nim pisał.
Earned Value Management (EVM) to zestaw miar wydajności projektu: SPI (Schedule Performance Index = EV/PV – wartość poniżej 1 to opóźnienie), CPI (Cost Performance Index = EV/AC – poniżej 1 to przekroczenie budżetu). Możesz analizować dane EVM z projektów jako miary sukcesu.
Zwinne: Jira, Azure DevOps, Monday.com, Trello – sprint planning, velocity, burndown
Jira (Atlassian) to de facto standard dla zespołów Scrum i Kanban – ma wbudowane raporty: burndown chart, velocity chart, cumulative flow diagram. Azure DevOps (Microsoft) łączy zarządzanie backlogiem z CI/CD – coraz popularniejszy w organizacjach Microsoft-centrycznych. Monday.com i Trello to narzędzia lżejsze, częściej w małych zespołach.
Dane z tych narzędzi to skarbnica dla Twojej pracy empirycznej. Velocity (liczba story points per sprint), sprint burndown (czy praca kończy się w terminie), cycle time (czas od „in progress” do „done”) – to wszystko mierzalne, archiwizowane i dostępne do analizy.
Hybrid PM: Microsoft Project Online, Asana
Podejście hybrydowe (hybrid PM) – mieszające elementy waterfall i agile – to rosnący trend. PMI Pulse of the Profession 2022 podaje, że 58% organizacji stosuje podejście hybrydowe. Microsoft Project Online i Asana obsługują zarówno Gantt jak i tablice kanbanowe. Badanie efektywności podejścia hybrydowego vs czystego agile lub czystego waterfall to aktualny i słabo zbadany temat w polskim kontekście.
Certyfikaty i standardy (kontekst pracy)
PMI PMP, PMI-ACP, CAPM – egzaminy i wymagania doswiadczenia
PMP (Project Management Professional) wymaga 36 miesięcy doświadczenia (z dyplomem) lub 60 miesięcy (bez), plus 35 godzin formalnego szkolenia, plus egzamin 180 pytań w 230 minut. Od 2021 roku egzamin PMP ma 50% pytań z agile/hybrydowego PM – to odzwierciedla zmianę w branży. PMI-ACP (Agile Certified Practitioner) to certyfikat typowo zwinny – wymaga znajomości Scrum, Kanban, XP, Lean. CAPM to wersja wejściowa bez wymogu doświadczenia.
PRINCE2 Foundation/Practitioner – procesy, motywy, zasady
PRINCE2 7 (2023) to aktualna wersja standardu Axelos. Struktura: 7 zasad (ciągłe uzasadnienie biznesowe, wyciąganie wniosków, role i odpowiedzialności, zarządzanie etapowe, zarządzanie przez wyjątki, koncentracja na produktach, dostosowanie do środowiska projektu), 7 motywów (Business Case, Organizacja, Jakość, Plany, Ryzyko, Zmiana, Postęp), 7 procesów. PRINCE2 dominuje w UK i Europie Zachodniej, jest też popularny w administracji polskiej.
Professional Scrum Master (PSM I/II), SAFe 6.0 certifications
PSM I (scrum.org) to test 80 pytań w 60 minut, próg zdania 85%. PSM II to już egzamin wymagający głębszej wiedzy i kosztuje więcej. SAFe 6.0 (Scaled Agile Framework) to aktualną wersja – certyfikaty Leading SAFe, SAFe Scrum Master, SAFe Product Owner/Product Manager. SAFe 6.0 wprowadził większy nacisk na przepływ wartości (value stream) i miary biznesowe. W pracy możesz analizować, czy certyfikacja koreluje z lepszymi wynikami projektów – to jest empirycznie weryfikowalne.
ISO 21500 (zarzadzanie projektami), ISO 21502
ISO 21500:2012 (zaktualizowany 2021) to międzynarodowy standard zarządzania projektami, używany jako rama odniesienia w organizacjach działających globalnie. ISO 21502 (2020) rozszerza go o wytyczne dla zarządzania projektami „ogólnie”. W Polsce rzadko stosowany jako jedyny standard, częściej jako uzupełnienie PMBOK lub PRINCE2.
Struktura pracy magisterskiej
Klasyczna struktura dla pracy empirycznej z PM wygląda tak:
Rozdział 1 to wstęp: kontekst badania, problem badawczy (najlepiej jako pytanie: „Czy stosowanie SAFe 6.0 wpływa na velocity zespołów scrumowych?”), cel i zakres, hipotezy, struktura pracy. Nie więcej niż 5-8 stron.
Rozdział 2 to przegląd literatury: teorie (Cynefin, Iron Triangle, krzywa uczenia), standardy (PMBOK 7, PRINCE2 7, ISO 21500), metodyki (Scrum, Kanban, SAFe 6.0), stan badań (gdzie są luki, które Ty wypełniasz). Minimum 30-40 pozycji bibliograficznych, w tym anglojęzyczne artykuły z Journal of Project Management, International Journal of Project Management, Project Management Journal.
Rozdział 3 to metodologia: uzasadnienie wyboru metodologii (dlaczego case study, a nie ankieta?), opis próby badawczej, narzędzia zbierania danych (scenariusz wywiadu, kwestionariusz), procedura analizy danych, ograniczenia metodologiczne.
Rozdział 4 to wyniki badań: prezentacja danych bez interpretacji – tabele, wykresy velocity, cytaty z wywiadów (zanonimizowane), dane z dokumentacji.
Rozdział 5 to dyskusja: interpretacja wyników, odniesienie do hipotez, porównanie z literaturą i raportami branżowymi (tu wchodzi benchmarking z PMI/State of Agile/CHAOS Report), wnioski teoretyczne i praktyczne.
Zakończenie, bibliografia, aneksy (scenariusz wywiadu, kwestionariusz, tabele surowych danych).
Typowe bledy
Opis metodyki zamiast badania jej stosowania
To jest najczęstszy błąd w pracach z PM: student opisuje, co to jest Scrum, jakie ma ceremonie, role, artefakty. Promotor czyta to i myśli: „To jest z documentation Scrum Guide, nie z badań.” Twoja praca ma odpowiadać na pytanie, jak Scrum działa w konkretnym kontekście – jakie napotyka bariery, jakie przynosi mierzalne efekty, jak różni się od książkowego modelu. Opis metodyki trafia do rozdziału teoretycznego, nie do wyników.
Brak triangulacji w case study
Jeden wywiad z dyrektorem IT firmy to za mało na case study projektu wdrożenia SAFe. Masz powiedzianą wersję z perspektywy jednej osoby, na jednym poziomie hierarchii, w jednym momencie czasu. Triangulacja oznacza: wywiady z kilkoma osobami (PM, Scrum Master, deweloper, sponsor), plus dokumentacja (burndown charty, rejestr ryzyka, retrospektywy), plus ewentualnie obserwacja. Dopiero wtedy możesz powiedzieć, że rozumiesz przypadek.
Mylenie metodyki z procesem
Scrum nie jest procesem – jest frameworkiem. PMBOK 7 nie jest metodyką – jest standardem. Waterfall to ogólne podejście, nie standard ISO. Te rozróżnienia mają znaczenie, gdy piszesz pracę naukową. Mylenie tych pojęć sygnalizuje promotorowi, że nie masz głębszego rozumienia obszaru.
FAQ – Najczestsze pytania
Czy do pracy z PM potrzebna jest wspolpraca z firma?
Nie jest absolutnie niezbędna, ale zdecydowanie podnosi wartość pracy. Bez dostępu do organizacji możesz zrobić przegląd literatury i badanie ankietowe – to akceptowalne. Jeśli chcesz zrobić case study lub analizę dokumentacji projektowej, musisz mieć partnera organizacyjnego. Szukaj przez LinkedIn, przez stowarzyszenia PM (PMI Poland Chapter), przez znajomych. Firmy IT, software houses, korporacje z PMO – wszystkie mają potencjalne case study. Umowa o poufności (NDA) i anonimizacja danych to standard – nie bój się tego proponować.
Jak dobrac organizacje do case study?
Szukaj organizacji, która: (a) realizuje projekty pasujące do Twojego pytania badawczego, (b) ma dostęp do dokumentacji, którą możesz analizować, (c) ma przynajmniej jedną osobę gotową poświęcić czas na wywiady. Rozmiar ma znaczenie: mała firma (10-50 osób) łatwiej dostępna, ale mniej procesów formalnych; duża korporacja ma PMO i formalne metodyki, ale trudniejszy dostęp. Idealny wariant: organizacja, w której już pracujesz lub robiłeś praktyki.
Czym rozni sie Scrum od Kanbana w kontekscie pracy naukowej?
Scrum ma predefiniowane sprinty (iteracje o stałej długości), role (Product Owner, Scrum Master, Development Team), ceremonie (sprint planning, daily standup, review, retrospektiva) i artefakty (product backlog, sprint backlog, increment). Kanban to system sterowania przepływem pracy: wizualizacja (tablica), limit WIP (Work In Progress), zarządzanie przepływem. Scrum nadaje się do badań z miarami sprint-level (velocity, burndown), Kanban do badań przepływowych (cycle time, throughput, CFD – cumulative flow diagram). W pracy naukowej oba mają konkretne miary, ale wymagają różnych danych i różnych ram teoretycznych.
Jak mierzyc sukces projektu IT?
Sukces projektu IT to wielowymiarowy konstrukt – i to jest punkt wyjścia dla dobrego rozdziału teoretycznego. Masz wymiary klasyczne: czas (SPI), koszt (CPI), zakres (% zrealizowanego backlogu). Masz wymiary Atkinson (1999): jakość produktu, satysfakcja użytkownika, korzyści biznesowe. Masz wymiary specyficzne dla agile: satysfakcja zespołu, szybkość dostarczania wartości (time to market), częstotliwość deploymentu (z metryk DORA: deployment frequency, lead time for changes, change failure rate, time to restore). Twoja praca powinna wybrać zestaw miar pasujący do pytania badawczego i uzasadnić ten wybór.
Wymagania formalne i egzamin
Praca magisterska na kierunku zarządzanie lub zarządzanie projektami ma zazwyczaj od 60 do 100 stron (bez aneksów). Sprawdź regulamin swojej uczelni – liczba stron, krój czcionki (Times New Roman 12 lub Arial 11), interlinia (1,5), marginesy (2,5 cm z lewej, 1,5 z prawej), styl cytowań (APA lub własny uczelniany). Bibliografię rób w menedżerze cytowań: Zotero (darmowy, dobrze integruje się z Word), Mendeley (płatny, ale szeroki).
Na egzaminie dyplomowym (obronie) zazwyczaj dostajesz 3 pytania od komisji: jedno od promotora, dwa od recenzentów lub komisji. Pytają o uzasadnienie wyborów metodologicznych („dlaczego case study a nie ankieta?”), o teorie („co to jest Iron Triangle i jakie są jego ograniczenia?”), o wnioski praktyczne („co wynika z Twojej pracy dla PM-a w firmie?”). Przygotuj się na pytania o Cynefin framework, miary EVM, różnice między PMBOK 7 a poprzednią edycją. To pytania, które lubią komisje – bo weryfikują, czy rozumiesz, o czym piszesz, a nie tylko przepisałeś z Wikipedii.
Jeśli masz dostęp do Jiry lub Azure DevOps przez pracę lub praktyki – eksportuj dane historyczne. To jest materiał badawczy, który przerobi Twoją pracę z opisowej w empiryczną. Nikt nie broni Ci analizować velocity swojego własnego zespołu.
