Case Studies

Warsztat z zarządzania projektami po mojemu, a może również po Twojemu?

With agile being now the most popular approach to IT project management, the variety of projects it’s being used for is extensive. Agile is no longer reserved for small, dynamic products. It has turned out that more complex, potentially critical projects can also benefit from agile practices. Nevertheless, some adjustments had to be made – such as managing risks. Risk management is a no brainer in systems where human lives are at stake. However, I would like to address another type of projects, the ones that most of us are probably involved in – products that in case of malfunction will not cost lives, but might have some serious (usually financial) repercussions. Even though “risk” is not the most attractive of terms, it’s worth bringing it up during your agile meetings. And who knows, maybe being the killjoy at the planning phase will allow your team to actually achieve more joy by the end of the project?

Eklektyzm metodyczny, czyli o projektach infrastrukturalnych słów kilka. Budowa tuneli kolejowych w Serbii – case study

Zazwyczaj jest tak, że planując rozpoczęcie realizacji projektu zastanawiamy się nad tym, w jaki sposób, a właściwie to według jakiej metodyki lub szkoły będziemy go prowadzić. Czy sytuacja zawsze jest tak oczywista? Czy projekty IT to zawsze Agile lub Scrum, a projekty infrastrukturalne, czy produkcyjne to zawsze stream lub waterfall? Otóż nie i mówię to z pełnym przekonaniem. Nie zawsze białe to białe, a czarne to czarne. Pomiędzy nimi jest dość duża skala szarości, lub po prostu bielsze odcienie bieli.

Projekty kluczem do realizacji nowoczesnej strategii. Studium przypadku Jastrzębskiej Spółki Węglowej

Projekt i zarządzanie projektami to powszechnie znane pojęcia, od lat używane – zarówno przez największe korporacje jak i małe firmy rodzinne. Na niektóre osoby pojęcia te wciąż jednak działają jak płachta na byka. Projekty postrzegane są w takich wypadkach jako zakłócenie działalności przedsiębiorstwa. „Po co nam jakieś projekty? Jakby nie było nam dość bieżącej pracy!” Tymczasem, dzięki skoordynowanemu zarządzaniu portfelami, programami i projektami realizacja działań rozwojowych organizacji może być prostsza, czytelniejsza i bardziej transparentna. W poniższym studium przypadku Jastrzębskiej Spółki Węglowej przedstawię, w jaki sposób przejść przez okres negacji potrzeby zarządzania projektami i udowodnić pozytywny wpływ uporządkowania i standaryzacji działań okołoprojektowych na skuteczną i efektywną realizację przedsięwzięć i strategii firmy.

DevOps in SAFe – Success Possible with Cultural Change First

DevOps is the new buzzword in many companies. Although the concept has been there for a while it is still something new, something that we feel we need, something that we try to implement. And the sooner the better! Yet we still fail to recognize what DevOps has actually become and that the implementation is not only technical but rather cultural. What is DevOps? Let’s start with Wikipedia: “DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.”

Podróż w nieznane. Zarządzanie zmianą na przykładzie implementacji DDD

Menedżerowie wiedzą najlepiej, ile czasu trzeba poświęcić na budowanie świadomości i potrzeb w organizacji, zanim możliwe jest rozpoczęcie zmiany. Sytuacja zmienia się o 180 stopni, kiedy potrzeba, bardzo mocna, uderzy znienacka i zażąda zmiany. W takich momentach brakuje nam przygotowania, a co gorsza, nie mamy pojęcia jak zaistniałą potrzebę zaspokoić. Ostatnio taka sytuacja miała miejsce w firmie, w której pracuję. Artykuł ten przedstawia historię naszej podróży w nieznane oraz jej podział na elementy kluczowe dla procesu zarządzania (nieplanowaną) zmianą.

Wnioski z doświadczeń – studium przypadku. Rozwiązanie

W poprzednim artykule (Strefa PMI, nr 31, s. 34-35) przedstawiłem Wam studium przypadku – przedsięwzięcie realizowane w 7 obszarach przez zespoły z różnym podejściem do organizacji pracy. Projekt miał też kilku dostawców zaangażowanych w realizację wybranych zadań i obszarów. W ramach artykułu zadałem pytanie: w jaki sposób i kiedy powinien zostać zorganizowany proces zbierania wniosków z doświadczeń? Poprosiłem też czytelników Strefy PMI o przesłanie swoich pomysłów na sposób podejścia do zbierania wniosków z doświadczeń w projekcie.

“Do It Yourself, użytkowniku” czyli warsztat badawczy w oparciu o Design Thinking

Jak zbudować prawdziwą empatię w zespole, szybko zweryfikować założenia i prawdziwie zaangażować naszych odbiorców w proces tworzenia? Odpowiedzią na to pytanie może być warsztat badawczy – a o tym, czym on jest, oraz kiedy i jak go używać, znajdziecie więcej w poniższym artykule.

Drogowskaz Managera – subiektywny ranking najczęściej popełnianych błędów

Jaki jest najczęstszy powód rozpadu zespołu, nawet tego najbardziej zgranego? Co demotywuje pracownika, nawet tego najbardziej zaangażowanego? I wreszcie, jaka jest najczęstsza przyczyna konfliktów w załodze, nawet tej najbardziej zgodnej? Odpowiedź na wszystkie te pytania jest bardzo prosta – niewłaściwy człowiek na stanowisku managera.

Wnioski z doświadczeń – studium przypadku

O wnioskach z doświadczeń napisano już bardzo dużo. Z jednej strony standardy zarządzania projektami dostarczają wytycznych i przykładów zastosowań, z drugiej strony nawet świat zwinny od początku swojego „istnienia” postawił na zbieranie i wdrażanie usprawnień (w postaci na przykład retrospektywy w Scrumie). I o ile w zespołach scrumowych rzeczywiście retrospektywa jest bardzo często stosowana, o tyle na dużych projektach stanowi to „dodatek do kożucha” i głównie jest robiona na końcu projektu (bo wymaga tego dokumentacja zamknięcia projektu).

PMO – więzień Azkabanu czy żołnierz na poligonie?

Termin PMO został odmieniony już chyba przez wszystkie przypadki i choć na ten temat powiedziano już dużo, wciąż jednak dla wielu organizacji wydaje się on być zupełnie odległy. Ale od początku… Zagadnienie PMO (Project Management Office), ma już pewną histo­rię, jednak wciąż ewoluuje i wymaga ciągłych zmian. Funkcjonowanie w środowisku VUCA (Volatility, Uncertainty, Complexity, Ambiguity) determinuje konieczność stałego uczenia się organizacji, obserwowania otoczenia i dostosowywania do aktualnych warunków w odnie­sieniu ogólnym do strategii firmy, ale również jej poszczególnych obszarów. Podobnie z PMO, na które nie ma jednej uniwersalnej recepty.