Na pewnym warsztacie strategicznym zespół projektowy przykleił na ścianie kartkę z „mocną stroną": „rynek e-commerce rośnie 15% rocznie". Zatrzymałem spotkanie. Rosnący rynek to nie jest mocna strona - to szansa. Mocna strona to coś, co masz w środku firmy i co możesz kontrolować. Ta pomyłka nie jest niewinna: jeśli wrzucisz czynnik zewnętrzny do złej ćwiartki, cała późniejsza strategia stanie na głowie. A właśnie ta jedna pomyłka - mylenie tego, co wewnętrzne, z tym, co zewnętrzne - psuje 80% analiz SWOT, które widziałem.
Analiza SWOT wygląda na narzędzie banalne: cztery pudełka, burza mózgów, gotowe. W praktyce to jedna z najczęściej źle robionych technik w arsenale analityka biznesowego. W tym artykule pokażę Ci, jak przeprowadzić SWOT dla projektu IT tak, żeby wyszła z niej konkretna decyzja, a nie ładny slajd. Przejdziemy przez definicje (z naciskiem na rozróżnienie, które wszystko zmienia), proces krok po kroku, macierz TOWS, która zamienia analizę w strategię, oraz częste błędy. Na koniec - pełny przykład na MediFlow, sieci 12 przychodni wdrażającej rejestrację online.
Analiza SWOT dla projektu IT - czym naprawdę jest
SWOT to akronim od czterech angielskich słów: Strengths (mocne strony), Weaknesses (słabe strony), Opportunities (szanse) i Threats (zagrożenia). To narzędzie analizy strategicznej, które porządkuje czynniki wpływające na projekt według dwóch osi: pochodzenie (wewnętrzne vs zewnętrzne) oraz charakter (pomocne vs szkodliwe).
Najważniejsze - i najczęściej ignorowane - jest pierwsze rozróżnienie:
- Mocne i słabe strony są wewnętrzne. To czynniki, które kontrolujesz lub na które masz realny wpływ: kompetencje zespołu, architektura, budżet, jakość kodu, procesy. Możesz je zmienić decyzją projektową.
- Szanse i zagrożenia są zewnętrzne. To czynniki otoczenia, na które nie masz wpływu, ale na które musisz reagować: trendy rynkowe, regulacje, konkurencja, dostępność technologii, sytuacja gospodarcza.
Test jest prosty: zapytaj „czy mogę to zmienić moją decyzją w projekcie?". Jeśli tak - to czynnik wewnętrzny (S lub W). Jeśli nie, a jedynie mogę się do tego dostosować - to czynnik zewnętrzny (O lub T). „Doświadczony zespół" to mocna strona (zatrudniłeś tych ludzi). „Niedobór specjalistów React na rynku" to zagrożenie (nie kontrolujesz rynku pracy).
Jeśli interesuje Cię, gdzie kończy się SWOT, a zaczyna analiza makrootoczenia, zajrzyj do artykułu o tym, jak SWOT i PESTLE uzupełniają się jako narzędzia analizy strategicznej. To dwa różne poziomy patrzenia na ten sam projekt.
Dlaczego SWOT ma sens akurat w projekcie IT
Projekty informatyczne mają swoją specyfikę: wysoką niepewność, szybko starzejące się technologie, długi czas realizacji i duże uzależnienie od ludzi. Dobrze zrobiony SWOT na starcie projektu daje analitykowi cztery konkretne rzeczy:
- Wspólny obraz sytuacji - zarząd, dział IT i biznes zaczynają mówić o tym samym projekcie tym samym językiem, zamiast każdy w swojej bańce.
- Wczesne sygnały ryzyka - zagrożenia z SWOT to gotowy materiał wejściowy do rejestru ryzyk projektu. Lepiej zobaczyć „zależność od jednego architekta" w drugim tygodniu niż w piątym miesiącu, gdy ten architekt złoży wypowiedzenie.
- Argumenty do business case'u - szanse i mocne strony to materiał, którym uzasadnisz inwestycję przed decydentami.
- Punkt odniesienia do aktualizacji - SWOT zrobiony raz i schowany do szuflady jest bezużyteczny. Ale SWOT, do którego wracasz na każdym kamieniu milowym, pokazuje, jak zmienia się kontekst projektu.
Zaznaczę od razu: SWOT nie jest narzędziem decyzyjnym. To narzędzie diagnostyczne. Sam w sobie niczego nie rozstrzyga - porządkuje obraz, na podstawie którego dopiero podejmujesz decyzje. Dlatego później pokażę Ci macierz TOWS, która z tego obrazu wyciąga konkretne działania.
Jak przeprowadzić analizę SWOT - krok po kroku
Krok 1: Zdefiniuj przedmiot i cel analizy
Najczęstszy błąd na starcie: analiza SWOT „firmy" pomieszana z analizą SWOT „projektu". To dwie różne rzeczy. SWOT projektu IT dotyczy konkretnego przedsięwzięcia - np. wdrożenia systemu rejestracji online - a nie całej organizacji. Zapisz jednym zdaniem, co analizujesz i po co. Przykład: „Analiza SWOT wdrożenia systemu rejestracji online dla sieci MediFlow, na potrzeby decyzji o uruchomieniu projektu w Q3". To zdanie ustawia granicę dla wszystkiego, co znajdzie się w ćwiartkach.
Krok 2: Zbierz zespół z różnymi perspektywami
SWOT robiony w pojedynkę to lista Twoich przekonań, nie analiza. Zaproś ludzi, którzy widzą projekt z różnych stron: kierownika projektu, architekta lub lead developera, przedstawiciela biznesu (sponsora), a jeśli się da - kogoś od bezpieczeństwa i kogoś od strony użytkownika. Cztery-sześć osób to optymalny rozmiar. Większa grupa rozmywa dyskusję.
Krok 3: Generuj czynniki - osobno dla każdej ćwiartki
Prowadź to jako moderowaną burzę mózgów, ale z dyscypliną. Polecam zacząć od czynników wewnętrznych (S i W), bo zespół zna je najlepiej, a potem przejść do zewnętrznych (O i T), które wymagają spojrzenia na rynek. Na tym etapie nie oceniaj - zbieraj. Jedna karteczka = jeden konkretny czynnik.
Krok 4: Selekcjonuj i priorytetyzuj
Tu odsiewasz plewy. Z trzydziestu karteczek zostaw 4-6 w każdej ćwiartce - te, które realnie wpływają na powodzenie projektu. Pomocne pytanie przy każdej: „gdyby to zniknęło lub się ziściło, czy zmieniłoby to losy projektu?". Jeśli nie - wyrzuć. Priorytety ustal np. głosowaniem punktowym (każdy ma 3 głosy na ćwiartkę).
Krok 5: Wyciągnij strategie (macierz TOWS)
To krok, który większość zespołów pomija - i dlatego ich SWOT umiera na slajdzie. O macierzy TOWS za chwilę osobno, bo to ona zamienia diagnozę w plan działania.
Mocne strony w projekcie IT - przykłady z realiów
Mocne strony to wewnętrzne atuty, które dają projektowi przewagę. Zwróć uwagę, że dobry zapis mocnej strony jest konkretny i weryfikowalny, a nie ogólnikowy.
| Źle (ogólnik) | Dobrze (konkret) |
|---|---|
| Doświadczony zespół | Zespół z 3 wdrożeniami systemów rezerwacji w branży medycznej w ostatnich 2 latach |
| Nowoczesne technologie | Architektura oparta na sprawdzonym stacku (PostgreSQL + API REST), znanym całemu zespołowi |
| Dobra marka | Rozpoznawalna marka MediFlow w regionie - 60% pacjentów zna sieć z polecenia |
| Sprawne zarządzanie | Działający proces w Scrumie z dwutygodniowymi sprintami i regularnym refinementem |
Różnica jest fundamentalna. „Doświadczony zespół" nie daje się z niczym powiązać. „Zespół z 3 wdrożeniami w branży medycznej" to argument, który możesz wprost wykorzystać w strategii - np. obiecać klientowi szybsze tempo dzięki znajomości domeny.
Słabe strony w projekcie IT - przykłady
Słabe strony to wewnętrzne ograniczenia. Tu zespoły grzeszą odwrotnie - są zbyt łagodne dla siebie. Dobry SWOT wymaga uczciwości, która bywa niewygodna.
- Zależność od jednej osoby (bus factor = 1) - tylko jeden architekt rozumie integrację z systemem płatności. Jego nieobecność blokuje projekt.
- Brak doświadczenia w domenie - zespół nigdy nie pracował z danymi medycznymi i nie zna wymogów RODO dla danych wrażliwych.
- Dług techniczny istniejącego systemu - nowa funkcja musi się integrować z 12-letnim systemem rejestracji bez dokumentacji.
- Napięty budżet bez rezerwy - projekt zaplanowany co do złotówki, każda zmiana zakresu wywraca finansowanie.
- Rozproszony zespół w trzech strefach czasowych - synchroniczna komunikacja możliwa tylko 2 godziny dziennie.
Praktyczna wskazówka: słabe strony to materiał, który prosi się o plan działania. Każdą z nich potraktuj jak otwarte zadanie - „bus factor = 1" rozwiązujesz przez pair programming i dokumentację, „brak wiedzy o RODO" przez konsultację z prawnikiem na starcie, nie na końcu.
Szanse dla projektu IT - przykłady
Szanse to korzystne czynniki zewnętrzne. Pamiętaj: nie kontrolujesz ich, ale możesz się do nich ustawić tak, by na nich skorzystać.
- Zmiana zachowań pacjentów - po pandemii rejestracja online stała się oczekiwanym standardem, nie ekstrawagancją. Rynek jest „rozgrzany".
- Dofinansowania na cyfryzację ochrony zdrowia - dostępne programy mogą pokryć część kosztów wdrożenia.
- Dojrzałe, tanie technologie - gotowe bramki SMS, kalendarze API, biblioteki uwierzytelniania skracają czas budowy.
- Słabość konkurencji - lokalne przychodnie wciąż przyjmują zapisy telefonicznie, w godzinach pracy. Okno na przewagę jest otwarte.
Zagrożenia dla projektu IT - przykłady
Zagrożenia to niekorzystne czynniki zewnętrzne. To one zasilają rejestr ryzyk projektu.
- Zaostrzenie regulacji - zmiany w przepisach o ochronie danych medycznych mogą wymusić przeprojektowanie systemu w trakcie budowy.
- Cyberataki na placówki medyczne - sektor zdrowia jest celem ataków ransomware; wyciek danych pacjentów to ryzyko reputacyjne i prawne.
- Wejście dużego gracza - ogólnopolska platforma rezerwacji wizyt może wejść na rynek lokalny z większym budżetem marketingowym.
- Niedobór specjalistów - trudność z dorekrutowaniem programistów może wydłużyć harmonogram.
Macierz SWOT i macierz TOWS - od diagnozy do strategii
Klasyczna macierz SWOT to tabela 2×2, w której układasz czynniki według osi pochodzenia i charakteru:
| Pomocne | Szkodliwe | |
|---|---|---|
| Wewnętrzne | Strengths Zespół z doświadczeniem w branży medycznej Znajomy, stabilny stack technologiczny | Weaknesses Brak wiedzy o RODO dla danych wrażliwych Bus factor = 1 przy integracji płatności |
| Zewnętrzne | Opportunities Pacjenci oczekują rejestracji online Dostępne dofinansowania na cyfryzację | Threats Zaostrzenie regulacji o danych medycznych Cyberataki na placówki medyczne |
Ale to dopiero diagnoza. Prawdziwa wartość pojawia się, gdy zestawisz ćwiartki ze sobą w macierzy TOWS - narzędziu, które generuje cztery typy strategii:
- SO (maxi-maxi) - jak wykorzystać mocne strony, by złapać szanse? Przykład: skorzystać z doświadczenia zespołu w branży medycznej (S), by szybciej niż konkurencja zdobyć pacjentów oczekujących rejestracji online (O).
- WO (mini-maxi) - jak nadrobić słabości, by nie przegapić szans? Przykład: zatrudnić konsultanta RODO (nadrobienie W), żeby móc legalnie wejść w obszar danych medycznych i wykorzystać dofinansowania (O).
- ST (maxi-mini) - jak użyć mocnych stron, by zneutralizować zagrożenia? Przykład: wykorzystać stabilny, sprawdzony stack (S) z dobrymi mechanizmami bezpieczeństwa, by zminimalizować ryzyko cyberataków (T).
- WT (mini-mini) - jak ograniczyć słabości i zagrożenia jednocześnie? Przykład: rozłożyć wiedzę o integracji płatności na dwie osoby (W) i wdrożyć szyfrowanie zgodne z regulacjami (T), zanim ryzyka się zmaterializują.
Dopiero TOWS zamienia cztery listy w cztery zestawy działań. To jest ten moment, w którym analiza zaczyna na siebie zarabiać.
Częste błędy w analizie SWOT (i jak ich uniknąć)
- Mylenie czynników wewnętrznych z zewnętrznymi - najczęstszy i najgroźniejszy błąd. „Rosnący rynek" trafia do mocnych stron, „świetny zespół" do szans. Test kontrolny: czy mogę to zmienić decyzją projektową? Wewnętrzne = tak, zewnętrzne = nie.
- Ogólniki zamiast konkretów - „dobra komunikacja", „nowoczesne technologie". Z takiego zapisu nie da się nic wyciągnąć. Każdy czynnik powinien być na tyle konkretny, by dało się go powiązać z działaniem.
- Zatrzymanie się na czterech listach - SWOT bez TOWS to diagnoza bez recepty. Listy same w sobie niczego nie rozstrzygają.
- Lakierowanie rzeczywistości - zespół wstydzi się słabych stron, więc wpisuje miękkie ogólniki. Bez uczciwej oceny słabości i zagrożeń analiza jest bezużyteczna.
- Jednorazowość - SWOT zrobiony na kick-offie i nigdy nieaktualizowany. Otoczenie projektu IT zmienia się szybko; wracaj do analizy na kamieniach milowych.
- Brak priorytetyzacji - 15 czynników w każdej ćwiartce to nie analiza, to lista życzeń. Mniej znaczy więcej: 4-6 naprawdę istotnych czynników.
Mini-case: SWOT dla rejestracji online w MediFlow
MediFlow to sieć 12 przychodni, która chce wdrożyć system rejestracji wizyt online. Zanim ruszył projekt, zrobiliśmy z zespołem SWOT, a potem TOWS. Oto skrócona wersja.
Mocne strony: rozpoznawalna marka w regionie; zespół IT z wcześniejszym wdrożeniem systemu rezerwacji; stabilna baza pacjentów (ok. 40 tys.).
Słabe strony: 12-letni system rejestracji bez dokumentacji, do którego trzeba się podłączyć; brak kompetencji RODO dla danych medycznych; rejestratorki przyzwyczajone do telefonu - ryzyko oporu wobec zmiany.
Szanse: pacjenci oczekują dziś rejestracji online; konkurencja wciąż przyjmuje zapisy telefonicznie; dostępne dojrzałe komponenty (bramka SMS, kalendarz API).
Zagrożenia: wymogi prawne dla danych wrażliwych; ryzyko cyberataku na dane pacjentów; możliwość wejścia ogólnopolskiej platformy.
Z macierzy TOWS wyszły konkretne decyzje, które trafiły do planu projektu:
- SO: uruchomić MVP rejestracji online w 3 najpopularniejszych przychodniach jako pierwszych, by wyprzedzić konkurencję, korzystając z rozpoznawalności marki.
- WO: zakontraktować audyt RODO na starcie i przeznaczyć część budżetu z dofinansowania na zgodność prawną.
- ST: oprzeć system na sprawdzonym, dobrze zabezpieczonym stacku i wymusić szyfrowanie danych pacjentów od pierwszej linii kodu.
- WT: zbudować integrację ze starym systemem w parze (dwóch deweloperów), z bieżącą dokumentacją, by uniknąć bus factor = 1.
Najważniejsze odkrycie tego SWOT-u było nieoczywiste: największym ryzykiem nie była technologia, tylko opór rejestratorek. To przesunęło środek ciężkości projektu - dodaliśmy etap szkoleń i pilotaż z udziałem zespołu rejestracji, zanim ruszyliśmy szerzej. SWOT zrobiony porządnie potrafi takie rzeczy ujawnić.
Jak poprowadzić warsztat SWOT, żeby coś z niego wyszło
SWOT najczęściej robi się grupowo i to facylitacja decyduje, czy wyjdzie z niego konkret, czy lista ogólników. Kilka rzeczy, które sprawdzają mi się jako prowadzącemu:
- Przygotuj kontekst przed spotkaniem. Roześlij jednozdaniowy cel analizy i krótkie tło projektu. Ludzie, którzy przychodzą „na zimno", produkują ogólniki.
- Pracuj cicho, zanim zaczniesz głośno. Daj uczestnikom 5 minut na samodzielne wypisanie czynników na karteczkach, zanim zaczniecie dyskusję. Inaczej najgłośniejsza osoba ustawia ton, a cisi - często najlepiej znający szczegóły - milkną.
- Pilnuj rozróżnienia na bieżąco. Gdy ktoś przykleja „rosnący rynek" do mocnych stron, zatrzymaj się i zadaj test kontrolny: „możemy to zmienić decyzją projektową?". To uczy zespół właściwego myślenia w trakcie pracy.
- Wymuszaj konkret. Na każdy ogólnik reaguj pytaniem „co dokładnie masz na myśli?". „Dobry zespół" zamień na „zespół z trzema wdrożeniami w tej domenie".
- Nie kończ na listach. Zostaw ostatnią trzecią część warsztatu na TOWS - zestawienie ćwiartek i wyciągnięcie strategii. Bez tego zespół wyjdzie z czterema listami i poczuciem, że „coś zrobili", ale bez decyzji.
Facylitacja to osobna, niedoceniana umiejętność analityka. Dobry warsztat SWOT w 90 minut daje więcej niż tydzień indywidualnych przemyśleń - pod warunkiem, że ktoś nim sprawnie pokieruje.
Od SWOT do rejestru ryzyk - praktyczny pomost
Ćwiartka „zagrożenia" to nie koniec pracy, tylko surowiec. Każde istotne zagrożenie warto przenieść do rejestru ryzyk projektu i opisać konkretniej, niż pozwala na to format SWOT. Przejście wygląda tak:
| Zagrożenie (SWOT) | Ryzyko w rejestrze | Reakcja |
|---|---|---|
| Cyberataki na placówki medyczne | Wyciek danych pacjentów wskutek ataku ransomware (wpływ: wysoki, prawdopodobieństwo: średnie) | Szyfrowanie danych, audyt bezpieczeństwa, kopie zapasowe offline |
| Zaostrzenie regulacji o danych medycznych | Konieczność przeprojektowania systemu w trakcie budowy (wpływ: wysoki, prawdopodobieństwo: niskie) | Konsultacja prawna na starcie, architektura z marginesem na zgodność |
| Niedobór specjalistów na rynku | Wydłużenie harmonogramu z powodu braku rąk (wpływ: średni, prawdopodobieństwo: średnie) | Wcześniejsza rekrutacja, rozłożenie wiedzy w zespole |
Różnica jest istotna: SWOT mówi „uwaga, to może się stać", a rejestr ryzyk dodaje „jak prawdopodobne, jak groźne i co z tym robimy". SWOT bez tego pomostu zostaje obserwacją; z nim staje się początkiem zarządzania ryzykiem. To jeden z powodów, dla których robię SWOT na starcie każdego większego projektu - daje gotowy materiał wejściowy do planu. Jeśli chcesz zobaczyć gotowy rejestr od środka - z oceną prawdopodobieństwa, wpływem i właścicielem każdej pozycji - opisałem krok po kroku, jak zbudować rejestr ryzyk.
SWOT w cyklu życia projektu - kiedy wracać do analizy
Najlepsi analitycy nie traktują SWOT jak jednorazowego rytuału na kick-offie. Wracają do niego:
- Na starcie projektu - jako wkład do business case'u i rejestru ryzyk.
- Na kamieniach milowych - bo otoczenie się zmienia; nowy konkurent, nowa regulacja, odejście najważniejszej osoby przesuwają czynniki między ćwiartkami.
- Przy decyzjach o zmianie zakresu - gdy ktoś chce dorzucić funkcję, SWOT pomaga ocenić, czy to wzmacnia mocne strony, czy odsłania słabość.
SWOT to nie dokument do archiwum. To żywa mapa kontekstu, która powinna ewoluować razem z projektem.
FAQ - analiza SWOT dla projektu IT
Czym różni się analiza SWOT od PESTLE?
SWOT patrzy na konkretny projekt lub firmę i łączy czynniki wewnętrzne (mocne i słabe strony) z zewnętrznymi (szanse i zagrożenia). PESTLE bada wyłącznie makrootoczenie - czynniki polityczne, ekonomiczne, społeczne, technologiczne, prawne i środowiskowe. W praktyce robi się najpierw PESTLE, by zrozumieć otoczenie, a jego wyniki zasilają część „szanse i zagrożenia" w SWOT. Więcej w artykule o SWOT i PESTLE jako narzędziach analizy strategicznej.
Czy SWOT to to samo co analiza ryzyka?
Nie, ale się przenikają. Ćwiartka „zagrożenia" w SWOT to świetny materiał wejściowy do rejestru ryzyk - ale analiza ryzyka idzie dalej: szacuje prawdopodobieństwo, wpływ i plany reakcji. SWOT daje szerszy, strategiczny obraz, ryzyka schodzą w szczegóły operacyjne.
Ile czynników powinno być w każdej ćwiartce?
Optymalnie 4-6. Więcej oznacza, że nie przeprowadziłeś priorytetyzacji i analiza traci ostrość. Lepiej mieć cztery czynniki, które realnie ważą na losach projektu, niż piętnaście, z których połowa to szum.
Czy SWOT ma sens w projektach zwinnych (Agile)?
Tak - szczególnie na poziomie strategicznym, przy uruchamianiu inicjatywy lub epiki. W Agile robi się go lżej i wraca do niego częściej, bo iteracyjny charakter pracy oznacza, że kontekst zmienia się szybciej. Sposób pracy analityka różni się tu od podejścia kaskadowego - opisuję to w artykule o roli analityka w Agile i Waterfall.
Kto powinien prowadzić analizę SWOT w projekcie IT?
Najczęściej analityk biznesowy lub kierownik projektu, w roli moderatora. Ważne, by prowadzący nie narzucał własnych czynników, tylko wydobywał je od zespołu i pilnował dyscypliny rozróżnienia wewnętrzne/zewnętrzne.
Podsumowanie
Analiza SWOT dla projektu IT jest tak dobra, jak dyscyplina, z jaką ją robisz. Jeśli zapamiętasz tylko jedno z tego artykułu, niech to będzie test kontrolny: mocne i słabe strony są w środku i możesz je zmienić; szanse i zagrożenia są na zewnątrz i musisz się do nich ustawić. Reszta - konkret zamiast ogólników, priorytetyzacja, a przede wszystkim macierz TOWS, która zamienia cztery listy w cztery strategie - buduje się na tym fundamencie.
Chcesz przećwiczyć SWOT i inne techniki analizy strategicznej na realnych przypadkach, z informacją zwrotną? Na platformie Analify robisz to na case studies takich jak MediFlow, a swoją wiedzę sprawdzasz w testach z analizy biznesowej - bo analizę najlepiej opanować, robiąc ją, a nie tylko o niej czytając.