POPC Wsparcie

Jak badaliśmy?

Badanie miało 4 etapy:

1. Przygotowanie badania:
   • opracowaliśmy scenariusz badania i narzędzia badawcze,
   • wyłoniliśmy i zaprosiliśmy przedstawicieli instytucji do wzięcia udziału w badaniach jakościowych.
2. Badanie jakościowe:
   • podzieliliśmy uczestników na 5 grup focusowych,
   • przeprowadziliśmy z nimi zajęcia warsztatowe, na których wspólnie przeanalizowaliśmy ich potrzeby.
3. Badanie ilościowe – uczestnicy wypełnili ankietę on-line, dzięki której:
   • poznaliśmy Wasze potrzeby,
   • zbadaliśmy dojrzałość projektową wnioskodawców i beneficjentów II osi POPC.
4. Analiza i raport – opracowaliśmy raport z badań z etapu 2 i 3.
   Raport możecie pobrać na dole strony.

 

Kto badał?

Badanie przeprowadzili nasi eksperci do spraw badań User Experience w składzie: Magdalena Andrzejewska, Radosław Ratajczak i Filip Sieracki. Opiekę merytoryczną sprawowali: Andrzej Pieczunko – dyrektor Departamentu Realizacji w Centralnym Ośrodku Informatyki, Marcin Rogalski – kierownik projektu POPC Wsparcie, oraz Szymon Sankiewicz – kierownik Zespołu Projektów w Centralnym Ośrodku Informatyki, ekspert POPC Wsparcie.

 

Dlaczego i do czego wykorzystaliśmy retrospektywę?

W tym roku badania przebiegały zgodnie z zasadami retrospektywy. Retrospektywa to jeden z etapów zwinnych metodyk pracy. Jest okazją, by przeanalizować swoje działania i opracować plan usprawnień. Z tego punktu widzenia przyjrzeliśmy się projektom IT i ich otoczeniu instytucjonalnemu.

Czego tym razem dowiedzieliśmy się o projektach publicznych?

Potrzeby wnioskodawców i beneficjentów POPC zebraliśmy w 10 kategoriach:

1. Bariera administracyjna

Nadal zespoły projektowe zderzają się z barierą administracyjną. Jak możemy z nią sobie poradzić?

• Stwórzmy przyjazny, efektywny i szybki system oceny projektu i kontroli poprawności wydawania środków.
• Usprawnijmy działania wewnątrz organizacji, by przyspieszyć realizację projektu.

2. Kluczowa rola instytucji w powodzeniu projektów IT

Oczekiwania wobec pracowników tych instytucji rosną proporcjonalnie do rozwoju publicznych systemów IT. Dlatego być może musimy zmienić procesy, by dopasować się do ich oczekiwań i zapewnić im optymalne warunki.

3. Architektura IT i wiedza

Co możemy zrobić?

• Zapewnijmy zespołom projektowym dostęp do szkoleń i wiedzy eksperckiej.
• Zadbajmy o koordynację architektury państwa z metapoziomu portfela publicznych projektów IT oraz dostęp do wspólnej infrastruktury państwa.

4. Utrzymanie i rozwój systemów IT

Beneficjenci nie są organizacjami technologicznymi, dlatego planowanie projektu IT, utrzymania i rozwoju oprogramowania po okresie finansowania może stwarzać problemy. Dlatego, jeszcze zanim złożymy wniosek o dofinansowanie, potrzebujemy wiedzy i szkoleń na ten temat.

5. Zarządzanie zmianą – struktura wdrażania projektów IT

Zarządzanie zmianą w strukturach administracyjnych to istotna część zarządzania projektem IT. Potrzebujemy więcej szkoleń dotyczących:

• zarządzania zmianą,
• transformacji cyfrowej organizacji,
• metodyk angażowania użytkowników,
• budowania pilności zmiany i struktury wdrażania,
• koordynacji pomiędzy wykonawcami w zamówieniach publicznych.

6. Mniejsze projekty IT

Rozdzielmy konkursy i procedury dla dużych i mniejszych projektów IT. Te mniejsze zazwyczaj są zwinniejsze i łatwiejsze w realizacji.

7. Metody zapewniania jakości w zamówieniach publicznych

Wiele zespołów projektowych już przetestowało i znalazło skuteczne narzędzia realizacji zamówienia publicznego. Dlatego chcemy je zebrać i rozpropagować w środowisku publicznych projektów IT.

8. Większa świadomość User Experience

Organizacje:

• czują potrzebę angażowania użytkowników instytucjonalnych, jak i końcowych,
• dostrzegają konieczność zatrudnienia specjalistów UX,
• widzą brak wiedzy specjalistycznej, dlatego potrzebują wsparcia w budowaniu kompetencji.

9. Platforma wymiany doświadczeń

Nadal potrzebujemy platformy do wymiany doświadczeń.
Taka platforma:

• budowałaby społeczność zespołów projektowych IT,
• gromadziła wiedzę, kompetencje IT i doświadczenia,
• umożliwiała kontakt,
• pozwalała szukać synergii projektowych i reagować na bariery.

Beneficjenci czekają na takie rozwiązanie i chcą się w nie zaangażować!

10. Wypalenie zawodowe

Ryzyko wypalenia pojawia się, gdy:

• zachodzi konflikt między podziałem obowiązków bieżących i obowiązków projektowych u kierownika i członków zespołu,
• brakuje czasu na myślenie koncepcyjne i innowacyjne oraz rozwój.

 

Bardzo dziękujemy wszystkim uczestnikom za aktywny udział. Wasza otwartość i chęć dzielenia się wiedzą i problemami, które napotykacie w codziennej pracy, bardzo nam pomogły. Dzięki temu wiemy, na jakich elementach powinniśmy się skupić.
Wielkie brawa również dla naszego zespołu badawczego! Dobra robota!

 

Raport z badań możecie pobrać na dole strony. Przeczytajcie go i dajcie nam znać, czy w czymś możemy Wam pomóc. Czekamy na kontakt!